Would be a bit easier to use if we could get away with just specifying the date, and if 00:00:00 was assumed for the time in this case.

CommentFileSizeAuthor
#17 _scheduler.perm_admin.trivial.patch679 byteslaken
#15 _scheduler.perm_admin.patch.txt377 bytesjonathan1055

Comments

gpk’s picture

gpk commented
Title: Remove requirement to specify time in the (un)publish fields » Only user 1 can administer scheduler
Category: feature » bug

Ah I see there is a settings page at admin/settings/scheduler. However I cannot access it, because 1) I am not logged in as user 1, and 2) there is no such thing as an "administer content" permission.

Probably the latter should be "administer site configuration", or maybe a new "administer scheduler" permission.

gpk’s picture

gpk commented

Removing tag added by mistake.

eric-alexander schaefer’s picture

eric-alexander schaefer commented

Current CVS-Version of 6.x and 5.x use "access administration pages" as permission for configuring scheduler. There will be a new release very soon.

gpk’s picture

gpk commented

Thanks Eric.

This seems to me a very weak permission to control who can modify the single global scheduler date/time format. To give anyone access to any of the admin pages on the site I think you have to give them "access administration pages" permission, so this means that any lowly administrator of any sort will always be able to modify the scheduler date format setting. Not sure if this is what is intended? I'd have thought this setting is something set once and for all by the site admin, end of story!

"Administer nodes" would be another option I guess, but again, since the date format is something you wouldn't change once you've got it to your liking I can't see much benefit in having it on every content administrator's admin page.

HTH

gpk’s picture

gpk commented
Title: Only user 1 can administer scheduler » "access admin pages" is too permissive for allowing user to change sheduler settings

I've just checked the {menu_router} table in my DB and the "access administration pages" permission only lets you access the admin "portal" and any help pages, i.e. it is much less privileged than "administer nodes", which allows someone to mess with any content on the site.

In view of #431510: Change permission for admin setings to 'access administration pages' perhaps "administer site configuration" would be the best permission to use.

eric-alexander schaefer’s picture

eric-alexander schaefer commented

So we should have "administer scheduler" and the admin can then choose if he wants anybody to edit this value...

eric-alexander schaefer’s picture

eric-alexander schaefer commented

I'd like some more opinions for this, because I don't want to change the permission string every other week...

gpk’s picture

gpk commented

@7: Thanks for paying attention to my ramblings, and yes, I sympathise!

jonathan1055’s picture

jonathan1055 commented

OK, lets think this through. For sites with only one administrator (user/1) it is not an issue because they will always get every permission.

So for sites which have a secondary level of admin user, permissions would most likely be given to this role to allow these users to have admin authority for contrib modules but core admin tasks would remain in the control of user/1. These are probably large sites for which control of everything is a big task and user/1 wishes to delegate some work. Also, it is my opinion that permissions should be granted based on the role and activities of the person, not on how often the settings need to be changed. There may be new settings added to the scheduler admin pages in future, so we should not just think about what is on that page as of now.

I would say that setting the authority for the scheduler admin page to 'administer site configuration' is too restrictive, as this permission is unlikely to be given to anyone except user/1 but a secondary admin role is likely to need access to the pages.

I think it is therefore between (1) leaving the perm as is, ie 'access administration pages' which is a drupal standard for giving a cut-down set of tasks for secondary admins, or (2) creating a new permission 'Administer scheduler' which could be granted to the secondary admin role if it exists.
Several contrib modules I am using do have an 'Admin ...' permission, so this would fit in with standard practice, and would be the most flexible.

Jonathan

gpk’s picture

gpk commented

Just to point out that some of us (or maybe I am in a minority of 1) don't use user 1 except for running update.php and troubleshooting, i.e. I treat it a bit like unix root user. I'd also emphasise that 'access administration pages' doesn't actually let you do anything in Drupal core - it's just a prerequisite to being any sort of an admin (part from a content administrator).

TBH maybe it's not worth worrying about this too much at present since there is only one scheduler setting to configure. I was just slightly concerned that anyone who was allowed to access the main admin page would be able to change the scheduler date/time format whether or not it's one of their intended activities. (I wonder if those with administer nodes permission are generally given the 'access admin pages' permission too, so they can get into the admin portal.. otherwise you have to create separate menu items to reveal the admin tasks available to them.) But I don't expect this to be a problem on the sites I am involved with.

eric-alexander schaefer’s picture

eric-alexander schaefer commented

I will look into the open issues this weekend. Pretty busy week...

eric-alexander schaefer’s picture

eric-alexander schaefer commented
Title: "access admin pages" is too permissive for allowing user to change scheduler settings » "access admin pages" is too permissive for allowing user to change sheduler settings

I guess the most flexible permission is "administer scheduler". user/1 can grant/revoke this permission as needed and it is not tied to any other tasks (as "administer nodes"). Committed for D5 & D6.

eric-alexander schaefer’s picture

eric-alexander schaefer commented
Title: "access admin pages" is too permissive for allowing user to change sheduler settings » "access admin pages" is too permissive for allowing user to change scheduler settings
Status: Active » Needs review
eric-alexander schaefer’s picture

eric-alexander schaefer commented
Title: "access admin pages" is too permissive for allowing user to change sheduler settings » "access admin pages" is too permissive for allowing user to change scheduler settings
Status: Needs review » Fixed
jonathan1055’s picture

jonathan1055 commented
Status: Fixed » Needs review
StatusFileSize
new _scheduler.perm_admin.patch.txt377 bytes

Hi Eric,
I reopened this issue because you forgot to add the new permission 'administer scheduler' to the array returned by hook_perm. Here is a patch for it.

Jonathan

eric-alexander schaefer’s picture

eric-alexander schaefer commented
Status: Needs review » Fixed

Stupid me. Commited...

laken’s picture

laken commented
StatusFileSize
new _scheduler.perm_admin.trivial.patch679 bytes

Last patch looks right but commit left out line-ending semicolon. Here's the trivial patch.

eric-alexander schaefer’s picture

eric-alexander schaefer commented

[homer]Noo![/homer]

I will test all manually applied patches even if they worked in a different branch. I will test all manually applied patches even if they worked in a different branch. I will test all manually applied patches even if they worked in a different branch. I will test all manually applied patches even if they worked in a different branch. I will test all manually applied patches even if they worked in a different branch. I will test all manually applied patches even if they worked in a different branch. I will test all manually applied patches even if they worked in a different branch. I will test all manually applied patches even if they worked in a different branch...

Thanks laken!

gpk’s picture

gpk commented

LOL

thanks for the work on this, sorry for the grief it has caused!!

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.