On Tue, Jun 1, 2010 at 10:03, Denis Gervalle <d...@softec.lu> wrote: > Caty, > > I probably have an issue with my browser (Chrome/Mac) but I cannot see the > icons :( >
Fixed: thanks. Made some screenshots with how it suppose to look like: - Wiki: http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Rights4Proposal/wiki42View.png - Space: http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Rights4Proposal/space42View.png > 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 ? > I had your vision (changing rights in summary mode) in mind when I started prototyping. Let me show you some versions: V1_space) First version took the exact order from the extended view (first Allow, second Deny rights) http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Rights4Proposal/spaceTest1.png + this version lets the user drag its right to the appropriate column +- has the same representation as the extended version --- there is no scanability: if I want to see the status of "delete" right for different groups/users I have to search for them (making me dizzy :P ) + there is no gapping space between rights V2_space) Tried to fix the dizziness by providing same order/position for rights http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Rights4Proposal/spaceTest2.png +- this version lets the user drag its right to the appropriate column, but the user has not control over the position he choose to drop the target: the right will appear on the column it's suppose to be +- doesn't have the same representation as the extended version (allowed/denied order broke, determined order present) + scanability: it's easy to scan for the searched column/position - gap space between rights: ex. evalica-DenyDelete: some users might not like that gap and may not understand why is there (is it a bug?) See also: V2_wiki) http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Rights4Proposal/wikiTest2.png V2_wiki_expanded) http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Rights4Proposal/wikiTest21.png As you see in V2) has the same functionality as the expanded version. The main benefit is that is occupying less space, but we still need the expanded view for the Inherited/detailed information for each right. The down side of version 2 http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Rights4Proposal/wikiTest2.png is that if I want to *summarize *a global state for a given right (ex see for what users 'delete' is allowed/denied) at a global level, not at a group/user level, the same dizziness effect appears (I have to search for 'delete' right in three columns, for all the users) V3) is the current proposal, it compresses the 3 column spread information in one view. http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Rights4Proposal/space42View.png - this version doesn't lets the user drag its right to the appropriate column +- doesn't have the same representation as the extended version + scanability: it's easy to scan for the searched column/position at a * global* level + there is no gapping space between rights V3_wiki) http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Rights4Proposal/wikiTest3.png is equivalent to V2_wiki) http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Rights4Proposal/wikiTest2.png I prefer V3) over V2): + Summary does what is suppose to: give a global summary of existing rights, without being concerned of the type of the right (inherited, locally allowed, locally denied) + Good Readability +/- Doesn't allow rights to be dragged around. I prefer changing rights in expanded mode because there you also have more information, like source of the inheritance + 3 columns. Being compact it's easier to understand the "local source of inheritance" for a given right. For example, allowing "view" right for 'evalica' will deny it for 'unregistered users' and 'registered users'. Being on the same column is easier to look for the change and see it in action (being highlighted). http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Rights4Proposal/space42View.png Please tell me what you think about this rationale. It would be great if you have ideas about how to make the summary being draggable, but also keeping scanability and less gaps. Thanks, Caty > Denis > > On Mon, May 31, 2010 at 16:54, Ecaterina Valica <vali...@gmail.com> wrote: > > > On Mon, May 31, 2010 at 17:53, Ecaterina Valica <vali...@gmail.com> > 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 <d...@softec.lu> wrote: > > > > > >> On Thu, May 27, 2010 at 09:57, Ecaterina Valica <vali...@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 > > 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 <vali...@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: > > >> > > > > 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 <d...@softec.lu> > > 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 < > vali...@gmail.com > > > > > >> > >> wrote: > > >> > >> > > >> > >> > On Fri, May 21, 2010 at 21:42, Alex Busenius < > > >> alex.busen...@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. > > 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 > > >> > >> > > > users@xwiki.org > > >> > >> > > > http://lists.xwiki.org/mailman/listinfo/users > > >> > >> > > > > > >> > >> > > _______________________________________________ > > >> > >> > > devs mailing list > > >> > >> > > d...@xwiki.org > > >> > >> > > http://lists.xwiki.org/mailman/listinfo/devs > > >> > >> > > > > >> > >> > _______________________________________________ > > >> > >> > users mailing list > > >> > >> > users@xwiki.org > > >> > >> > http://lists.xwiki.org/mailman/listinfo/users > > >> > >> > > > >> > >> > > >> > >> > > >> > >> > > >> > >> -- > > >> > >> Denis Gervalle > > >> > >> SOFTEC sa - CEO > > >> > >> eGuilde sarl - CTO > > >> > >> _______________________________________________ > > >> > >> devs mailing list > > >> > >> d...@xwiki.org > > >> > >> http://lists.xwiki.org/mailman/listinfo/devs > > >> > >> > > >> > > > > >> > > > > >> > _______________________________________________ > > >> > users mailing list > > >> > users@xwiki.org > > >> > http://lists.xwiki.org/mailman/listinfo/users > > >> > > > >> > > >> > > >> > > >> -- > > >> Denis Gervalle > > >> SOFTEC sa - CEO > > >> eGuilde sarl - CTO > > >> _______________________________________________ > > >> users mailing list > > >> users@xwiki.org > > >> http://lists.xwiki.org/mailman/listinfo/users > > >> > > > > > > > > _______________________________________________ > > users mailing list > > users@xwiki.org > > http://lists.xwiki.org/mailman/listinfo/users > > > > > > -- > Denis Gervalle > SOFTEC sa - CEO > eGuilde sarl - CTO > _______________________________________________ > devs mailing list > d...@xwiki.org > http://lists.xwiki.org/mailman/listinfo/devs > _______________________________________________ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
