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 _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
