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