On Wed, Jun 9, 2010 at 12:57, Sergiu Dumitriu <ser...@xwiki.com> wrote:
> On 05/27/2010 10:26 AM, Denis Gervalle 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 was done because the deny right is stronger than the allow right. How > can I say that for space X only group A has view right, and nobody else? > > Attempt 1. Deny to Guest and All, allow to A. Oups, doesn't work, since > everybody in A is also in All, and deny is stronger, so everyone is > denied... > IMO, RegisteredUsers is a special case. Imagine RegisteredUsers as a Wiki, and GroupA as a Space; and have the same level of appliance for groups (page-space-wiki, where space rights override wiki rights). So if I deny All and allow A, semantically A will have allow, because the tie will be broken by level. Just a thought. Caty > > Attempt 2. Hm, how could this be done? Denying to everybody is not an > option... So, allow the view right to A, and automagically everybody > else is denied. Great, XWiki really rocks! > > This is not a very valid use case, but more like a necessity. When > designing the current rights mechanism, a lot of not-entirely-compatible > use cases had to be balanced, and the outcome doesn't cleanly satisfy > all use cases, but it tries to make each scenario possible one way or > another. > > > > >> 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. > > +1. > > > 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 > > > -- > Sergiu Dumitriu > <http://purl.org/net/sergiu/> _______________________________________________ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
