|Ecaterina Valica||May 10, 2010 6:39 am|
|Guillaume Lerouge||May 10, 2010 7:01 am|
|Ecaterina Valica||May 10, 2010 7:07 am|
|Thomas Mortagne||May 10, 2010 8:21 am|
|Ecaterina Valica||May 13, 2010 1:56 am|
|Ecaterina Valica||May 18, 2010 2:03 am|
|Guillaume Lerouge||May 18, 2010 8:07 am|
|Denis Gervalle||May 18, 2010 8:28 am|
|Ecaterina Valica||May 19, 2010 3:23 am|
|Ecaterina Valica||May 19, 2010 3:39 am|
|Denis Gervalle||May 19, 2010 6:52 am|
|Ecaterina Valica||May 19, 2010 7:32 am|
|Ecaterina Valica||May 20, 2010 9:17 am|
|Guillaume Lerouge||May 20, 2010 9:21 am|
|Ecaterina Valica||May 21, 2010 10:51 am|
|Alex Busenius||May 21, 2010 11:41 am|
|Ecaterina Valica||May 21, 2010 10:57 pm|
|Denis Gervalle||May 22, 2010 1:31 am|
|Ecaterina Valica||May 26, 2010 6:48 am|
|Ecaterina Valica||May 27, 2010 12:57 am|
|Denis Gervalle||May 27, 2010 1:25 am|
|Ecaterina Valica||May 31, 2010 7:53 am|
|Ecaterina Valica||May 31, 2010 7:54 am|
|Denis Gervalle||Jun 1, 2010 12:03 am|
|Ecaterina Valica||Jun 1, 2010 3:54 am|
|Ecaterina Valica||Jun 3, 2010 9:08 am|
|Denis Gervalle||Jun 4, 2010 12:42 am|
|Ecaterina Valica||Jun 4, 2010 9:54 am|
|Alex Busenius||Jun 4, 2010 10:56 am|
|Ecaterina Valica||Jun 4, 2010 11:23 am|
|Raluca Stavro||Jun 4, 2010 11:33 am|
|Raluca Stavro||Jun 4, 2010 11:36 am|
|Alex Busenius||Jun 4, 2010 12:04 pm|
|Denis Gervalle||Jun 4, 2010 3:53 pm|
|Ecaterina Valica||Jun 7, 2010 1:22 am|
|Ecaterina Valica||Jun 7, 2010 1:50 am|
|Denis Gervalle||Jun 7, 2010 2:23 am|
|Ecaterina Valica||Jun 7, 2010 7:59 am|
|Ecaterina Valica||Jun 8, 2010 2:19 am|
|Denis Gervalle||Jun 8, 2010 3:46 am|
|Raluca Stavro||Jun 8, 2010 4:44 am|
|Ecaterina Valica||Jun 8, 2010 6:40 am|
|Denis Gervalle||Jun 8, 2010 8:13 am|
|Philip Brunetti||Jun 8, 2010 6:53 pm|
|Caleb James DeLisle||Jun 8, 2010 7:31 pm|
|Vincent Massol||Jun 9, 2010 12:24 am|
|Sergiu Dumitriu||Jun 9, 2010 2:56 am|
|Ecaterina Valica||Jun 9, 2010 3:23 am|
|Ecaterina Valica||Jun 9, 2010 3:35 am|
|Sergiu Dumitriu||Jun 9, 2010 3:45 am|
|Sergiu Dumitriu||Jun 9, 2010 5:01 am|
|Sergiu Dumitriu||Jun 9, 2010 5:04 am|
|Raluca Stavro||Jun 9, 2010 8:28 am|
|Raluca Stavro||Jun 9, 2010 8:29 am|
|Raluca Stavro||Jun 9, 2010 8:31 am|
|Ecaterina Valica||Jun 9, 2010 10:11 am|
|Denis Gervalle||Jun 10, 2010 12:15 am|
|Subject:||Re: [xwiki-users] [xwiki-devs] [Proposal] Rights Management UI|
|From:||Ecaterina Valica (vali...@gmail.com)|
|Date:||May 27, 2010 12:57:23 am|
I want to talk a bit about:
The inheritance is a little bit particular, since allowing a given right at lower level, will deny that same right for anybody else even if this right is allowed at a higher level.
I want to know how hard this would be to be changed. Another question is why this has been done in the first place? Can someone give a valid use case when this is more productive than other ways.
It is very confusing and users need to do additional steps in order to give the rights they want.
I think is a problem of how the Groups are perceived. Only as a rights mechanism or as a semantically grouping.
If we use groups just to give rights than the current implementation is usable. But if you have groups, like Tech team, Design team, Marketing, Happy team ... etc in order to classify our users in other ways beside rights management, giving permission to a user is breaking all the inheritance from upper levels.
Example: Group A(Managers) has View (default allowed) at wiki level - this means that they should be allowed to view all the pages in the wiki. Group B(Tech Team) has View (explicitly denied) at spaceX level - this means they shouldn't be allowed to view this space.
But I have a person (the managerX) in Group B that is supposed to see the info in spaceX level. So the first logical move would be to give him allow at space level (having in mind that space rights are stronger that wiki rights and the view right has been overriden). But, if I give managerX view right, all the other groups (incluing Managers) will be denied for spaceX level. This means I need to know that and "repair" again all the rights I ALREADY set at the higher level.
This behavior is not logical for me.
A solution would be to take out managerX form Group B and leave it just in Managers group. Yes, this way my problem is solved, but this means Groups are only used for Rights purposes. Group B (Tech Team) is no longer semantically compact and I can't further give this group compact tasks, etc.
Please tell if is a way to change this behavior and please have in mind XWiki 3.0, where Groups are going beyond rights management and they should be seen as collaboration mechanisms (which need to be semantical).
Rights should be inherited from upper level and should affect only the user/group where a change is made, not make some complicated implications at other levels and groups.
On Wed, May 26, 2010 at 16:48, Ecaterina Valica <vali...@gmail.com> wrote:
Did: - source of inheritance is per rights; - local source of inheritance: if the a right is allowed to anyone else at the same level, it is implicitly disallowed for any others; - inheritance from upper levels / groups.
Please see if I put the rights correctly: Wiki Level: http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Rights41Wiki Space Level: http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Rights41Space
Obs. Summary view + icons not done yet.
On Sat, May 22, 2010 at 11:31, Denis Gervalle <dg...@softec.lu> wrote:
This one is simpler and more easy to understand than proposal 2 (which I liked but were complex). It is your best try IMO. I agree with Caty that using icons too reduce the place taken will not allow easy extensions. But Alex proposal would help to have a summary view, which is nice to have too.
Maybe we could do both in fact. Propose a summary view (by default), which fit a single line per user, this view would present the common rights (V/C/E/D/A/(R/P)) using icons, and a last icon would be used to mention there is more special rights either inherited, allowed or denied. So we only need to use (and think about) a short icon representation for common rights, and extended rights will be represented by a single special representation. Rows could be expanded individually or globally so if you want a more detailled information, you may reach it either for a single user or all at once. Changing common rights would be allowed in collapsed mode and expanded mode, but changing special rights would only be allowed in expanded view.
If you want to keep the width even smaller, you may also colspan the user/group column over the others, using 2 rows per user, but I am not sure it will be nice. (Could this be only when horizontal space is short ?)
I really like this one because it is simple to learn without documentation and could also help learning how rights works, but there is again some inconstancies with the current implementation. Compare to proposal 3, these inconsistencies may be nicely fixed and really helps understanding why the right is disallowed at any time. You can do it like this:
- the inheritance pop-up information should be at the right level in the inheritance columns. The rights are inherited and check individually, so the precise source of inheritance is per rights, not only per user or group - there is a local source of inheritance: if the a right is allowed to anyone else at the same level, it is implicitly disallowed for any others. So the source of inheritance is the local level, implying a deny because the local level has at least a specific allow. This means than when you drag the first time a right in the allow column, all other user/group at the same level will have that right inherited deny from the current level. (For those who wonder and will check the source of the right service, yes, there is potential performance improvement by immediately denying when a non-matching allow is found, currently we continue to check right at higher level for more deny, this is not really clever)
With these changes, I really feel that this last proposal could be a real improvement in the way rights are applied, and keeps the interface simple at the same time.
On Sat, May 22, 2010 at 07:57, Ecaterina Valica <vali...@gmail.com> wrote:
On Fri, May 21, 2010 at 21:42, Alex Busenius <alex...@xwiki.com
I like this version, it makes clear what is allowed/denied and why, but it takes a lot of space. What if those rights names would be replaced by big icons and placed side by side? Like this (sorry for ASCII-art):
-------------------+-------------------------------------+--+------ Unregistered users | [+V] [+C] [+R] [-D] [-A] [-P] [-CC] | | [-E]
Big Icons: We are using Silk set for our icons and this is constraining. Also, Rights version 3-4 were made having rights extensibility in mind, for use cases like adding "captchaComment" right, or "annotate" right, or "applicationXusage" right .... so I don't think is very good if applications are gonna have to choose their custom icon to represent their custom right, because is gonna be a mess in the UI.
There are few possible icons to choose from (in order to keep the look&feel unitary) and having the developers choose their own icon for the right they extend is gonna break the UI consistency. I think is much easier, extensible and less visual cryptic to textual describe an extensible right.
Placed side by side: Version 4 takes a lot of space, yes, but the problem with side by side is that is less readable (harder to scan the rights order). Also it's easier to have a bigger area to select when you want to drag an item.
Thanks Alex for your feedback, Caty
On 05/21/2010 07:51 PM, Ecaterina Valica wrote:
- One additional column is added: "Default / Inherited Rights", by default all rights appear in this column - By using drag'n'drop items are tossed around between "Allow rights", "Deny rights" and "Default / Inherited Rights"
Rights Proposal 4:
This proposal is done by using feedback provided by Roman Muntyanu and Raluca Morosan. Thanks, Caty
-- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO