On Mon, Feb 12, 2018 at 2:48 PM, Ecaterina Moraru (Valica) <
> Hi devs,
> The purpose of this mail is to decide on some rules for where admin related
> applications should be located. This mail resulted after a discussion with
> Vincent and it was initially started by the proposal to move Menu
> application inside Administration .
> Some mentions:
> - Admins should have a central place where they could find all the
> applications they can use and are intended for them. Having a central
> location helps discoverability. Administration would be that place.
> - Applications have configurations and actions. All configurations should
> be in Administration. If the actions are targeted only to Administrators,
> they should be listed also in Administration. We will use TABS, one for
> configuration, one for the actions UI (ex Invitation app). If the actions
> are targeted also to Users, than this application should be publicly
> available (ex User Directory).
I don't think it's that simple. Applications also have entries (data) and
the person that creates the data is not always the person that decides how
the data is used. The user that creates the panel, the menu, the tour, the
color theme, the icon theme, the skin etc. could be a content writer, a
designer, a developer and not necessarily the administrator. I find it
strange to have to give administration writes to a designer to allow him to
create a new color theme.
> - These mixed target applications, might have admin dedicated actions
> displayed in place (ex. livetable edit, delete entry. ex. Repository app
> import). This is fine since it preserves the context, not all admin actions
> should be present exclusively in Administration.
> - Application Index should contain only applications that are targeted
> towards normal users. Admins will have Administration as entry point.
> - If the application needs to add special permissions to a group of users,
> these can be added with rights, or provide manual links towards the
> application in a custom menu/panel (ex Stats app providing access to a
> particular user).
> This means several changes for the following applications:
> Bundled apps listed in AppIndex:
> 1. Invitation App - Move the actions (Invitation.WebHome) to
> Administration. Use ConfigurableClass and create a new Tab containing the
> actions. Remove the AppBar entry (UIExtensionClass).
> 2. Panels - move to Administration, remove the AppBar entry.
> 3. Menus - move to Administration, remove the AppBar entry.
> 4. Scheduler - move to Administration, remove the AppBar entry.
> 5. Tour - move to Administration since it contains tour definitions.
> 6. User Index - leave it public, but remove the AppBar entry since there is
> a dedicated Drawer entry.
> Recommended apps:
> 7. Antispam tool app - move to Administration, remove the AppBar entry.
> 8. Nested pages Migrator - move to Administration, remove the AppBar entry.
> 9. Filter Streams Converter Application - move to Administration, remove
> the AppBar entry.
> 10. Flash Messages Application - move to Administration, remove the AppBar
> - In case we might have a lot of applications listed in Administration, we
> might need in the future to reorder them and prioritize some. We might need
> to introduce the concept of Simple / Advanced administration, where in
> Simple we could have just the applications that are mandatory for the
> initial configuration flow. This should be discussed later.
> Let me know what you think,
>  http://xwiki.markmail.org/thread/romxz7iylujslg36