IMO configurations and admin stuff should be all in one place. If we don't
have a central location for them, they will not be discoverable. Also Admin
might see them (because of the Rights object provided) but not know they
are intended only for Admins.

Same for Panels. Not really sure why Panels.WebHome is accessible to
everyone. Even if you create a new panel, you need admin rights to use it
and display it. Now, admins can be global or space admin, but still, the
creation and enabling of panels is done though the WebPreferences.

We now can add entries in each of the Administration menu categories. We
also have the search in Administration. We just need to integrate them in
the right location and provide a flow.

I agree Menus and Panels are confusing, since they kind of do the same
thing. Panels are very technical since you need to write code, so the
difference Menu brought was the "easiness" to create them, using the list
syntax. Now, user are expecting even simpler interactions to create menus.
Most of them wanted drag&drop for the entries, listing the available
entries (scalability problems) and visual ways of creating them. Not to
mention the which is also listed
as P1.

On Mon, Feb 12, 2018 at 12:15 PM, Vincent Massol <> wrote:

> Hi,
> Some thoughts:
> * On
> IdeaMenuInAdministration#HProposals I see: "Users confuse Panels and
> Menus. Since creating the navigation is an Admin activity, they expect
> Menus to be in Administration.”
> ** It's not that user confuse them, it’s that they’re confusing! :) The
> fact that you create Panels with Menus and that you can also create Panels
> manually is also confusing. We need to decide what we want to promote and
> explain a lot better when one should be used vs the other. If the Menu app
> was limited to creating Menus the difference would be much simpler. Panels
> app for panels and Menu app for menus. IMO we may need to reintegrate some
> of the features of the menu app inside the panel app instead.
> ** "they expect Menus to be in Administration”. This is a discussion we’ve
> been having for a long time. Right now the strategy is NOT to do this but
> instead to make the Admin apps visible only to admins. I just noticed that
> the Menu app is visible to *everyone* by default. That’s wrong IMO. It
> should have default permissions to be visible to Admins only *by default*
> (admins could change that if they want), similar to Scheduler, Stats,
> Panels, etc.
> ** I’m ok to have a section in the Admin that lists all Admin apps (as a
> shortcut) if we think that’s useful, but it should only contain links to
> those apps and those apps should also be listed in the App Index. This
> allows Admins to change permissions for them, for ex if they want to allow
> such group of users the ability to create menus, etc.
> So I wouldn’t fold the Menu app itself in the Admin UI for now for
> consistency reason, OR we need to decide that we want to move all Admin
> apps to the Admin UI (and thus remove the use case I mentioned above of
> being able to give permissions to some users or groups to use them).
> Thanks
> -Vincent
> > On 9 Feb 2018, at 15:25, Ecaterina Moraru (Valica) <>
> wrote:
> >
> > Hi,
> >
> > This mail is also part of the Usability priorititzation list [1]
> >
> > Admins expect to manage custom navigation from the Administration.
> >
> > This proposal integrates the Menu application in Administration, see
> >
> IdeaMenuInAdministration#HProposals
> >
> > Let me know what you think,
> > Caty
> >
> > [1]
> >
> Tasks5/Prioritization/

Reply via email to