Caty, I probably have an issue with my browser (Chrome/Mac) but I cannot see the icons :( Anyway this seem to me nice, but I am not sure you should prevent changing rights in summary mode. I think that summary mode should allow simple right management, and for 'casual' or less knowledgeable users, this should be the only mode used. This is not only a summary, but also a simplified interface.
WDYT ? Denis On Mon, May 31, 2010 at 16:54, Ecaterina Valica <[email protected]> wrote: > On Mon, May 31, 2010 at 17:53, Ecaterina Valica <[email protected]> wrote: > > > 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 > > > > Sorry: link for Wiki is > http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Rights42Wiki > > > > > > 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 > >> > > > > > _______________________________________________ > 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
