[development] Menu feature -- can we lose this, please?

[Larry Garfield]

I believe what chx is proposing (and he is free to thwack me if I'm wrong) is that if the user doesn't have permission to see "/admin", then they won't see "/admin" in their menu at all.  If they have permission to see /admin/foo, they still won't see /admin in their menu and therefore won't see /admin/foo either.  That makes the logic easier/faster/more sane.  

That necessitates the creation of some sort of generic "see admin section" permission that does nothing but grant permission to "/admin".  A user with that permission and nothing else would get some sort of "Sorry, you're not a real admin, ha ha!" message if they went to /admin.  Something similar would likely be required for the "Create content" page.

Alternatively, I don't know how easy a "meta permission" would be to automate; eg, the permission for /admin is "you have permission on one of the children of this path".  I've not really been keeping up with the new menu system, so chx will have to tell us why I just created 40 hours more work for him with that sentence. :-)

--Larry Garfield

On Tue, 06 Mar 2007 10:50:49 -0500, Andre Molnar <mcsparkerton at yahoo.co.uk> wrote:
> Derek Wright wrote:
>>
>> On Mar 5, 2007, at 3:22 PM, Larry Garfield wrote:
>>
>>> I don't think that "in order to access A/B/C you need permission to
>>> access A/B and A, too" is an unreasonable restriction.  The magic
>>> flattening always bugged me from a UI perspective, honestly.
> 
> If user has permission to see 'admin > foo' and only 'admin > foo' user
> does not have access to 'admin' (top level - main callback).  So what
> would the user get when they click on 'admin' in order to make a second
> click to 'foo'?
> 'access denied'?  That can't be good.
> 
> Or do you display 'admin' as a non-clickable menu item - already
> expanded to display 'foo'?
> 
> andre