On Thu, May 27, 2010 at 09:57, Ecaterina Valica <[email protected]> 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 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. > 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 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). > 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, and 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 <[email protected]> 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: > > 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. > > > > Thanks, > > Caty > > > > > > On Sat, May 22, 2010 at 11:31, Denis Gervalle <[email protected]> wrote: > > > >> 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 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. > >> > >> WDYT ? > >> > >> Denis > >> > >> On Sat, May 22, 2010 at 07:57, Ecaterina Valica <[email protected]> > >> wrote: > >> > >> > On Fri, May 21, 2010 at 21:42, Alex Busenius <[email protected] > >> > >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. 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 > >> > > >> > > > >> > > 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: > >> > > > > >> > > >> > http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Rights4Proposal > >> > > > Wiki Prototype: > >> > > > > >> http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Rights4Wiki > >> > > > Space Prototype: > >> > > > > >> http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Rights4Space > >> > > > > >> > > > This proposal is done by using feedback provided by Roman Muntyanu > >> and > >> > > > Raluca Morosan. > >> > > > Thanks, > >> > > > Caty > >> > > > _______________________________________________ > >> > > > users mailing list > >> > > > [email protected] > >> > > > http://lists.xwiki.org/mailman/listinfo/users > >> > > > > >> > > _______________________________________________ > >> > > devs mailing list > >> > > [email protected] > >> > > http://lists.xwiki.org/mailman/listinfo/devs > >> > > > >> > _______________________________________________ > >> > users mailing list > >> > [email protected] > >> > http://lists.xwiki.org/mailman/listinfo/users > >> > > >> > >> > >> > >> -- > >> Denis Gervalle > >> SOFTEC sa - CEO > >> eGuilde sarl - CTO > >> _______________________________________________ > >> devs mailing list > >> [email protected] > >> http://lists.xwiki.org/mailman/listinfo/devs > >> > > > > > _______________________________________________ > users mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/users > -- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
