we already have the functionality for the per-role permission pages (e.g. http://drupal.org/node/105698). however, in 4.7.x, on the main access control page (/admin/access, what's now /admin/user/access in 5.x), the role names as the column header labels where themselves links to the per-role permission pages. this was a handy feature, and it seems a little counter-intuative to have to go to the separate /admin/user/roles page to find these links again.
why not just provide the links in both places?
| Comment | File | Size | Author |
|---|---|---|---|
| #5 | user_role_name_links.patch_1.txt | 993 bytes | dww |
| #4 | edit_this_role_only.png | 106.79 KB | dww |
| #1 | user_role_name_links.png | 133.93 KB | dww |
| user_role_name_links.patch.txt | 903 bytes | dww |
Comments
Comment #1
dwwscreenshot
Comment #2
ChrisKennedy commentedWorks great.
This feature was removed by http://cvs.drupal.org/viewcvs/drupal/drupal/modules/user/user.module?r1=...
Comment #3
drummUsually when a table header is clicked, the table sorts. Do we have a good reason for breaking convention here? What could be done to visually distinguish this as something different?
Comment #4
dwwa) this is existing behavior from (at least) 4.7.x, so it's not like we're introducing it here. ;)
b) i probably have the wrong perspective, but i can't even imagine how sorting by role name would work. i mean, i know that's the default behavior in other tables, but i'm not sure how anyone *could* be confused by thinking it would sort in this case.
c) we could certainly provide a mouse-over message explaining what happens, that'd be a no-brainer i should have done in the first place. ;)
d) if we wanted to waste a little screen real-estate at the top, we could so something kludgy like have the role name not as a link, but have it generate a
<br/>and a link called "edit this role only" or something that linked to the separate page. something like the attached screenshot. personally, i think this sucks... i'm just brainstorming here. ;) maybe someone will come up with better wording and a better implementation "inspired" by this crappy first attempt.in short, i think the "good reason for breaking convention" is that the role name as a link is the smallest, cleanest, and (IMHO) most intuitive way to give people access to a role-specific view of this data. in that sense, it still matches our convention -- when you click on the header, you see a view of the data/UI specific to that header. in many tables, we sort, in this table, we filter-out/hide everything else. the basic principle is the same...
thanks for being diligent on making this rather difficult UI in drupal as reasonable as can be...
-derek
p.s. here's that evil screenshot, just for discussion. ;)
Comment #5
dwwhere's a patch with the mouse-over title stuff. is this enough? any way we can make this UI any better at this stage in the game? the minor downside of this is that it's a new string to translate. :( if we don't want to change that at this stage, we're back to the original patch unless someone comes up with any better approaches.
thanks,
-derek
Comment #6
dries commentedThe functionality was removed with good reason -- the UI was confusing, and only a handful of people knew about the functionality. Re-introducing this functionality is not an option, unless it looks fundamentally different. The screenshot in #4 looks ugly, and is inconsistent with the rest of Drupal. I think we need to experiment some more with different UIs to make this work properly.
Definitely needs more work.
Comment #7
Anonymous (not verified) commentedOne of the thoughts I had today on the Access Control form is that it should be removed from the menu list. We have the Role form which has an Edit Permissions link for each individual role. I suggest that this Role form be modified to include check boxes to select the roles with a check all link at the top and a "Edit permissions of selected roles" link near the bottom" that would open a form similar to the Access Control form now but with a name change. This allows simplification of the administration menu, removes a confusion point being discussed, and gives the user greater control on just which roles need to have the permissions changed.
Comment #8
RobRoy commentedPlease don't hijack issues. Open another issue. Thanks.
Comment #9
Anonymous (not verified) commentedSorry the fine print Note didn't catch my eye. Consider me taught.
Still though my comment has merit in this conversation because we are both attacking the access control form. Any comment on my suggestion? Since the Role form already has a link to "edit permissions" for the individual role and since Dries has already stated that the change to the access control form was purposeful I came up with an alternate method that I thought I would share.
Comment #10
dwwthe point of "please don't hijack issues" isn't just about changing the title... your suggestion potentially has merit, but it doesn't directly have much to do with what i'm proposing here. if my specific request (to restore the functionality where the access control grid gives you a 1-click way to edit perms only for a certain role) is going to be marked "won't fix", so be it. but, this thread isn't about the Grand Unified Vision for the permissions/access UI, and every possible solution. if you've got better ideas, please submit them as separate issues. feel free to add a comment in here "another approach to fixing this UI is at http://drupal.org/node/xxxxx". then, if this gets killed (as seems likely), your issue won't necessarily be killed along with it.
cheers,
-derek
Comment #11
tstoecklerThis is won't fix per #6.