[Proposal] Admin targeted applications should be available in the Administration

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

[Proposal] Admin targeted applications should be available in the Administration

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 [1].

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).
- 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
entry.

Note:
- 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,
Caty


[1] http://xwiki.markmail.org/thread/romxz7iylujslg36
Reply | Threaded
Open this post in threaded view
|

Re: [Proposal] Admin targeted applications should be available in the Administration

Ecaterina Moraru (Valica)
On Mon, Feb 12, 2018 at 2:48 PM, Ecaterina Moraru (Valica) <
[hidden email]> wrote:

> 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 [1].
>
> 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).
> - 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
> entry.
>

+ mark pages as hidden.


>
> Note:
> - 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,
> Caty
>
>
> [1] http://xwiki.markmail.org/thread/romxz7iylujslg36
>
Reply | Threaded
Open this post in threaded view
|

Re: [Proposal] Admin targeted applications should be available in the Administration

vmassol
Administrator
In reply to this post by Ecaterina Moraru (Valica)

> On 12 Feb 2018, at 13:48, Ecaterina Moraru (Valica) <[hidden email]> wrote:
>
> 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 [1].
>
> 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).
> - 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
> entry.
>
> Note:
> - 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,

Obviously +1 from me ;)

Thanks
-Vincent

> Caty
>
>
> [1] http://xwiki.markmail.org/thread/romxz7iylujslg36

Reply | Threaded
Open this post in threaded view
|

Re: [Proposal] Admin targeted applications should be available in the Administration

Ecaterina Moraru (Valica)
In reply to this post by Ecaterina Moraru (Valica)
On Mon, Feb 12, 2018 at 2:48 PM, Ecaterina Moraru (Valica) <
[hidden email]> wrote:

> 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 [1].
>
> 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).
> - 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.
>

FlamingoThemes also fall into this category, so they should be integrated
in Administration, but they didn't had AppBar entries. FTR there was an
older / deprecated proposal about this
http://design.xwiki.org/xwiki/bin/view/Improvements/ColorThemesProposal

Maybe some other apps are missing from this list.

Thanks,
Caty


>
> 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
> entry.
>
> Note:
> - 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,
> Caty
>
>
> [1] http://xwiki.markmail.org/thread/romxz7iylujslg36
>
Reply | Threaded
Open this post in threaded view
|

Re: [Proposal] Admin targeted applications should be available in the Administration

Marius Dumitru Florea
In reply to this post by Ecaterina Moraru (Valica)
On Mon, Feb 12, 2018 at 2:48 PM, Ecaterina Moraru (Valica) <
[hidden email]> wrote:

> 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 [1].
>
> 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
> entry.
>
> Note:
> - 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,
> Caty
>
>
> [1] http://xwiki.markmail.org/thread/romxz7iylujslg36
>
Reply | Threaded
Open this post in threaded view
|

Re: [Proposal] Admin targeted applications should be available in the Administration

Thomas Mortagne
Administrator
In reply to this post by Ecaterina Moraru (Valica)
On Mon, Feb 12, 2018 at 1:48 PM, Ecaterina Moraru (Valica)
<[hidden email]> wrote:

> 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 [1].
>
> 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).
> - 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.

I don't really agree about this one. This is (currently) restricted to
user with PR for security reason but I don't really see it as an
administration tool.

> 10. Flash Messages Application - move to Administration, remove the AppBar
> entry.
>
> Note:
> - 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,
> Caty
>
>
> [1] http://xwiki.markmail.org/thread/romxz7iylujslg36



--
Thomas Mortagne
Reply | Threaded
Open this post in threaded view
|

Re: [Proposal] Admin targeted applications should be available in the Administration

Ecaterina Moraru (Valica)
In reply to this post by Marius Dumitru Florea
On Wed, Feb 14, 2018 at 11:55 AM, Marius Dumitru Florea <
[hidden email]> wrote:

