menu item access level

[ismayil.khayredinov]

Can we explore a possibility of adding an access level (public, logged_in, admin) to the menu items and adding the necessary checks in the menu builder?

[ewinslow]

Not sure how I feel about this. Can you describe a specific use case for me?

[brettp]

I imagine the use case is pretty simple: "Add new blog" is set to "logged_in." The access levels would be the same as actions' and not entities'.

[ewinslow]

In that case, the correct check would actually be $entity->canWriteToContainer(0, 'object', 'blog');.

I think adding an access parameter that takes an enum is not going to be granular enough and will lead to a lot of incorrect uses.

[ismayil.khayredinov]

I was thinking more in terms of 'public', 'logged_in', 'admin'. A simple use case would the 'Administration' menu item - rather than doing have explicit checks in hook handlers, this could be done implicitly in the menu factory

[cash]

Here is an example usage:

For the user avatar menu, we could register all the menu items with these three levels (public, loggedin, admin) and the menu manager handles which items to display. I think right now this is done in the hover view.

This does not handle Evan's case of deciding whether to display a menu item based on the ability to write to a container or write to an entity. That type of logic would still be done before registering the menu item.

[mrclay]

My gut feeling is devs already have enough problems learning the menu API and this doesn't provide a lot of value for the added complexity. How much boilerplate menu code would this remove from most plugins, and would it be clearer to read?

[brettp]

I consider this at the same level as context as far as complexity and legibility. I wouldn't mind seeing it in core.