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 management (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 <[email protected]> wrote: > 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 > _______________________________________________ > users mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/users > _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