> On Mon, Feb 12, 2018 at 2:48 PM, Ecaterina Moraru (Valica) <
> [hidden email]> wrote:
>
> > 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 [1].
> >
> > 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.
>
>
First of all I want to have all the related apps in one place, and that is
Administration. We should use configurableClass and includes and let the
Admin navigate through all the applications that are needed for him to
configure the wiki. There is no way he would know that he needs to go in
some apps from AppBar, but in the others (like in the case of Menu app).

Now I agree some applications might have other users involved. For that we
have the dedicated spaces. I didn't said that we need to protect Icon
Themes with Admin rights. But from Administration you should be able to
navigate and even better have the UI included there. If someone wants to
create Panels, know where they are and have rights on them, go create them.
So Administration should not be the only UI to manage the entries, but
should incorporate them.

Currently we don't have any link towards IconThemes management, we have no
link / inclusion towards Menus. We have a link towards Panels, but we break
the context when we are navigating there.

Thanks,
Caty


>
> > - 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
> > entry.
> >
> > Note:
> > - 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,
> > Caty
> >
> >
> > [1] http://xwiki.markmail.org/thread/romxz7iylujslg36
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: [Proposal] Admin targeted applications should be available in the Administration

Ecaterina Moraru (Valica)
In reply to this post by Thomas Mortagne
On Mon, Feb 19, 2018 at 1:32 PM, Thomas Mortagne <[hidden email]>
wrote:

> On Mon, Feb 12, 2018 at 1:48 PM, Ecaterina Moraru (Valica)
> <[hidden email]> wrote:
> > 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 [1].
> >
> > 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).
> > - 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.
>
> I don't really agree about this one. This is (currently) restricted to
> user with PR for security reason but I don't really see it as an
> administration tool.
>

I've added this application in the list since it's Recommended. To be sure,
I don't really know what it does. Maybe is intended for developers, but if
that is the case, it should not be Recommended.
If this is not intended for Admins, than it certainly is not for users.
Users with PR are a very special kind of users. So maybe we need to discuss
the target for this app.

Administration should contain admin related apps, while AppBar should
contain normal user related apps. For Developers it's problematic since
expect advanced profiles and access rights for them.

Thanks,
Caty


>
> > 10. Flash Messages Application - move to Administration, remove the
> AppBar
> > entry.
> >
> > Note:
> > - 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,
> > Caty
> >
> >
> > [1] http://xwiki.markmail.org/thread/romxz7iylujslg36
>
>
>
> --
> Thomas Mortagne
>
Reply | Threaded
Open this post in threaded view
|

Re: [Proposal] Admin targeted applications should be available in the Administration

vmassol
Administrator


> On 21 Feb 2018, at 15:04, Ecaterina Moraru (Valica) <[hidden email]> wrote:
>
> On Mon, Feb 19, 2018 at 1:32 PM, Thomas Mortagne <[hidden email]>
> wrote:
>
>> On Mon, Feb 12, 2018 at 1:48 PM, Ecaterina Moraru (Valica)
>> <[hidden email]> wrote:
>>> 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 [1].
>>>
>>> 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).
>>> - 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.
>>
>> I don't really agree about this one. This is (currently) restricted to
>> user with PR for security reason but I don't really see it as an
>> administration tool.
>>
>
> I've added this application in the list since it's Recommended. To be sure,
> I don't really know what it does. Maybe is intended for developers, but if
> that is the case, it should not be Recommended.
> If this is not intended for Admins, than it certainly is not for users.
> Users with PR are a very special kind of users. So maybe we need to discuss
> the target for this app.
>
> Administration should contain admin related apps, while AppBar should
> contain normal user related apps. For Developers it's problematic since
> expect advanced profiles and access rights for them.

The Filter stream app is not for developers, it’s for admins (they’re the main target - All apps can always have uses not for admins but we’re talking about default here since in the proposal it’s possible for an admin to make them avail for non admins).

Thanks
-Vincent

>
> Thanks,
> Caty
>
>
>>
>>> 10. Flash Messages Application - move to Administration, remove the
>> AppBar
>>> entry.
>>>
>>> Note:
>>> - 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,
>>> Caty
>>>
>>>
>>> [1] http://xwiki.markmail.org/thread/romxz7iylujslg36
>>
>>
>>
>> --
>> Thomas Mortagne