Menu feature -- can we lose this, please?

Hi,

One of the biggest problems I am facing is a feature that
happened  
somewhat accidentally in the old menu system.

If you give administer comments right to someone and no
other administer  
permission then you will see a 'Comments' link along with
'My account' and  
'Logout'. This 'bubbling' just kills the new system.

So, what about we get rid of it for good? admin,
admin/by-task,  
admin/compact, admin/by-module, admin/logs, admin/help has
access  
administration pages and their children have this
permission, too.  
admin/settings, admin/content, admin/build and admin/user is
currently set  
to administer site configuration . While it has logic in it,
I would like  
to see a permission for the collection pages listed here
which is not used  
anywhere else. Then you give your admin 'see admin pages'
rights which in  
itself does not grant you any admin priviledges and also
administer  
comments. However this comments admin user would see a very
empty  
admin/build page, for example. With a nice message,
probably.

Is this acceptable?

If not, then there are not one but two patches that are able
to address  
this problem. However, the simpler one would slow down D6 to
D5 speeds and  
the more complex one is, erm, a hell lot more complex and I
have not yet  
benched it. See http://d
rupal.org/node/122876#comment-206669 #12 for the  
more complex approach, #15 for the simpler. If we find that
a) the above  
is not acceptable b) the more complex one is needed then I
will need help  
with explaining and commenting the code .

Regards,

NK

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.  

--Larry Garfield

On Mon, 05 Mar 2007 23:15:06 +0100, "Karoly
Negyesi" <karolynegyesi.net> wrote:
> Hi,
> 
> One of the biggest problems I am facing is a feature
that happened
> somewhat accidentally in the old menu system.
> 
> If you give administer comments right to someone and no
other administer
> permission then you will see a 'Comments' link along
with 'My account' and
> 'Logout'. This 'bubbling' just kills the new system.
> 
> So, what about we get rid of it for good? admin,
admin/by-task,
> admin/compact, admin/by-module, admin/logs, admin/help
has access
> administration pages and their children have this
permission, too.
> admin/settings, admin/content, admin/build and
admin/user is currently set
> to administer site configuration . While it has logic
in it, I would like
> to see a permission for the collection pages listed
here which is not used
> anywhere else. Then you give your admin 'see admin
pages' rights which in
> itself does not grant you any admin priviledges and
also administer
> comments. However this comments admin user would see a
very empty
> admin/build page, for example. With a nice message,
probably.
> 
> Is this acceptable?
> 
> If not, then there are not one but two patches that are
able to address
> this problem. However, the simpler one would slow down
D6 to D5 speeds and
> the more complex one is, erm, a hell lot more complex
and I have not yet
> benched it. See http://d
rupal.org/node/122876#comment-206669 #12 for the
> more complex approach, #15 for the simpler. If we find
that a) the above
> is not acceptable b) the more complex one is needed
then I will need help
> with explaining and commenting the code .
> 
> Regards,
> 
> NK

Karoly Negyesi wrote:
> Hi,
> 
> One of the biggest problems I am facing is a feature
that happened 
> somewhat accidentally in the old menu system.
> 
> If you give administer comments right to someone and no
other administer 
> permission then you will see a 'Comments' link along
with 'My account' 
> and 'Logout'. This 'bubbling' just kills the new
system.
> 
> So, what about we get rid of it for good? admin,
admin/by-task, 
> admin/compact, admin/by-module, admin/logs, admin/help
has access 
> administration pages and their children have this
permission, too. 
> admin/settings, admin/content, admin/build and
admin/user is currently 
> set to administer site configuration . While it has
logic in it, I would 
> like to see a permission for the collection pages
listed here which is 
> not used anywhere else. Then you give your admin 'see
admin pages' 
> rights which in itself does not grant you any admin
priviledges and also 
> administer comments. However this comments admin user
would see a very 
> empty admin/build page, for example. With a nice
message, probably.
> 
> Is this acceptable?

I am not sure I am getting what you are saying, but if you
that saying 
that if a user doesn't have access rights to foo he won't
have access 
rights to foo/bar then I am all for it.

Cheers.
	Gerhard

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.

agreed.  i put some stupid code into signup.module to deal
with weird  
UI problems that came from this magic flattening for users
that have  
"administer signups" but not "administer
site" (or whatever it's  
called) perms.  i'd be happy to clean it all up in 6.x if
the  
flattening went away.

and yes, needing to have access to A and A/B to get to A/B/C
seems  
totally reasonable to me, too, especially given the split of
admin  
menu perms into "see admin pages" and "have
admin rights" as  
described by chx's original message...  my only minor
quibble with  
that is that i'm not sure just having "see admin
pages" should give  
you access to the logs.  i could imagine wanting to give a
role  
permission to admin comments, but not necessarily see all
site logs.

-derek

On Tue, 2007-03-06 at 00:26 +0100, Gerhard Killesreiter
wrote:
> Karoly Negyesi wrote:
> > Hi,
> > 
> > One of the biggest problems I am facing is a
feature that happened 
> > somewhat accidentally in the old menu system.
> > 
> > If you give administer comments right to someone
and no other administer 
> > permission then you will see a 'Comments' link
along with 'My account' 
> > and 'Logout'. This 'bubbling' just kills the new
system.
> > 
> > So, what about we get rid of it for good? admin,
admin/by-task, 
> > admin/compact, admin/by-module, admin/logs,
admin/help has access 
> > administration pages and their children have this
permission, too. 
> > admin/settings, admin/content, admin/build and
admin/user is currently 
> > set to administer site configuration . While it
has logic in it, I would 
> > like to see a permission for the collection pages
listed here which is 
> > not used anywhere else. Then you give your admin
'see admin pages' 
> > rights which in itself does not grant you any
admin priviledges and also 
> > administer comments. However this comments admin
user would see a very 
> > empty admin/build page, for example. With a nice
message, probably.
> > 
> > Is this acceptable?
> 
> I am not sure I am getting what you are saying, but if
you that saying 
> that if a user doesn't have access rights to foo he
won't have access 
> rights to foo/bar then I am all for it.
> 
> Cheers.
> 	Gerhard


