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
