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