chx is actually talking about the presentation of menu in
the Navigation
menu, not actual access control, i think. I'm sure chx will
correct me
if I'm wrong.

Right now if you have access to administer comments, but not
to access
administration pages, you see a Comments link at the root
level of the
menu. 

I think permissions to containers should be inferred if you
have access
to the children, just for consistency of navigation. The
click trail to
administer comments should be the same whether you have
access
administration pages or not. 

How hard will it be to support end users if you have all
these
possibilities to get to the 'administer comments' section? 

Developers and power users may realize its usually the same
url, but not
people who are used to desktop apps where 'edit >>
preferences'
consistently gets you to preferences. preferences doesn't
get bumped to
the root of the menu tree if you don't have access to the
edit
container. they just show you the container with the options
you can
access hidden or disabled.

very much like the edit and revisions tabs.

so chx. I very much agree with you, except it would be nice
if
admin/build were completely hidden instead of showing a page
stating I
don't have access to this section.

.darrel.

> so chx. I very much agree with you, except it would be
nice if
> admin/build were completely hidden instead of showing a
page stating I
> don't have access to this section.

That is not impossible, a simple access callback is needed
which would determine whether there is more than one thing
for you on the collection page.

I am so very happy that I can lose the bubbling thing. Next
time I will ask before wasting weeks struggling to implement
something that ends up in the trashcan.

Thanks,

Karoly Negyesi

On 3/5/07, Karoly Negyesi <karolynegyesi.net> wrote:
> > so chx. I very much agree with you, except it
would be nice if
> > admin/build were completely hidden instead of
showing a page stating I
> > don't have access to this section.
>
> That is not impossible, a simple access callback is
needed which would determine whether there is more than one
thing for you on the collection page.

This is what MENU_ITEM_GROUPING does last I checked. It is
used to
show node/add if any children of node/add are visible. I
tried to use
this a long time ago, before the admin menu reorganization,
to remove
the 'access administration pages' permission. The problem I
ran into
was admin/help wanting to be visible if the parent is
visible. I
haven't looked at it recently.

I'd like to see the 'access administration pages' permission
removed,
in favor of showing the top-level admin pages when someone
has access
to any sub-page.

-- 
Neil Drumm
http://delocalizedham.com

> > That is not impossible, a simple access callback
is needed which would determine whether there is more than
one thing for you on the collection page.
> 
> This is what MENU_ITEM_GROUPING does last I checked. 

So true. But if you use that then you need to access check
all it's children. No, thanks. I still prefer the custom
access callback.

Bčr, I don't understand why hierarchical permissions and
role 
permissions can't be mixed. Could you elaborate, and cite
some of the 
sources of wisdom you're alluding to?


Bčr Kessels wrote:
>  Especially because a 
> hierarchical permission system, combined with group
(Drupal calls them roles) 
> based systems is generally considered no-go area;
because: too complex in UI 
> and concept.
>   

-- 
* * * * *
Lullabot's First Ever Advanced Workshops Are Here!
Drupal API & Module Building - Advanced Drupal Themeing
April 9th-13th - Providence, RI
Early Bird Discounts Available Now
http://www.lullabot.
com/training
* * * * *

OP MAANDAG 5 MAART 2007 23:15, SCHREEF KAROLY NEGYESI:
> IS THIS ACCEPTABLE?

I DON'T THINK SO. THIS IS NOT MY PERSONAL OPNION, ITS JUST A
HELICOPTER VIEW 
THINGY:

WHAT YOU ARE PROPOSING IS A HIERARCHICAL PERMISSION SYSTEM
(LIKE THAT OF LDAP) 
TO REPLACE OUR CURRENT NODE (NOT THE DRUPAL NODE, THE REAL
THING) BASED 
PERMISSIONS (LIKE THAT IN *NIX SYSTEMS). OUR NODEBASED (NOT
THE DRUPAL 
NODE!!) PERMISSION SYSTEM HAS WORKED VERY WELL SO FAR.
MOVING THIS TO A 
HIERARCHICAL SYSTEM INVOLVES A LOT MORE THEN MERELY A MENU
REFACTORING. IT IS 
AN ARCHITECTURAL DECICION WITH A GREAT IMPACT ON HOW PEOPLE
(CAN) USE DRUPAL.

WE SHOULD AT LEAST KNOW MORE ABOUT THE SIDE-EFFECTS. BUT
PREFERABLY WE SHOULD 
REALLY KNOW ABOUT THE UNDERLYING CONCEPTS AND PITFALLS.
ESPECIALLY BECAUSE A 
HIERARCHICAL PERMISSION SYSTEM, COMBINED WITH GROUP (DRUPAL
CALLS THEM ROLES) 
BASED SYSTEMS IS GENERALLY CONSIDERED NO-GO AREA; BECAUSE:
TOO COMPLEX IN UI 
AND CONCEPT.

IN GENERAL I WOULD SAY: DON'T GO IN THAT SWAMP, UNLESS YOU
HAVE A GUIDE 
(PERMISSION EXPERT) TO GUIDE YOU.

BčR
-- 
DRUPAL, RUBY ON RAILS AND JOOMLA! DEVELOPMENT: WEBSCHUUR.COM
| DRUPAL HOSTING: 
WWW.SYMPAL.NL