18 Jun
2012
18 Jun
'12
1:56 p.m.
On Sat, Jun 16, 2012 at 12:04 AM, Vincent Massol <vincent(a)massol.net> wrote:
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.
Hi Caty and all,
On Jun 15, 2012, at 3:53 PM, Ecaterina Moraru (Valica) wrote:
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).
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.
Panels?
actually all the applications inside XE (blog, sandbox, etc.)
Thanks,
Caty
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? 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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs