[xwiki-devs] [Discussion] About hidden applications and how we find them
Hi, XWIKI-7568 <http://jira.xwiki.org/browse/XWIKI-7568> - Implement mechanism to hide technical content added some big changes for me in the way we organize things inside XWiki, what we consider to be hidden or not and how we reach hidden applications. As a first visible change, now the Spaces gadget found on Main.WebHome doesn't display anymore spaces like 'AnnotationCode', 'ColorThemes', 'Invitation', 'Panels', 'Scheduler', 'Stats'. My main concern is that if something is not visible and accessible it will never be used and thus it doesn't exists. That's why I've created: XWIKI-7916 <http://jira.xwiki.org/browse/XWIKI-7916> - Integrate ColorThemes functionality inside Administration XWIKI-7920 <http://jira.xwiki.org/browse/XWIKI-7920> - Integrate Scheduler functionality inside Administration XWIKI-7919 <http://jira.xwiki.org/browse/XWIKI-7919> - Create an entry point for Stats inside Administration XWIKI-7918 <http://jira.xwiki.org/browse/XWIKI-7918> - Have an entry point for the Invitation application While some functionality may seem normal to be Admin only (also because some of the hidden spaces were about configuration), some is arguable: - 'ColorThemes' initially were supposed to be used also by normal users in their profile but this didn't made it in final implementation; - makes sense that maybe a normal user could create a 'Panel' but right now this is not possible from Panels.WebHome; - Invitation should be able to be used by both types of users, but without the setting of the server mail, the users will always receive an error; - Stats again could be used by both. What I would like is that things that are about configuration should always be integrated in the Administration. I am referring to the Scheduler configuration, Stats configuration, Search Suggest configuration, etc. The logic behind is that the Administration acts like an entry point for any configuration related actions. As Admin I shouldn't go outside Administration in order to achieve my configuration task (ex. XWIKI-7917<http://jira.xwiki.org/browse/XWIKI-7917> XWIKI-7921 <http://jira.xwiki.org/browse/XWIKI-7921> etc. ). Now adding configuration inside Administration still doesn't solve the problem on the entry point. As an administrator, after I've completed the configuration step, where do I find the application? As a normal user is the same question + how do I even know that applications exists? For this issue I've created XWIKI-7927 <http://jira.xwiki.org/browse/XWIKI-7927> - Create an entry point for all available applications inside the wiki This can be implemented as a gadget, as a panel or even as an Application Index (as a livetable or as a grid). Now another problem remaining is that of specifying if an application is intended for Advanced, Simple users or both. Who should see Stats app? All the users? Just advanced users? As a first step, the hidden feature works because 'advanced' applications will be considered 'hidden' for users. The problem is what we consider 'advanced' to mean. Is ColorThemes or Stats an advanced application? And is especially problematic since by default the Administrator has an 'advanced' + 'hidden' configuration, meaning that he will not be able to see by default ColorThemes or other configuration (but currently hidden) application that might be useful for him (he needs to know that the functionality exists somewhere). So he is an 'advanced' user that doesn't have visibility to 'advanced' applications. So IMO the hidden mechanism is great for hiding technical pages (pages like *Sheet, *Template, Macros, internal pages, etc.) from users. It doesn't matter if those pages exist (from an user's point of view) as long as there is an UI that integrates them. The bad part of the current status of the 4.1RC1 is that IMO we should not consider entire applications to be hidden. Internal pages of the 'Invitation' app should be hidden, but the WebHome (that contains the functionality and the UI) should be available/discoverable somewhere. In order for 'advanced' applications to not be displayed for normal users we should have another field that describes the application and this can be 'simple' or 'advanced' (and not rely just on the 'hidden'). XWIKI-7925 <http://jira.xwiki.org/browse/XWIKI-7925> - Have application descriptors for Application spaces So the only problem remaining (besides the actual implementation :) ) would be to discuss what applications are advanced (or even admin only) and what are not (thus available to the general population). Keep in mind that the current separation is now simple/advanced but we might need a user/developer/admin separation in order to better separate the task functionality of our current applications scopes (ex. since we might want to have admins only applications that should not be available to developers, both being advanced users). Thanks, Caty
Hi Caty, here's my feedback regarding this. On Fri, Jun 15, 2012 at 3:53 PM, Ecaterina Moraru (Valica) < [email protected]> wrote:
Hi,
XWIKI-7568 <http://jira.xwiki.org/browse/XWIKI-7568> - Implement mechanism to hide technical content added some big changes for me in the way we organize things inside XWiki, what we consider to be hidden or not and how we reach hidden applications.
As a first visible change, now the Spaces gadget found on Main.WebHome doesn't display anymore spaces like 'AnnotationCode', 'ColorThemes', 'Invitation', 'Panels', 'Scheduler', 'Stats'. My main concern is that if something is not visible and accessible it will never be used and thus it doesn't exists.
+1
That's why I've created: XWIKI-7916 <http://jira.xwiki.org/browse/XWIKI-7916> - Integrate ColorThemes functionality inside Administration XWIKI-7920 <http://jira.xwiki.org/browse/XWIKI-7920> - Integrate Scheduler functionality inside Administration XWIKI-7919 <http://jira.xwiki.org/browse/XWIKI-7919> - Create an entry point for Stats inside Administration XWIKI-7918 <http://jira.xwiki.org/browse/XWIKI-7918> - Have an entry point for the Invitation application
Sounds good, that would definitely be useful. While some functionality may seem normal to be Admin only (also because
some of the hidden spaces were about configuration), some is arguable: - 'ColorThemes' initially were supposed to be used also by normal users in their profile but this didn't made it in final implementation;
I'd say color themes should be an admin-only feature. Organizations usually want to enforce a consistent look & feel for internal and external tools. Color Themes are a great way to let them achieve this.
- makes sense that maybe a normal user could create a 'Panel' but right now this is not possible from Panels.WebHome;
For the same reason as above, I don't think this action should be available to users that are not administrators (or developers).
- Invitation should be able to be used by both types of users, but without the setting of the server mail, the users will always receive an error;
Yes, the invitation application should be more discoverable. The way it's made visible in XWiki Cloud could be a good source of inspiration.
- Stats again could be used by both.
I don't really agree, see below.
What I would like is that things that are about configuration should always be integrated in the Administration. I am referring to the Scheduler configuration, Stats configuration, Search Suggest configuration, etc. The logic behind is that the Administration acts like an entry point for any configuration related actions. As Admin I shouldn't go outside Administration in order to achieve my configuration task (ex. XWIKI-7917<http://jira.xwiki.org/browse/XWIKI-7917> XWIKI-7921 <http://jira.xwiki.org/browse/XWIKI-7921> etc. ).
I strongly agree with this. Now adding configuration inside Administration still doesn't solve the
problem on the entry point. As an administrator, after I've completed the configuration step, where do I find the application? As a normal user is the same question + how do I even know that applications exists?
For this issue I've created XWIKI-7927 <http://jira.xwiki.org/browse/XWIKI-7927> - Create an entry point for all available applications inside the wiki This can be implemented as a gadget, as a panel or even as an Application Index (as a livetable or as a grid).
Your proposal of an "app bar" on the left of all pages was a nice solution to this issue. Now another problem remaining is that of specifying if an application is
intended for Advanced, Simple users or both. Who should see Stats app? All the users? Just advanced users?
From the use cases I see within organizations, I'd say only admins should be able to access Statistics. Stats are sensitive information that admins use to monitor activity on the wiki and take action. For instance, you don't necessarily want all your users to know that the "important procedures" space is never looked at by anyone.
As a first step, the hidden feature works because 'advanced' applications will be considered 'hidden' for users. The problem is what we consider 'advanced' to mean. Is ColorThemes or Stats an advanced application? And is especially problematic since by default the Administrator has an 'advanced' + 'hidden' configuration, meaning that he will not be able to see by default ColorThemes or other configuration (but currently hidden) application that might be useful for him (he needs to know that the functionality exists somewhere). So he is an 'advanced' user that doesn't have visibility to 'advanced' applications.
OTOH functional admins without technical knowledge are often surprised to see "technical" spaces and pages on the homepage of the wiki. So IMO the hidden mechanism is great for hiding technical pages (pages like
*Sheet, *Template, Macros, internal pages, etc.) from users. It doesn't matter if those pages exist (from an user's point of view) as long as there is an UI that integrates them. The bad part of the current status of the 4.1RC1 is that IMO we should not consider entire applications to be hidden. Internal pages of the 'Invitation' app should be hidden, but the WebHome (that contains the functionality and the UI) should be available/discoverable somewhere.
+1, but only provided there's an user-friendly interface for those apps.
In order for 'advanced' applications to not be displayed for normal users we should have another field that describes the application and this can be 'simple' or 'advanced' (and not rely just on the 'hidden'). XWIKI-7925 <http://jira.xwiki.org/browse/XWIKI-7925> - Have application descriptors for Application spaces
Applications descriptors are more and more needed, especially with the arrival of a fully functional extension manager in the coming releases. So the only problem remaining (besides the actual implementation :) ) would
be to discuss what applications are advanced (or even admin only) and what are not (thus available to the general population). Keep in mind that the current separation is now simple/advanced but we might need a user/developer/admin separation in order to better separate the task functionality of our current applications scopes (ex. since we might want to have admins only applications that should not be available to developers, both being advanced users).
I agree that the user / admin / dev separation would be better than the simple user / advanced user separation that we currently have. Guillaume Thanks,
Caty _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Hi Caty and all, On Jun 15, 2012, at 3:53 PM, Ecaterina Moraru (Valica) wrote:
Hi,
XWIKI-7568 <http://jira.xwiki.org/browse/XWIKI-7568> - Implement mechanism to hide technical content added some big changes for me in the way we organize things inside XWiki, what we consider to be hidden or not and how we reach hidden applications.
As a first visible change, now the Spaces gadget found on Main.WebHome doesn't display anymore spaces like 'AnnotationCode', 'ColorThemes', 'Invitation', 'Panels', 'Scheduler', 'Stats'. My main concern is that if something is not visible and accessible it will never be used and thus it doesn't exists.
That's why I've created: XWIKI-7916 <http://jira.xwiki.org/browse/XWIKI-7916> - Integrate ColorThemes functionality inside Administration XWIKI-7920 <http://jira.xwiki.org/browse/XWIKI-7920> - Integrate Scheduler functionality inside Administration XWIKI-7919 <http://jira.xwiki.org/browse/XWIKI-7919> - Create an entry point for Stats inside Administration XWIKI-7918 <http://jira.xwiki.org/browse/XWIKI-7918> - Have an entry point for the Invitation application
While some functionality may seem normal to be Admin only (also because some of the hidden spaces were about configuration), some is arguable: - 'ColorThemes' initially were supposed to be used also by normal users in their profile but this didn't made it in final implementation; - makes sense that maybe a normal user could create a 'Panel' but right now this is not possible from Panels.WebHome; - Invitation should be able to be used by both types of users, but without the setting of the server mail, the users will always receive an error; - Stats again could be used by both.
What I would like is that things that are about configuration should always be integrated in the Administration. I am referring to the Scheduler configuration, Stats configuration, Search Suggest configuration, etc. The logic behind is that the Administration acts like an entry point for any configuration related actions.
+1, I agree.
As Admin I shouldn't go outside Administration in order to achieve my configuration task (ex. XWIKI-7917<http://jira.xwiki.org/browse/XWIKI-7917>
I agree for this one since it's about configuration.
XWIKI-7921 <http://jira.xwiki.org/browse/XWIKI-7921> etc. ).
Creating a new panel is not configuration for me. It's like creating a page. Now configuring the whole wiki or a given space to use such panel is configuration.
Now adding configuration inside Administration still doesn't solve the problem on the entry point. As an administrator, after I've completed the configuration step, where do I find the application? As a normal user is the same question + how do I even know that applications exists?
For me all apps should be visible from a single place (app panel) and only the app for which you have rights to should be visible. For example if we decide that the stats apps requires the user to be in a given group to be visible by default (the admin could change that so that everyone can see it or include/exclude some other users/groups) then it should be listed only if my user has the associated permission (view, etc). Knowing what is an app does need to define an application with an app descriptor indeed. A first implementation I had suggested was to map an app to a space. I believe this will work. I also believe that we'll need in the future to be more fine-grained than a space and we may (or not?) want than an app is composed of pages located in lots of different spaces and for this we would need a proper app descriptor.
For this issue I've created XWIKI-7927 <http://jira.xwiki.org/browse/XWIKI-7927> - Create an entry point for all available applications inside the wiki This can be implemented as a gadget, as a panel or even as an Application Index (as a livetable or as a grid).
+1 for an app panel (for me app bar and app panel are the same) at least (we can also have an app index somewhere if we want).
Now another problem remaining is that of specifying if an application is intended for Advanced, Simple users or both. Who should see Stats app? All the users? Just advanced users?
There's no definitive answer here of course. The question is just that of the default configuration for XE. For example some installs will want that only admins can see the stats app while others will allow everyone to see stats. For me we should definitely NOT put the Stats app entry point in the Admin UI. If we do se then we will not be able to allow some installs to let everyone see stats for ex (or people in a given group). For me all apps entry points should be in the app panel. For me the Admin UI should be reserved only for configuration.
As a first step, the hidden feature works because 'advanced' applications will be considered 'hidden' for users. The problem is what we consider 'advanced' to mean. Is ColorThemes or Stats an advanced application?
Creating Color Themes is not for admin for me. I can definitely envision use cases where people other than admins are allowed to create color themes (like people in the designer group for ex). However, again, only admins should be allowed to say that the whole or a given space should use that color theme.
And is especially problematic since by default the Administrator has an 'advanced' + 'hidden' configuration, meaning that he will not be able to see by default ColorThemes or other configuration (but currently hidden) application that might be useful for him (he needs to know that the functionality exists somewhere). So he is an 'advanced' user that doesn't have visibility to 'advanced' applications.
Yep. That''s solved with the single app panel I mentioned + permissions.
So IMO the hidden mechanism is great for hiding technical pages (pages like *Sheet, *Template, Macros, internal pages, etc.) from users. It doesn't matter if those pages exist (from an user's point of view) as long as there is an UI that integrates them.
I agree that we should never mark UI pages as hidden. They should only be "protected" by permissions.
The bad part of the current status of the 4.1RC1 is that IMO we should not consider entire applications to be hidden.
+1
Internal pages of the 'Invitation' app should be hidden, but the WebHome (that contains the functionality and the UI) should be available/discoverable somewhere.
+1
In order for 'advanced' applications to not be displayed for normal users we should have another field that describes the application and this can be 'simple' or 'advanced' (and not rely just on the 'hidden').
We have several options here but IMO the best is to use permissions to tell who should be allowed to view a given app since we already have this mechanism in place for authorization…. No need to reinvent it… Now we have several options to implement this: * Set the permission on the app space WebHome page for ex and only list the app in the app panel if the current user is allowed to view the app space's WebHome * (variation) Have a specially named page in each app on which permission can be set and check if the current user is allowed to view that page and decide accordingly whether to list the app in the app panel or not * Introduce notion of permissions specific to an app. For example have "a stats app permission" and allow groups/users to use that app. Each app would contribute a permission and the permission UI would need to be amended to scale to a large 1 of permissions.
XWIKI-7925 <http://jira.xwiki.org/browse/XWIKI-7925> - Have application descriptors for Application spaces
So the only problem remaining (besides the actual implementation :) ) would be to discuss what applications are advanced (or even admin only) and what are not (thus available to the general population).
The only thing to discuss for me are what default permissions we wish to set in XE. As I mentioned the admin should be able to change those permissions according to the use case at hand. Let's start listing the apps + default permission we could have (note that I'm assuming that we don't want to introduce a new group of users and that we have only normal users and admin users which are the only 2 permission groups we have ATM): - stats: admin group - color theme: admin group - scheduler: admin group - any more? Thanks -Vincent
Keep in mind that the current separation is now simple/advanced but we might need a user/developer/admin separation in order to better separate the task functionality of our current applications scopes (ex. since we might want to have admins only applications that should not be available to developers, both being advanced users).
Thanks, Caty
On Sat, Jun 16, 2012 at 12:04 AM, Vincent Massol <[email protected]> wrote:
Hi Caty and all,
On Jun 15, 2012, at 3:53 PM, Ecaterina Moraru (Valica) wrote:
Hi,
XWIKI-7568 <http://jira.xwiki.org/browse/XWIKI-7568> - Implement mechanism to hide technical content added some big changes for me in the way we organize things inside XWiki, what we consider to be hidden or not and how we reach hidden applications.
As a first visible change, now the Spaces gadget found on Main.WebHome doesn't display anymore spaces like 'AnnotationCode', 'ColorThemes', 'Invitation', 'Panels', 'Scheduler', 'Stats'. My main concern is that if something is not visible and accessible it will never be used and thus it doesn't exists.
That's why I've created: XWIKI-7916 <http://jira.xwiki.org/browse/XWIKI-7916> - Integrate ColorThemes functionality inside Administration XWIKI-7920 <http://jira.xwiki.org/browse/XWIKI-7920> - Integrate Scheduler functionality inside Administration XWIKI-7919 <http://jira.xwiki.org/browse/XWIKI-7919> - Create an entry point for Stats inside Administration XWIKI-7918 <http://jira.xwiki.org/browse/XWIKI-7918> - Have an entry point for the Invitation application
While some functionality may seem normal to be Admin only (also because some of the hidden spaces were about configuration), some is arguable: - 'ColorThemes' initially were supposed to be used also by normal users in their profile but this didn't made it in final implementation; - makes sense that maybe a normal user could create a 'Panel' but right now this is not possible from Panels.WebHome; - Invitation should be able to be used by both types of users, but without the setting of the server mail, the users will always receive an error; - Stats again could be used by both.
What I would like is that things that are about configuration should always be integrated in the Administration. I am referring to the Scheduler configuration, Stats configuration, Search Suggest configuration, etc. The logic behind is that the Administration acts like an entry point for any configuration related actions.
+1, I agree.
As Admin I shouldn't go outside Administration in order to achieve my configuration task (ex. XWIKI-7917<http://jira.xwiki.org/browse/XWIKI-7917>
I agree for this one since it's about configuration.
XWIKI-7921 <http://jira.xwiki.org/browse/XWIKI-7921> etc. ).
Creating a new panel is not configuration for me. It's like creating a page. Now configuring the whole wiki or a given space to use such panel is configuration.
The problem with 'Create panel' functionality is that now it is intended just for Admins. Making all the functionality available in one place is the right thing to do. A similar example is 'Add new user', you have one place where you can manage the users (add, edit, delete). One version would be to let admins create panels just from here, but for this to be valid we should agree that panels are just for admins. Another version would mean just to duplicate this functionality also in the Administration (from productivity and organization reasons) and have it also in the Panels space. The issue mostly relates to the fact that now the default Admin has 'display hidden: true' and will not know from where to create panels, since he will not be able to find that space (without prior knowledge of it).
Now adding configuration inside Administration still doesn't solve the problem on the entry point. As an administrator, after I've completed the configuration step, where do I find the application? As a normal user is the same question + how do I even know that applications exists?
For me all apps should be visible from a single place (app panel) and only the app for which you have rights to should be visible.
For example if we decide that the stats apps requires the user to be in a given group to be visible by default (the admin could change that so that everyone can see it or include/exclude some other users/groups) then it should be listed only if my user has the associated permission (view, etc).
Knowing what is an app does need to define an application with an app descriptor indeed. A first implementation I had suggested was to map an app to a space. I believe this will work. I also believe that we'll need in the future to be more fine-grained than a space and we may (or not?) want than an app is composed of pages located in lots of different spaces and for this we would need a proper app descriptor.
For this issue I've created XWIKI-7927 <http://jira.xwiki.org/browse/XWIKI-7927> - Create an entry point for all available applications inside the wiki This can be implemented as a gadget, as a panel or even as an Application Index (as a livetable or as a grid).
+1 for an app panel (for me app bar and app panel are the same) at least (we can also have an app index somewhere if we want).
Now another problem remaining is that of specifying if an application is intended for Advanced, Simple users or both. Who should see Stats app? All the users? Just advanced users?
There's no definitive answer here of course. The question is just that of the default configuration for XE. For example some installs will want that only admins can see the stats app while others will allow everyone to see stats.
For me we should definitely NOT put the Stats app entry point in the Admin UI. If we do se then we will not be able to allow some installs to let everyone see stats for ex (or people in a given group).
For me all apps entry points should be in the app panel.
For me the Admin UI should be reserved only for configuration.
As a first step, the hidden feature works because 'advanced' applications will be considered 'hidden' for users. The problem is what we consider 'advanced' to mean. Is ColorThemes or Stats an advanced application?
Creating Color Themes is not for admin for me. I can definitely envision use cases where people other than admins are allowed to create color themes (like people in the designer group for ex). However, again, only admins should be allowed to say that the whole or a given space should use that color theme.
And is especially problematic since by default the Administrator has an 'advanced' + 'hidden' configuration, meaning that he will not be able to see by default ColorThemes or other configuration (but currently hidden) application that might be useful for him (he needs to know that the functionality exists somewhere). So he is an 'advanced' user that doesn't have visibility to 'advanced' applications.
Yep. That''s solved with the single app panel I mentioned + permissions.
So IMO the hidden mechanism is great for hiding technical pages (pages like *Sheet, *Template, Macros, internal pages, etc.) from users. It doesn't matter if those pages exist (from an user's point of view) as long as there is an UI that integrates them.
I agree that we should never mark UI pages as hidden. They should only be "protected" by permissions.
The bad part of the current status of the 4.1RC1 is that IMO we should not consider entire applications to be hidden.
+1
Internal pages of the 'Invitation' app should be hidden, but the WebHome (that contains the functionality and the UI) should be available/discoverable somewhere.
+1
In order for 'advanced' applications to not be displayed for normal users we should have another field that describes the application and this can be 'simple' or 'advanced' (and not rely just on the 'hidden').
We have several options here but IMO the best is to use permissions to tell who should be allowed to view a given app since we already have this mechanism in place for authorization…. No need to reinvent it…
Now we have several options to implement this: * Set the permission on the app space WebHome page for ex and only list the app in the app panel if the current user is allowed to view the app space's WebHome
I think this would be the most easy solution to implement, but it doesn't protect at all the data pages inside the app, just the visibility. But I'm sure the devs will find the most approachable solution.
* (variation) Have a specially named page in each app on which permission can be set and check if the current user is allowed to view that page and decide accordingly whether to list the app in the app panel or not * Introduce notion of permissions specific to an app. For example have "a stats app permission" and allow groups/users to use that app. Each app would contribute a permission and the permission UI would need to be amended to scale to a large 1 of permissions.
XWIKI-7925 <http://jira.xwiki.org/browse/XWIKI-7925> - Have application descriptors for Application spaces
So the only problem remaining (besides the actual implementation :) ) would be to discuss what applications are advanced (or even admin only) and what are not (thus available to the general population).
The only thing to discuss for me are what default permissions we wish to set in XE. As I mentioned the admin should be able to change those permissions according to the use case at hand.
Let's start listing the apps + default permission we could have (note that I'm assuming that we don't want to introduce a new group of users and that we have only normal users and admin users which are the only 2 permission groups we have ATM): - stats: admin group - color theme: admin group - scheduler: admin group - any more?
Invitation? Panels? actually all the applications inside XE (blog, sandbox, etc.)
Thanks, Caty
Thanks -Vincent
Keep in mind that the current separation is now simple/advanced but we might need a user/developer/admin separation in order to better separate the task functionality of our current applications scopes (ex. since we might want to have admins only applications that should not be available to developers, both being advanced users).
Thanks, Caty
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Hello, I have a few remarks of my own. Please see below: On Fri, Jun 15, 2012 at 4:53 PM, Ecaterina Moraru (Valica) <[email protected]> wrote:
Hi,
XWIKI-7568 <http://jira.xwiki.org/browse/XWIKI-7568> - Implement mechanism to hide technical content added some big changes for me in the way we organize things inside XWiki, what we consider to be hidden or not and how we reach hidden applications.
As a first visible change, now the Spaces gadget found on Main.WebHome doesn't display anymore spaces like 'AnnotationCode', 'ColorThemes', 'Invitation', 'Panels', 'Scheduler', 'Stats'. My main concern is that if something is not visible and accessible it will never be used and thus it doesn't exists.
+1, I agree
That's why I've created: XWIKI-7916 <http://jira.xwiki.org/browse/XWIKI-7916> - Integrate ColorThemes functionality inside Administration XWIKI-7920 <http://jira.xwiki.org/browse/XWIKI-7920> - Integrate Scheduler functionality inside Administration XWIKI-7919 <http://jira.xwiki.org/browse/XWIKI-7919> - Create an entry point for Stats inside Administration XWIKI-7918 <http://jira.xwiki.org/browse/XWIKI-7918> - Have an entry point for the Invitation application
While some functionality may seem normal to be Admin only (also because some of the hidden spaces were about configuration), some is arguable: - 'ColorThemes' initially were supposed to be used also by normal users in their profile but this didn't made it in final implementation; - makes sense that maybe a normal user could create a 'Panel' but right now this is not possible from Panels.WebHome; - Invitation should be able to be used by both types of users, but without the setting of the server mail, the users will always receive an error; - Stats again could be used by both.
What I would like is that things that are about configuration should always be integrated in the Administration. I am referring to the Scheduler configuration, Stats configuration, Search Suggest configuration, etc. The logic behind is that the Administration acts like an entry point for any configuration related actions. As Admin I shouldn't go outside Administration in order to achieve my configuration task (ex. XWIKI-7917<http://jira.xwiki.org/browse/XWIKI-7917> XWIKI-7921 <http://jira.xwiki.org/browse/XWIKI-7921> etc. ).
Now adding configuration inside Administration still doesn't solve the problem on the entry point. As an administrator, after I've completed the configuration step, where do I find the application? As a normal user is the same question + how do I even know that applications exists?
For this issue I've created XWIKI-7927 <http://jira.xwiki.org/browse/XWIKI-7927> - Create an entry point for all available applications inside the wiki This can be implemented as a gadget, as a panel or even as an Application Index (as a livetable or as a grid).
+1 we should have something custom for our applications, so users can easily see them. Having a space listed there doesn't mean necessarily it contains an application.
Now another problem remaining is that of specifying if an application is intended for Advanced, Simple users or both. Who should see Stats app? All the users? Just advanced users? As a first step, the hidden feature works because 'advanced' applications will be considered 'hidden' for users. The problem is what we consider 'advanced' to mean. Is ColorThemes or Stats an advanced application? And is especially problematic since by default the Administrator has an 'advanced' + 'hidden' configuration, meaning that he will not be able to see by default ColorThemes or other configuration (but currently hidden) application that might be useful for him (he needs to know that the functionality exists somewhere). So he is an 'advanced' user that doesn't have visibility to 'advanced' applications.
For this, I reported http://jira.xwiki.org/browse/XWIKI-7935 because for the moment, you can't do much about this (seeing hidden pages, only if you know their name) if you are a simple user.
So IMO the hidden mechanism is great for hiding technical pages (pages like *Sheet, *Template, Macros, internal pages, etc.) from users. It doesn't matter if those pages exist (from an user's point of view) as long as there is an UI that integrates them. The bad part of the current status of the 4.1RC1 is that IMO we should not consider entire applications to be hidden. Internal pages of the 'Invitation' app should be hidden, but the WebHome (that contains the functionality and the UI) should be available/discoverable somewhere.
Another important thing I would like to point out is that when doing a migration from an older version, some pages: BlueSky, Bordo, InnerDark, Natural, Nightfall, Peach for the ColorThemes Space and ClassEditorWelcome, GlobalRightsEditorWelcome, Tags, WebPreferences for Panels space (there might be others too) will not be deleted and they won't be marked as hidden. So these leftover pages from previous versions will unhide a space and make it visible in the Spaces macro, because they contain unhidden documents. IMO this is an important aspect, if we want to have a clean and consistent behavior after the migration.
In order for 'advanced' applications to not be displayed for normal users we should have another field that describes the application and this can be 'simple' or 'advanced' (and not rely just on the 'hidden'). XWIKI-7925 <http://jira.xwiki.org/browse/XWIKI-7925> - Have application descriptors for Application spaces
So the only problem remaining (besides the actual implementation :) ) would be to discuss what applications are advanced (or even admin only) and what are not (thus available to the general population). Keep in mind that the current separation is now simple/advanced but we might need a user/developer/admin separation in order to better separate the task functionality of our current applications scopes (ex. since we might want to have admins only applications that should not be available to developers, both being advanced users).
+1 here, we should decide. Guillaume was stating that mostly enterprises are forcing the same look and feel over their whole wiki. But don't forget that an XWiki instance has several mods, it can be an open wiki, etc. In these cases we might want to allow these kind of customizations at a user level. A hardcore approach would be to have rights for applications too, but I guess this is not feasible. Regards, Sorin B.
Thanks, Caty _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
participants (4)
-
Ecaterina Moraru (Valica) -
Guillaume Lerouge -
Sorin Burjan -
Vincent Massol