I've made a patch to add a permission "edit programs" -- volunteers on my site are able to edit all posts but only their own programs, which is weird.
However, looking at the code I think the permissions for the program module are a bit strange:
- administer programs -- can create and delete
- edit own program -- what it says
Core content types and those added with CCK you get:
- create (type) -- can create nodes of the type
- edit own (type) -- can edit and delete own nodes of the type
- edit (type) -- can edit and delete all nodes of the type
(At least that's what I understand -- if I'm wrong, leave a comment at http://drupal.org/node/132202 ;)
I'd like to bring the station module in line with this scheme and I'm happy to provide a new patch to do all this. But I'm still very new to drupal coding -- is it safe to change the name of the permission 'administer programs'?
(In which case, I'd make 'edit own program' plural while I'm at it.)
| Comment | File | Size | Author |
|---|---|---|---|
| #5 | station_132895_1.patch | 2.96 KB | drewish |
| #4 | station_132895_0.patch | 1.62 KB | drewish |
| #3 | station_132895.patch | 3.87 KB | drewish |
| edit program permission.patch | 722 bytes | joachim |
Comments
Comment #1
drewish commentedcreate and delete permission is handled separately because deleting a program would effectively remove it from the schedule. it does make sense to have a separate edit programs permission to allow an intermediate role where users can edit all programs but not their position on the schedule.
Comment #2
joachim commentedAh, I see what you mean about deleting programs.
Isn't scheduling/unscheduling covered by 'administer schedule' permission?
Comment #3
drewish commented[i'll just select schedule so we don't have to keep re-selecting program]
you're right, scheduling (and deleting) should be covered by the administer schedule permissions. i'd be into adopting the new permission names. the attached patch should do this but it needs an update migrate the permissions. i need to dig around and see if i can find some code in someone else's module.
Comment #4
drewish commentedhere's a re-roll that applies cleanly. i'm wondering though if we need to have both the 'edit program content' and 'administer programs' permissions.... thoughts?
Comment #5
drewish commentedcommitting the attached to DRUPAL-5.
Comment #6
drewish commentedbetter title
Comment #7
(not verified) commentedComment #8
joachim commentedI'm looking at this again as I'm once again at the point of looking at permissions for users on my site...
> i'm wondering though if we need to have both the 'edit program content' and 'administer programs' permissions.... thoughts?
'administer programs' could be renamed 'create program content' to bring it in line with permission names from core.
I think the way 'administer schedule' works with 'create program content' could be changed: I think 'administer schedule' should override 'create program content', but only the user has that right.
In other words, if user Joe can't create programs, but can administer the schedule, let him create programs anyway. But if he can't administer the schedule, let him create programs (they don't affect the schedule, they just . The two rules should be ORed is what I'm trying to say, I think, whereas currently 'administer schedule' takes absolute precedence if the schedule module exists.
I wasn't sure about the usefulness of making this change, and was about to say so, but I've talked myself into seeing its purpose: suppose new DJ Susan has a new show. I don't want her to mess with the schedule, but I want her to be able to edit her own show page. With the current system, I have to create the page first, assign her authorship, then let her find it and edit it, then I schedule it. If she can create a program node, then one step is removed from the process.
PS. I need to document these in the handbook :)
Comment #9
drewish commentedjoachim, i'd be open to adding a "create program content" permission... but they wouldn't be able to delete the programs... humm this should probably be moved to a new issue. respectfully re-closing this one.