I'm kind of curious if it really makes sense to continue to collect and manage the administrative settings of ldap under the 'People' category. I get that LDAP is a user directory, and users are 'people', and so it makes sense. But, I'd argue that there is a lot more to ldap, and certainly the ldap settings.
for example:
- ldap servers aren't people. Defining them is really a structural part of building a site.
- groups aren't people. but the configuration essentially lives there.
- other ldap entities that might be used and tracked.. conference rooms etc.
It might make more sense if, navigationally, the admin settings were reorganized a bit. I'd suggest the following items:
- Move "servers" and "settings" and "queries" out of people, and create an 'ldap' group under structure where they are actual menu items instead of tabs.
- once ldap entities are defined as per: #1784876: LDAP Server: Provide Generic ldap dn field have an area in admin/structure/ldap for viewing all ldap entities being tracked and a fieldable screen for managing the base ldap entity.
- also per #1784876: LDAP Server: Provide Generic ldap dn field have an ldap_user bundle that is configurable in admin/people/ldap_settings
- reflect this into the respective entities that we'll have ldap support for. (OG, Roles, etc)
- the authentication and authorization work could possibly be moved to local tasks on the user settings page. though that is tough to just discover. adding links directly to it from the ldap screens could solve that though.
I think this will serve a couple of purposes. It will free up tab space for things that need to assign tabs ( I came across this issue while working making entities out of the ldap records). It should also help users intuit where they need to go to do various tasks. Developing a vertical navigation structure will give us room to expand as new tools are developed - such as the entity work that's happening.
Anybody have any thoughts this possible re-org?
-Chris
Comments
Comment #1
johnbarclay commentedAs long as things are cross referenced, a good reorg would make sense. We can work the details out. I would say we should create a 7.x-3.0 branch as a placeholder for things like this, so we don't lose track of them while working toward a 7.x-2.0 release candidate. I have a bunch of tasks related to the alignment of example ldap within the UI, simpletests, documentation, and reference ldap server that I see in 7.x-3.0. Maybe we should also skip the UI simpletest coverage in 7.x-2.0 and put it off until 7.x-3.0?
Comment #2
netw3rker commentedThat's a good plan. I've got some fairly sweeping changes in mind that have been making me nervous about putting into a 2.x. I'll create a 3.x branch & start committing my stuff to that branch.
-Chris
Comment #3
johnbarclay commentedAny progress on this? I'm cleaning up the issue queue and marking this for the next branch.
Comment #4
larowlanno update for > 12 months, no patches - closing