Re: [xwiki-devs] [xwiki-users] [Proposal] Rights Management UI

Hi, Summary Icons for standard rights: *Space Level:* http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Rights42Space *Wiki Level*: http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Rights4Proposal

Bug: - when clicking on "more" next to the summary, all columns should expand, not just one column at a time. Missing: - expand/collapse all + pagination, etc Remarks: - Summary view is good for quick scanning of the rights. Rights

(changing) and inheritance explanations are available in expanded view. - Icons presented just for: view, comment, edit, delete, admin, register, programming. Extended rights|Expand mode are represented by "..." (more) Thanks, Caty On Thu, May 27, 2010 at 11:26, Denis Gervalle <dgl(a)softec.lu> wrote: > On Thu, May 27, 2010 at 09:57, Ecaterina Valica <valicac(a)gmail.com> > wrote: > > > Hi, > > > > 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. > > > > Changing this is not hard, but it will increase complexity since we will > need a backward compatibility mode for existing wikis. > > > > 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. > > > > I really do not know, and I am curious as well. > > > > It is very confusing and users need to do additional steps in order to > give > > the rights they want. > > > > I completely agree, this is poor. > > I think is a problem of how the Groups are perceived. Only as a rights > > mechanism or as a semantically grouping. > > > > We should not decide this, since groups maybe synchronized from external > system (ie LDAP), imposing groups for rights is not correct. By the way, > groups may contains groups, but I am almost sure that this will work > properly in practice. > > > > If we use groups just to give rights than the current implementation

> > usable. But if you have groups, like Tech team, Design team,

> > 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

> > 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

> > 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

> I > > ALREADY set at the higher level. > > > > This behavior is not logical for me. > > > > It is not logical for me and I imagine many others ! > > > > > > A solution would be to take out managerX form Group B and leave it

> 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

> > etc. > > > > Please tell if is a way to change this behavior and please have in

> > XWiki 3.0, where Groups are going beyond rights management and they > should > > be seen as collaboration mechanisms (which need to be semantical). > > > > IMO, XWiki 3.0 should have a complete rework of the right service > implementation, and breaks with the past. > Since this will cause many migration issue, I am not in favor of > progressive > changes, and I would prefer to see a big single change that fix this,

> also the current discussion on script rights. > > Denis > > 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. > > > > Thanks, > > Caty > > > > On Wed, May 26, 2010 at 16:48, Ecaterina Valica <valicac(a)gmail.com> > wrote: > > > > > Hi, > > > > > > 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: > > >

> > > Space Level: > > > > http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Rights41Space > > > > > > Obs. Summary view + icons not done yet. > > > > > > Thanks, > > > Caty > > > > > > > > > On Sat, May 22, 2010 at 11:31, Denis Gervalle <dgl(a)softec.lu>

> > > > > >> Hi Caty, > > >> > > >> 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

> > which > > >> fit a single line per user, this view would present the common

> > >> (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.

> we > > >> only > > >> need to use (and think about) a short icon representation for

> > >> rights, > > >> and extended rights will be represented by a single special > > >> representation. > > >> Rows could be expanded individually or globally so if you want a

> > >> 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

> > >> 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

> > >> the inheritance columns. The rights are inherited and check > > individually, > > >> so > > >> the precise source of inheritance is per rights, not only per user

> > >> group > > >> - there is a local source of inheritance: if the a right is

> 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,

> is > > >> potential performance improvement by immediately denying when a > > >> non-matching > > >> allow is found, currently we continue to check right at higher

> for > > >> more deny, this is not really clever) > > >> > > >> With these changes, I really feel that this last proposal could be

> > >> wrote: > > >> > > >> > On Fri, May 21, 2010 at 21:42, Alex Busenius < > alex.busenius(a)xwiki.com > > >> > >wrote: > > >> > > > >> > > 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.

> > >> Rights > > >> > version 3-4 were made having rights extensibility in mind, for

> > 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

> > >> easier > > >> > to > > >> > have a bigger area to select when you want to drag an item. > > >> > > > >> > Thanks Alex for your feedback, > > >> > Caty > > >> > > > >> > > > > >> > > Alex > > >> > > > > >> > > > > >> > > On 05/21/2010 07:51 PM, Ecaterina Valica wrote: > > >> > > > Hi, > > >> > > > > > >> > > > Changes: > > >> > > > > > >> > > > - 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: > > >> > > > > > >> > > > >> > > >

> > >> > > > Wiki Prototype: > > >> > > > > > >>