Closed (fixed)
Project:
Drupal core
Version:
7.x-dev
Component:
user.module
Priority:
Normal
Category:
Bug report
Assigned:
Unassigned
Issue tags:
Reporter:
Created:
30 Jan 2010 at 15:12 UTC
Updated:
3 Jan 2014 at 01:08 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #1
catchComment #2
mr.baileysMarked #697950: Make Permissions one-click from People as a duplicate.
Comment #3
mr.baileysPatch & screenshot attached.
Comment #4
flickerfly commentedsub
Comment #5
moshe weitzman commentedI support this. Subscribe.
Comment #6
Bojhan commentedSo, I talked about this with Dries and actually discussed this in length before many times. The reason it was put up there, because People is sort of an entity for other objects to be attached to. For example, events - showing as a tab on People.
This paradigm would go up, if we treat entities in their own right in the IA. But sadly we don't, given that the events as a tab is also kind of an edge case.
So if we move Permissions, there are couple of next steps to take "Roles" should be a secondary navigation item to Permissions.
And on the Configuration page, we need to move out "Permissions "Roles", and rename the category to People.
Comment #7
mr.baileysRerolled to take Bojhan's comments into account.
Comment #8
webchickCould we get screenshots of the latest patch?
And +1,000,000 for this change. :P From the "old" new IA ;), the modules page and the permissions page were the two top ones that no one could ever find. We moved modules to top-level, and since then I've seen no complaints about finding it. If we move permissions up to "People" I think that will eliminate 90% of the grief people give the new IA.
(As a side note, I think it's awesome that of all the re-jiggering of pages we did this release, there were really only two that a wide swath of the population had problems with. Bravo!)
Comment #9
mr.baileysScreenshots attached, one of the trimmed and renamed "People" section on the configuration page, and one of the extended people section.
Comment #10
webchickThat looks fine to me. Let's get final approval from yoroy/Bojhan.
Comment #11
yoroy commentedI support this. Having People/Permissions next to each other as tabs is a handy thing. Roles as a sub of permissions is great too, it's a very likely next destination.
Only thing that worries me (just a) bit is that we now use 'People' as a label twice in different contexts. I guess for now that's ok, better to keep a clear relation than forced renaming of the Category ("More people"? ;-) "Accounts"?)
Comment #12
Bojhan commentedOk, RTBC
We can open a new issue to discuss the label, I am unsure as we obviously named this People keeping in mind that a lot of modules would add their module under People and thats still appropriate.
Comment #13
webchickAwesome, thanks folks!
Committed to HEAD!
Comment #14
Noyz commentedI support this too. I definitely think its better, given that permissions is buried without this patch.
However, one major nit I have is that we need a more clear definition of tab use. For example, under Content, tabs are used to splice different kinds of content. Under Appearance, tabs are not splicing different kinds of themes. The same is true for Modules. And now, the same is true for People. Seems the most common use of tabs is to splice methods of managing (List view/manage stuff in the list). I'm not sure there's time to flush out a comprehensive solution for this, but it's definitely an itch of mine for d8.
Comment #15
yoroy commentedAgreed. We split out the main actions ('Add') from the tabs and made them links, aligned to the left. Remaining tabs are still a mixed bag. I think we're looking at D8 for that indeed.
Comment #16
berdirOne broken test less!
While the path has been changed, the test tried to assert that the title of the page is Permissions, which isn't the case anymore. Changed to the first permission on that patch, I don't think that shows up anywhere else. I'm open for other ideas though.
Comment #17
webchickWell, the other test was more granular, since it was testing for that string in the title. This one checks for it anywhere.
It's a pretty stupid test though. :P
Comment #18
berdirThe new patch looks for an active link to admin/people/permissions, that is displayed in form of the 2nd level local task.
Chx also suggested to remove the assert completely as it doesn't test much.
Comment #19
webchickThat works! Committed to HEAD.
Comment #20
berdirOk, the above patch as crap and only works when drupal is not installed inside a subdirectory.
This is better, thanks DamZ!
Comment #21
damien tournoud commentedThanks Berdir. Let's fix the test bot :)
Comment #22
webchickCommitted to HEAD!
Comment #23
damien tournoud commentedSorry, I'm not sure what I was thinking, DrupalWebTestCase::getAbsoluteUrl() cannot be used in this context, as it is just an internal function to the internal browser (to handle relative paths in redirects and stuff).
url()is the correct way to do this, and the only way for this to be safe for both clean and normal URLs.Here is a patch.
Comment #24
webchickhaha. third time's a charm? :)
Committed to HEAD!
Comment #25
jhodgdonSee #715972: People section(s) are very confusing.
Comment #26
jhodgdonThis is not really completed.
The menu item descriptions of admin/people and admin/config/people are now wrong. admin/config/people still mentions permissions, and admin/people does not
You can see the latter menu item description in Toolbar (if you have toolbar.module enabled) by hovering over the People menu item. The former can be seen on path "admin".
Comment #27
jhodgdonThere were also several URLs on various pages that are still using the old values.
I'm patching...
Comment #28
jhodgdonHere's a patch. I've verified that all the links on the user module's help page at least now go to the right spot, and I don't think any of the old URLs are in core any more. Descriptions of a few menu items also updated to reflect what's actually in those menu trees.
Comment #29
dries commentedCommitted to CVS HEAD. Thanks.