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