Re: [xwiki-users] [xwiki-devs] [Proposal] Rights Management UI
A small variation for Version 3 http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Rights3AProposal Changes: - improved the display of inheritance of rights within a role description; - emphasize the display of "Inherited"|"Allow"|"Deny" by using color and icon representation. For Rights version 4 I'll remove the concept of Role. Thanks, Caty On Thu, May 20, 2010 at 15:30, Ecaterina Valica <[email protected]> wrote:
On Wed, May 19, 2010 at 21:04, Denis Gervalle <[email protected]> wrote:
On Wed, May 19, 2010 at 16:33, Ecaterina Valica <[email protected]> wrote:
Hi Denis,
On Wed, May 19, 2010 at 16:52, Denis Gervalle <[email protected]> wrote:
On Wed, May 19, 2010 at 12:39, Ecaterina Valica <[email protected]> wrote:
On Tue, May 18, 2010 at 18:29, Denis Gervalle <[email protected]> wrote:
On Tue, May 18, 2010 at 17:08, Guillaume Lerouge < [email protected] >wrote:
> Hi, > > On Tue, May 18, 2010 at 11:03, Ecaterina Valica < [email protected]
wrote: > > > Hi, > > > > I've reviewed some of your feedback and added them to Rights Management > UI > > Proposal *VERSION 3*: > > > > *Partial Prototype* > > > > - Wiki Level: > >
http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Rights3Wiki
> > - Space Level: > >
http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Rights3Space
> > - Page Level: > >
http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Rights3Page
> > > > *Desired Interaction* > > > > - > > >
http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Rights3Proposal
> > > > Thanks, > > Caty > > > > I like the separation between rights definition and rights affectation. > Only >
Nice indeed, but I do not understand how it could fits with current implementation.
> downside -> inherited rights are displayed less clearly than what they were > in version 2. >
and I do not see any inherited information anymore.
For example, in Space Level http://localhost:8084/xwiki/bin/view/Improvements/Rights3Space the text in yellow represents the inherited users and inherited roles from upper level.
The text in black (evalica with Reviewer and the Reviewer definition) is specified only for this level.
After the save the added "Reviewer" right is gonna look like this:
http://localhost:8084/xwiki/bin/download/Improvements/Rights3Proposal/addU6....
Thanks for these precision, I have better understand your idea.
(Personally
I have some difficulties with colors (partially color blind), so information based on colors is not always easy for me.)
So you're a great test candidate :). I also received a mail from Roman (he wanted icons to represent rights), so what I can do for you is to try a version with color + little icon to represent "Inherited"|"Allow"|"Deny". I will think about it.
I think that could be nice to have more visual than color information for inheritance. The way it was in proposal 2 was fine, since this was more intensity than color. And I will be pleased to be your candidate. Be careful that using icons for representing specific rights could add complexity when (later) components add new rights dynamically.
So, proposal 3 seems less interesting than proposal 2. I do not
see
what
it
solves based on previous comments either. Caty, could you explain further your goals with this proposal ?
I tried in proposal 3 to make it more easy to use. People told me that they didn't understood the "Containing Spaces/Pages" so I've removed it. This proposal gives the users the possibility to create Roles that can have semantically value to them and thus making the rights more easy to use.
This proposal accommodates the case: "Not sure it's scalable. In the future applications/components will be able to register new rights". Having the rights displayed vertically and only on Add, makes the UI more scalable, and in the code we could add as many rights as we would want. Also the spaces is now more economical having just "Allow"/"Deny" columns.
I completely agree that proposal 3 is clearer. The problem is that your samples and the structure of this proposal are really far from current implementation. Proposal 2 were fitting better but the samples where also not realistic and remarks from Thomas about global wiki users should also be integrated.
About Thomas feedback, don't you like
http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Rights3Proposal#HNa...
?
So, I am puzzle by your goals here. Aren't we going too fast ? Since there is very poor documentation about the way XWiki rights
works (I
would be happy to improve that, but it will require some time), I have the impression that there is a important misunderstanding of how inheritance is effectively applied. So the design of a proper UI is not easy. I have also read the draft of Sergiu that aims to improve the documentation, but either I have not understand it or it does not describe current behavior.
So the question is for me, are we designing this UI to think about future possibilities or to replace the current UI ?
My purpose is "to make rights easy to use at last". IMO this means do whatever it takes to make them "easy to use" :) I try to base my proposal on existing code, but I never disregard new functionalities that I can add if this means the UI and experience is gonna be improved.
The only thing Rights version 3 is adding is the "Role" part, which is some kind of groups for rights. If the solution given is gonna be convincing enough to be use in the rights part (not yet .... but maybe some version of it) I'm sure there will be someone that is gonna want to implement it. Until then I will continue to prototype and find out how we can add all that functionality in one place.
Well, this precisely the grouping of right that is a big change. Currently, right are inherit individually, not as a group. Moreover, 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. Said another way, once an allowance for a given right has been found and you are not part of it, you are denied. Of course, there is an exception to this rules regarding global admin rights, these ones are evaluated before and gets priority.
I would agree if you find this to be not the correct way of evaluating right, but this is the way it works since the beginning. There is also an option to evaluate rights based on a hierarchy of spaces, but this one is usually disabled. It will probably be revived when such hierarchy of space are bring back using the new reference model.
So, I am convinced that current right management is poor, but changing it will require important changes, and time.
Hope you get a better idea of my concerns. For detailled information on how rights are processed, you may want to have a look at http://dev.xwiki.org/xwiki/bin/view/Drafts/XWikiRightServiceReversed. This is really bare documentation of the code, but it tells the truths.
Denis, thanks for the extra info Caty
Denis
And yes... I need to focus more on the inheritance again.
Thanks, Caty
Denis
Thanks, Caty
Denis
> > Also, a drop-down might be better than an autosuggest when
selecting
which > right should be added to a role. > > Guillaume > > > > _______________________________________________ > > devs mailing list > > [email protected] > > http://lists.xwiki.org/mailman/listinfo/devs > > > > > > -- > Guillaume Lerouge > Product Manager - XWiki SAS > Skype: wikibc > Twitter: glerouge > http://guillaumelerouge.com/ > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs >
-- 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
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Hi, On Thu, May 20, 2010 at 18:18, Ecaterina Valica <[email protected]> wrote:
A small variation for Version 3 http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Rights3AProposal
Changes:
- improved the display of inheritance of rights within a role description; - emphasize the display of "Inherited"|"Allow"|"Deny" by using color and icon representation.
For Rights version 4 I'll remove the concept of Role.
Just for the record, I like this version a lot and I think having Roles makes a lot of sense. Looking forward to your nest iteration, I'm sure it will be even better :-) Guillaume
Thanks, Caty
On Thu, May 20, 2010 at 15:30, Ecaterina Valica <[email protected]> wrote:
On Wed, May 19, 2010 at 21:04, Denis Gervalle <[email protected]> wrote:
On Wed, May 19, 2010 at 16:33, Ecaterina Valica <[email protected]> wrote:
Hi Denis,
On Wed, May 19, 2010 at 16:52, Denis Gervalle <[email protected]> wrote:
On Wed, May 19, 2010 at 12:39, Ecaterina Valica <[email protected]> wrote:
On Tue, May 18, 2010 at 18:29, Denis Gervalle <[email protected]> wrote:
> On Tue, May 18, 2010 at 17:08, Guillaume Lerouge < [email protected] > >wrote: > > > Hi, > > > > On Tue, May 18, 2010 at 11:03, Ecaterina Valica < [email protected]
> wrote: > > > > > Hi, > > > > > > I've reviewed some of your feedback and added them to Rights Management > > UI > > > Proposal *VERSION 3*: > > > > > > *Partial Prototype* > > > > > > - Wiki Level: > > >
http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Rights3Wiki
> > > - Space Level: > > > > http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Rights3Space > > > - Page Level: > > >
http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Rights3Page
> > > > > > *Desired Interaction* > > > > > > - > > > > >
http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Rights3Proposal
> > > > > > Thanks, > > > Caty > > > > > > > I like the separation between rights definition and rights affectation. > > Only > > > > Nice indeed, but I do not understand how it could fits with current > implementation. > > > > downside -> inherited rights are displayed less clearly than what they > were > > in version 2. > > > > and I do not see any inherited information anymore. >
For example, in Space Level http://localhost:8084/xwiki/bin/view/Improvements/Rights3Space the text in yellow represents the inherited users and inherited roles from upper level.
The text in black (evalica with Reviewer and the Reviewer definition) is specified only for this level.
After the save the added "Reviewer" right is gonna look like this:
http://localhost:8084/xwiki/bin/download/Improvements/Rights3Proposal/addU6....
Thanks for these precision, I have better understand your idea.
(Personally
I have some difficulties with colors (partially color blind), so information based on colors is not always easy for me.)
So you're a great test candidate :). I also received a mail from Roman (he wanted icons to represent rights), so what I can do for you is to try a version with color + little icon to represent "Inherited"|"Allow"|"Deny". I will think about it.
I think that could be nice to have more visual than color information for inheritance. The way it was in proposal 2 was fine, since this was more intensity than color. And I will be pleased to be your candidate. Be careful that using icons for representing specific rights could add complexity when (later) components add new rights dynamically.
> > So, proposal 3 seems less interesting than proposal 2. I do not
see
what
it > solves based on previous comments either. > Caty, could you explain further your goals with this proposal ? >
I tried in proposal 3 to make it more easy to use. People told me that they didn't understood the "Containing Spaces/Pages" so I've removed it. This proposal gives the users the possibility to create Roles that can have semantically value to them and thus making the rights more easy to use.
This proposal accommodates the case: "Not sure it's scalable. In the future applications/components will be able to register new rights". Having the rights displayed vertically and only on Add, makes the UI more scalable, and in the code we could add as many rights as we would want. Also the spaces is now more economical having just "Allow"/"Deny" columns.
I completely agree that proposal 3 is clearer. The problem is that your samples and the structure of this proposal are really far from current implementation. Proposal 2 were fitting better but the samples where also not realistic and remarks from Thomas about global wiki users should also be integrated.
About Thomas feedback, don't you like
http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Rights3Proposal#HNa...
?
So, I am puzzle by your goals here. Aren't we going too fast ? Since there is very poor documentation about the way XWiki rights
works (I
would be happy to improve that, but it will require some time), I have the impression that there is a important misunderstanding of how inheritance is effectively applied. So the design of a proper UI is not easy. I have also read the draft of Sergiu that aims to improve the documentation, but either I have not understand it or it does not describe current behavior.
So the question is for me, are we designing this UI to think about future possibilities or to replace the current UI ?
My purpose is "to make rights easy to use at last". IMO this means do whatever it takes to make them "easy to use" :) I try to base my proposal on existing code, but I never disregard new functionalities that I can add if this means the UI and experience is gonna be improved.
The only thing Rights version 3 is adding is the "Role" part, which is some kind of groups for rights. If the solution given is gonna be convincing enough to be use in the rights part (not yet .... but maybe some version of it) I'm sure there will be someone that is gonna want to implement it. Until then I will continue to prototype and find out how we can add all that functionality in one place.
Well, this precisely the grouping of right that is a big change. Currently, right are inherit individually, not as a group. Moreover, 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. Said another way, once an allowance for a given right has been found and you are not part of it, you are denied. Of course, there is an exception to this rules regarding global admin rights, these ones are evaluated before and gets priority.
I would agree if you find this to be not the correct way of evaluating right, but this is the way it works since the beginning. There is also an option to evaluate rights based on a hierarchy of spaces, but this one is usually disabled. It will probably be revived when such hierarchy of space are bring back using the new reference model.
So, I am convinced that current right management is poor, but changing it will require important changes, and time.
Hope you get a better idea of my concerns. For detailled information on how rights are processed, you may want to have a look at http://dev.xwiki.org/xwiki/bin/view/Drafts/XWikiRightServiceReversed. This is really bare documentation of the code, but it tells the truths.
Denis, thanks for the extra info Caty
Denis
And yes... I need to focus more on the inheritance again.
Thanks, Caty
Denis
Thanks, Caty
> > Denis > > > > > > Also, a drop-down might be better than an autosuggest when selecting > which > > right should be added to a role. > > > > Guillaume > > > > > > > _______________________________________________ > > > devs mailing list > > > [email protected] > > > http://lists.xwiki.org/mailman/listinfo/devs > > > > > > > > > > > -- > > Guillaume Lerouge > > Product Manager - XWiki SAS > > Skype: wikibc > > Twitter: glerouge > > http://guillaumelerouge.com/ > > _______________________________________________ > > devs mailing list > > [email protected] > > http://lists.xwiki.org/mailman/listinfo/devs > > > > > > -- > 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
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Guillaume Lerouge Product Manager - XWiki SAS Skype: wikibc Twitter: glerouge http://guillaumelerouge.com/
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
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] 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
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
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
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
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. 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. It is very confusing and users need to do additional steps in order to give the rights they want. I think is a problem of how the Groups are perceived. Only as a rights mechanism or as a semantically grouping. 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. 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). 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
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
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
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
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
On Tue, Jun 1, 2010 at 10:03, Denis Gervalle <[email protected]> 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... - Space: http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Rights4Proposal...
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... + 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... +- 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... V2_wiki_expanded) http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Rights4Proposal... 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... 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... - 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... is equivalent to V2_wiki) http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Rights4Proposal... 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... 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 <[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
On 05/27/2010 10:26 AM, Denis Gervalle 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 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... 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/
On Wed, Jun 9, 2010 at 12:57, Sergiu Dumitriu <[email protected]> wrote:
On 05/27/2010 10:26 AM, Denis Gervalle 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 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/>
On 06/09/2010 12:24 PM, Ecaterina Valica wrote:
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).
True, but that's not the way it was implemented initially. XWikiAllGroup was just another group like all others. Now, it is a bit more special, since it can be completely virtual, it can implicitly contain all registered users, and it is referenced in the code as the default group for new users.
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.
-- Sergiu Dumitriu http://purl.org/net/sergiu/
participants (5)
-
Alex Busenius -
Denis Gervalle -
Ecaterina Valica -
Guillaume Lerouge -
Sergiu Dumitriu