20 May
2010
20 May
'10
6:18 p.m.
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 <valicac(a)gmail.com> wrote:
On Wed, May 19, 2010 at 21:04, Denis Gervalle <dgl(a)softec.lu> wrote:
On Wed, May 19, 2010 at 16:33, Ecaterina Valica
<valicac(a)gmail.com>
wrote:
valicac(a)gmail.com
http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Rights3Page
http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Rights3Proposal
(he
want.
realistic
proposal
Denis, thanks for the extra info
Caty
Hi Denis,
On Wed, May 19, 2010 at 16:52, Denis Gervalle <dgl(a)softec.lu> wrote:
wrote:
On Wed, May 19, 2010 at 12:39, Ecaterina Valica
<valicac(a)gmail.com>
wrote:
>
> > On Tue, May 18, 2010 at 18:29, Denis Gervalle <dgl(a)softec.lu> >
> > On Tue, May 18, 2010 at 17:08, Guillaume Lerouge <
guillaume(a)xwiki.com
> > > >wrote:
> > >
> > > > Hi,
> > > >
> > > > On Tue, May 18, 2010 at 11:03, Ecaterina Valica < >
> > > 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:
> > > > >
> > > >
> >
> > > > *Desired Interaction*
> > > >
> > > > -
> > > >
> > >
>
> > > > >
> > > > > 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
http://localhost:8084/xwiki/bin/download/Improvements/Rights3Proposal/addU6…
> specified only for this level.
>
> After the save the added "Reviewer" right is gonna look like this:
>
>
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 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 > > 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 and
http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Rights3Proposal#HN…
remarks from Thomas about global wiki users
should also be integrated.
About Thomas feedback, don't you like
?
>
> 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
inheritance
would be happy to improve that, but it will
require some time), I have
the
> impression that there is a important misunderstanding of how is
future
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
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 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
And yes... I need to focus more on the inheritance again.
Thanks,
Caty
--
Denis Gervalle
SOFTEC sa - CEO
eGuilde sarl - CTO
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
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
> > > > devs(a)xwiki.org
> > > > http://lists.xwiki.org/mailman/listinfo/devs
> > > >
> > >
> > >
> > >
> > > --
> > > Guillaume Lerouge
> > > Product Manager - XWiki SAS
> > > Skype: wikibc
> > > Twitter: glerouge
> > > http://guillaumelerouge.com/
> > > _______________________________________________
> > > devs mailing list
> > > devs(a)xwiki.org
> > > http://lists.xwiki.org/mailman/listinfo/devs
> > >
> >
> >
> >
> > --
> > Denis Gervalle
> > SOFTEC sa - CEO
> > eGuilde sarl - CTO
> > _______________________________________________
> > users mailing list
> > users(a)xwiki.org
> > http://lists.xwiki.org/mailman/listinfo/users
> >
> _______________________________________________
> users mailing list
> users(a)xwiki.org
> http://lists.xwiki.org/mailman/listinfo/users
>
--
Denis Gervalle
SOFTEC sa - CEO
eGuilde sarl - CTO
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
20 May
20 May
6:21 p.m.
New subject: [xwiki-users] [xwiki-devs] [Proposal] Rights Management UI
Hi,
On Thu, May 20, 2010 at 18:18, Ecaterina Valica <valicac(a)gmail.com> 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 <valicac(a)gmail.com> wrote:
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Guillaume Lerouge
Product Manager - XWiki SAS
Skype: wikibc
Twitter: glerouge
http://guillaumelerouge.com/
On Wed, May 19, 2010 at 21:04, Denis Gervalle <dgl(a)softec.lu> wrote:
> On Wed, May 19, 2010 at 16:33, Ecaterina Valica <valicac(a)gmail.com>
> wrote:
>
> > Hi Denis,
> >
> > On Wed, May 19, 2010 at 16:52, Denis Gervalle <dgl(a)softec.lu> wrote:
> >
> > > On Wed, May 19, 2010 at 12:39, Ecaterina Valica <valicac(a)gmail.com>
> > wrote:
> > >
> > > > On Tue, May 18, 2010 at 18:29, Denis Gervalle <dgl(a)softec.lu>
> wrote:
> > > >
> > > > > On Tue, May 18, 2010 at 17:08, Guillaume Lerouge <
> > guillaume(a)xwiki.com
> > > > > >wrote:
> > > > >
> > > > > > Hi,
> > > > > >
> > > > > > On Tue, May 18, 2010 at 11:03, Ecaterina Valica <
> valicac(a)gmail.com
> > >
> > > > > 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#HN…
> > ?
> >
> >
> > >
> > > 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
> > > > > devs(a)xwiki.org
> > > > > http://lists.xwiki.org/mailman/listinfo/devs
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Guillaume Lerouge
> > > > Product Manager - XWiki SAS
> > > > Skype: wikibc
> > > > Twitter: glerouge
> > > > http://guillaumelerouge.com/
> > > > _______________________________________________
> > > > devs mailing list
> > > > devs(a)xwiki.org
> > > > http://lists.xwiki.org/mailman/listinfo/devs
> > > >
> > >
> > >
> > >
> > > --
> > > Denis Gervalle
> > > SOFTEC sa - CEO
> > > eGuilde sarl - CTO
> > > _______________________________________________
> > > users mailing list
> > > users(a)xwiki.org
> > > http://lists.xwiki.org/mailman/listinfo/users
> > >
> > _______________________________________________
> > users mailing list
> > users(a)xwiki.org
> > http://lists.xwiki.org/mailman/listinfo/users
> >
>
>
>
> --
> Denis Gervalle
> SOFTEC sa - CEO
> eGuilde sarl - CTO
> _______________________________________________
> devs mailing list
> devs(a)xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
>
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Denis Gervalle
SOFTEC sa - CEO
eGuilde sarl - CTO
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
21 May
21 May
7:51 p.m.
New subject: [xwiki-users] [xwiki-devs] [Proposal] Rights Management UI
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
8:42 p.m.
New subject: [xwiki-users] [xwiki-devs] [Proposal] Rights Management UI
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
users(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/users
22 May
22 May
7:57 a.m.
New subject: [xwiki-users] [xwiki-devs] [Proposal] Rights Management UI
On Fri, May 21, 2010 at 21:42, Alex Busenius <alex.busenius(a)xwiki.com>wrote;wrote:
I like this version, it makes clear what is
allowed/denied and why, but
it takes a lot of space. What if those rights names would be replaced by
big icons and placed side by side? Like this (sorry for ASCII-art):
-------------------+-------------------------------------+--+------
Unregistered users | [+V] [+C] [+R] [-D] [-A] [-P] [-CC] | | [-E]
Big Icons:
We are using Silk set for our icons and this is constraining. Also, Rights
version 3-4 were made having rights extensibility in mind, for use cases
like adding "captchaComment" right, or "annotate" right, or
"applicationXusage" right .... so I don't think is very good if
applications
are gonna have to choose their custom icon to represent their custom right,
because is gonna be a mess in the UI.
There are few possible icons to choose from (in order to keep the look&feel
unitary) and having the developers choose their own icon for the right they
extend is gonna break the UI consistency.
I think is much easier, extensible and less visual cryptic to textual
describe an extensible right.
Placed side by side:
Version 4 takes a lot of space, yes, but the problem with side by side is
that is less readable (harder to scan the rights order). Also it's easier to
have a bigger area to select when you want to drag an item.
Thanks Alex for your feedback,
Caty
Alex
On 05/21/2010 07:51 PM, Ecaterina Valica wrote:
Hi,
Changes:
- One additional column is added: "Default / Inherited Rights", by
default all rights appear in this column
- By using drag'n'drop items are tossed around between "Allow
rights",
"Deny rights" and "Default / Inherited Rights"
Rights Proposal 4:
http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Rights4Proposal
Wiki Prototype:
http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Rights4Wiki
Space Prototype:
http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Rights4Space
This proposal is done by using feedback provided by Roman Muntyanu and
Raluca Morosan.
Thanks,
Caty
_______________________________________________
users mailing list
users(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/users
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
10:31 a.m.
New subject: [xwiki-users] [xwiki-devs] [Proposal] Rights Management UI
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 <valicac(a)gmail.com> wrote:
On Fri, May 21, 2010 at 21:42, Alex Busenius
<alex.busenius(a)xwiki.com
_______________________________________________
users mailing list
users(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/users
--
Denis Gervalle
SOFTEC sa - CEO
eGuilde sarl - CTO
wrote:
I like this version, it makes clear what is
allowed/denied and why, but
it takes a lot of space. What if those rights names would be replaced by
big icons and placed side by side? Like this (sorry for ASCII-art):
-------------------+-------------------------------------+--+------
Unregistered users | [+V] [+C] [+R] [-D] [-A] [-P] [-CC] | | [-E]
Big Icons:
We are using Silk set for our icons and this is constraining. Also, Rights
version 3-4 were made having rights extensibility in mind, for use cases
like adding "captchaComment" right, or "annotate" right, or
"applicationXusage" right .... so I don't think is very good if
applications
are gonna have to choose their custom icon to represent their custom right,
because is gonna be a mess in the UI.
There are few possible icons to choose from (in order to keep the look&feel
unitary) and having the developers choose their own icon for the right they
extend is gonna break the UI consistency.
I think is much easier, extensible and less visual cryptic to textual
describe an extensible right.
Placed side by side:
Version 4 takes a lot of space, yes, but the problem with side by side is
that is less readable (harder to scan the rights order). Also it's easier
to
have a bigger area to select when you want to drag an item.
Thanks Alex for your feedback,
Caty
Alex
On 05/21/2010 07:51 PM, Ecaterina Valica wrote:
> Hi,
>
> Changes:
>
> - One additional column is added: "Default / Inherited Rights", by
> default all rights appear in this column
> - By using drag'n'drop items are tossed around between "Allow
rights",
> "Deny rights" and "Default
/ Inherited Rights"
>
> Rights Proposal 4:
>
http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Rights4Proposal
Wiki
Prototype:
http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Rights4Wiki
Space Prototype:
http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Rights4Space
This proposal is done by using feedback provided by Roman Muntyanu and
Raluca Morosan.
Thanks,
Caty
_______________________________________________
users mailing list
users(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/users
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
26 May
26 May
3:48 p.m.
New subject: [xwiki-users] [xwiki-devs] [Proposal] Rights Management UI
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 <dgl(a)softec.lu> wrote:
Hi Caty,
This one is simpler and more easy to understand than proposal 2 (which I
liked but were complex). It is your best try IMO. I agree with Caty that
using icons too reduce the place taken will not allow easy extensions. But
Alex proposal would help to have a summary view, which is nice to have too.
Maybe we could do both in fact. Propose a summary view (by default), which
fit a single line per user, this view would present the common rights
(V/C/E/D/A/(R/P)) using icons, and a last icon would be used to mention
there is more special rights either inherited, allowed or denied. So we
only
need to use (and think about) a short icon representation for common
rights,
and extended rights will be represented by a single special representation.
Rows could be expanded individually or globally so if you want a more
detailled information, you may reach it either for a single user or all at
once. Changing common rights would be allowed in collapsed mode and
expanded
mode, but changing special rights would only be allowed in expanded view.
If you want to keep the width even smaller, you may also colspan the
user/group column over the others, using 2 rows per user, but I am not sure
it will be nice. (Could this be only when horizontal space is short ?)
I really like this one because it is simple to learn without documentation
and could also help learning how rights works, but there is again
some inconstancies with the current implementation. Compare to proposal 3,
these inconsistencies may be nicely fixed and really helps understanding
why
the right is disallowed at any time. You can do it like this:
- the inheritance pop-up information should be at the right level in
the inheritance columns. The rights are inherited and check individually,
so
the precise source of inheritance is per rights, not only per user or group
- there is a local source of inheritance: if the a right is allowed to
anyone else at the same level, it is implicitly disallowed for any others.
So the source of inheritance is the local level, implying a deny because
the
local level has at least a specific allow. This means than when you drag
the
first time a right in the allow column, all other user/group at the same
level will have that right inherited deny from the current level. (For
those
who wonder and will check the source of the right service, yes, there is
potential performance improvement by immediately denying when a
non-matching
allow is found, currently we continue to check right at higher level for
more deny, this is not really clever)
With these changes, I really feel that this last proposal could be a real
improvement in the way rights are applied, and keeps the interface simple
at
the same time.
WDYT ?
Denis
On Sat, May 22, 2010 at 07:57, Ecaterina Valica <valicac(a)gmail.com> wrote:
Rights
_______________________________________________
users mailing list
users(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/users
--
Denis Gervalle
SOFTEC sa - CEO
eGuilde sarl - CTO
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
On Fri, May 21, 2010 at 21:42, Alex Busenius
<alex.busenius(a)xwiki.com
by
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 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, 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
http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Rights4Space
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:
> > > >
> > This proposal is done by using feedback provided by Roman Muntyanu
and
Raluca Morosan.
Thanks,
Caty
_______________________________________________
users mailing list
users(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/users
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
27 May
27 May
9:57 a.m.
New subject: [xwiki-users] [xwiki-devs] [Proposal] Rights Management UI
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 <valicac(a)gmail.com> wrote:
Hi,
Did:
- source of inheritance is per rights;
- local source of inheritance: if the a right is allowed to anyone else at
the same level, it is implicitly disallowed for any others;
- inheritance from upper levels / groups.
Please see if I put the rights correctly:
Wiki Level:
http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Rights41Wiki
Space Level:
http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Rights41Space
Obs. Summary view + icons not done yet.
Thanks,
Caty
On Sat, May 22, 2010 at 11:31, Denis Gervalle <dgl(a)softec.lu> wrote:
Hi Caty,
This one is simpler and more easy to understand than proposal 2 (which I
liked but were complex). It is your best try IMO. I agree with Caty that
using icons too reduce the place taken will not allow easy extensions. But
Alex proposal would help to have a summary view, which is nice to have
too.
Maybe we could do both in fact. Propose a summary view (by default), which
fit a single line per user, this view would present the common rights
(V/C/E/D/A/(R/P)) using icons, and a last icon would be used to mention
there is more special rights either inherited, allowed or denied. So we
only
need to use (and think about) a short icon representation for common
rights,
and extended rights will be represented by a single special
representation.
Rows could be expanded individually or globally so if you want a more
detailled information, you may reach it either for a single user or all at
once. Changing common rights would be allowed in collapsed mode and
expanded
mode, but changing special rights would only be allowed in expanded view.
If you want to keep the width even smaller, you may also colspan the
user/group column over the others, using 2 rows per user, but I am not
sure
it will be nice. (Could this be only when horizontal space is short ?)
I really like this one because it is simple to learn without documentation
and could also help learning how rights works, but there is again
some inconstancies with the current implementation. Compare to proposal 3,
these inconsistencies may be nicely fixed and really helps understanding
why
the right is disallowed at any time. You can do it like this:
- the inheritance pop-up information should be at the right level in
the inheritance columns. The rights are inherited and check individually,
so
the precise source of inheritance is per rights, not only per user or
group
- there is a local source of inheritance: if the a right is allowed to
anyone else at the same level, it is implicitly disallowed for any others.
So the source of inheritance is the local level, implying a deny because
the
local level has at least a specific allow. This means than when you drag
the
first time a right in the allow column, all other user/group at the same
level will have that right inherited deny from the current level. (For
those
who wonder and will check the source of the right service, yes, there is
potential performance improvement by immediately denying when a
non-matching
allow is found, currently we continue to check right at higher level for
more deny, this is not really clever)
With these changes, I really feel that this last proposal could be a real
improvement in the way rights are applied, and keeps the interface simple
at
the same time.
WDYT ?
Denis
On Sat, May 22, 2010 at 07:57, Ecaterina Valica <valicac(a)gmail.com>
wrote:
Rights
http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Rights4Proposal
--
Denis Gervalle
SOFTEC sa - CEO
eGuilde sarl - CTO
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
On Fri, May 21, 2010 at 21:42, Alex Busenius
<alex.busenius(a)xwiki.com
but
wrote:
> I like this version, it makes clear what is allowed/denied and why, > 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, 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:
>
> > Wiki Prototype:
> >
http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Rights4Wiki
> > Space Prototype:
> >
http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Rights4Space
> >
> > This proposal is done by using feedback provided by Roman Muntyanu
and
>
Raluca Morosan.
> Thanks,
> Caty
> _______________________________________________
> users mailing list
> users(a)xwiki.org
> http://lists.xwiki.org/mailman/listinfo/users
>
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
users mailing list
users(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/users
10:26 a.m.
New subject: [xwiki-users] [xwiki-devs] [Proposal] Rights Management UI
On Thu, May 27, 2010 at 09:57, Ecaterina Valica <valicac(a)gmail.com> wrote:
Hi,
I want to talk a bit about:
Changing this is not hard, but it will increase complexity since we will
need a backward compatibility mode for existing wikis.
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.
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 <valicac(a)gmail.com> wrote:
_______________________________________________
users mailing list
users(a)xwiki.org
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 <dgl(a)softec.lu> wrote:
> Hi Caty,
>
> This one is simpler and more easy to understand than proposal 2 (which I
> liked but were complex). It is your best try IMO. I agree with Caty that
> using icons too reduce the place taken will not allow easy extensions.
But
> Alex proposal would help to have a summary
view, which is nice to have
> too.
>
> Maybe we could do both in fact. Propose a summary view (by default),
which
> fit a single line per user, this view would
present the common rights
> (V/C/E/D/A/(R/P)) using icons, and a last icon would be used to mention
> there is more special rights either inherited, allowed or denied. So we
> only
> need to use (and think about) a short icon representation for common
> rights,
> and extended rights will be represented by a single special
> representation.
> Rows could be expanded individually or globally so if you want a more
> detailled information, you may reach it either for a single user or all
at
> once. Changing common rights would be allowed
in collapsed mode and
> expanded
> mode, but changing special rights would only be allowed in expanded
view.
>
> If you want to keep the width even smaller, you may also colspan the
> user/group column over the others, using 2 rows per user, but I am not
> sure
> it will be nice. (Could this be only when horizontal space is short ?)
>
> I really like this one because it is simple to learn without
documentation
> and could also help learning how rights
works, but there is again
> some inconstancies with the current implementation. Compare to proposal
3,
> these inconsistencies may be nicely fixed and
really helps understanding
> why
> the right is disallowed at any time. You can do it like this:
>
> - the inheritance pop-up information should be at the right level in
> the inheritance columns. The rights are inherited and check
individually,
> so
> the precise source of inheritance is per rights, not only per user or
> group
> - there is a local source of inheritance: if the a right is allowed to
> anyone else at the same level, it is implicitly disallowed for any
others.
> So the source of inheritance is the local
level, implying a deny because
> the
> local level has at least a specific allow. This means than when you drag
> the
> first time a right in the allow column, all other user/group at the same
> level will have that right inherited deny from the current level. (For
> those
> who wonder and will check the source of the right service, yes, there is
> potential performance improvement by immediately denying when a
> non-matching
> allow is found, currently we continue to check right at higher level for
> more deny, this is not really clever)
>
> With these changes, I really feel that this last proposal could be a
real
> improvement in the way rights are applied,
and keeps the interface
simple
> at
> the same time.
>
> WDYT ?
>
> Denis
>
> On Sat, May 22, 2010 at 07:57, Ecaterina Valica <valicac(a)gmail.com>
> wrote:
>
> > On Fri, May 21, 2010 at 21:42, Alex Busenius <alex.busenius(a)xwiki.com
> > >wrote:
> >
> > > I like this version, it makes clear what is allowed/denied and why,
> but
> > > it takes a lot of space. What if those rights names would be
replaced
> by
> > > big icons and placed side by side? Like this (sorry for ASCII-art):
> > >
> > > -------------------+-------------------------------------+--+------
> > > Unregistered users | [+V] [+C] [+R] [-D] [-A] [-P] [-CC] | | [-E]
> > >
> > >
> > Big Icons:
> > We are using Silk set for our icons and this is constraining. Also,
> Rights
> > version 3-4 were made having rights extensibility in mind, for use
cases
> > like adding "captchaComment"
right, or "annotate" right, or
> > "applicationXusage" right .... so I don't think is very good if
> > applications
> > are gonna have to choose their custom icon to represent their custom
> right,
> > because is gonna be a mess in the UI.
> >
> > There are few possible icons to choose from (in order to keep the
> look&feel
> > unitary) and having the developers choose their own icon for the right
> they
> > extend is gonna break the UI consistency.
> > I think is much easier, extensible and less visual cryptic to textual
> > describe an extensible right.
> >
> > Placed side by side:
> > Version 4 takes a lot of space, yes, but the problem with side by side
> is
> > that is less readable (harder to scan the rights order). Also it's
> easier
> > to
> > have a bigger area to select when you want to drag an item.
> >
> > Thanks Alex for your feedback,
> > Caty
> >
> > >
> > > Alex
> > >
> > >
> > > On 05/21/2010 07:51 PM, Ecaterina Valica wrote:
> > > > Hi,
> > > >
> > > > Changes:
> > > >
> > > > - One additional column is added: "Default / Inherited
Rights",
> by
> > > > default all rights appear in this column
> > > > - By using drag'n'drop items are tossed around between
"Allow
> > rights",
> > > > "Deny rights" and "Default / Inherited Rights"
> > > >
> > > > Rights Proposal 4:
> > > >
> >
>
http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Rights4Proposal
> > Wiki Prototype:
> >
http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Rights4Wiki
> > Space Prototype:
> >
http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Rights4Space
> >
> > This proposal is done by using feedback provided by Roman Muntyanu
and
> > Raluca Morosan.
> > Thanks,
> > Caty
> > _______________________________________________
> > users mailing list
> > users(a)xwiki.org
> > http://lists.xwiki.org/mailman/listinfo/users
> >
> _______________________________________________
> devs mailing list
> devs(a)xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
>
_______________________________________________
users mailing list
users(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/users
--
Denis Gervalle
SOFTEC sa - CEO
eGuilde sarl - CTO
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
31 May
31 May
4:53 p.m.
New subject: [xwiki-users] [xwiki-devs] [Proposal] Rights Management UI
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 <dgl(a)softec.lu> wrote:
On Thu, May 27, 2010 at 09:57, Ecaterina Valica
<valicac(a)gmail.com> wrote:
I
mention
to
because
alex.busenius(a)xwiki.com
ASCII-art):
Muntyanu
_______________________________________________
users mailing list
users(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/users
--
Denis Gervalle
SOFTEC sa - CEO
eGuilde sarl - CTO
_______________________________________________
users mailing list
users(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/users
Hi,
I want to talk a bit about:
> The inheritance is a little bit particular, since allowing a given
right
at
Changing this is not hard, but it will increase complexity since we will
need a backward compatibility mode for existing wikis.
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.
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 <valicac(a)gmail.com>
wrote:
Hi,
Did:
- source of inheritance is per rights;
- local source of inheritance: if the a right is allowed to anyone else
at
> the same level, it is implicitly disallowed for any others;
> - inheritance from upper levels / groups.
>
> Please see if I put the rights correctly:
> Wiki Level:
> http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Rights41Wiki
> Space Level:
> http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Rights41Space
>
> Obs. Summary view + icons not done yet.
>
> Thanks,
> Caty
>
>
> On Sat, May 22, 2010 at 11:31, Denis Gervalle <dgl(a)softec.lu> wrote:
>
>> Hi Caty,
>>
>> This one is simpler and more easy to understand than proposal 2 (which >> 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 >> 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
proposal
> 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 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 >
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 >> 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 <valicac(a)gmail.com>
>> wrote:
>>
>> > On Fri, May 21, 2010 at 21:42, Alex Busenius < >> > >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 >> > >
>> > >
-------------------+-------------------------------------+--+------
> >> > > 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 and
> > > Raluca Morosan.
> > > Thanks,
> > > Caty
> > > _______________________________________________
> > > users mailing list
> > > users(a)xwiki.org
> > > http://lists.xwiki.org/mailman/listinfo/users
> > >
> > _______________________________________________
> > devs mailing list
> > devs(a)xwiki.org
> > http://lists.xwiki.org/mailman/listinfo/devs
> >
> _______________________________________________
> users mailing list
> users(a)xwiki.org
> http://lists.xwiki.org/mailman/listinfo/users
>
--
Denis Gervalle
SOFTEC sa - CEO
eGuilde sarl - CTO
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
4:54 p.m.
New subject: [xwiki-users] [xwiki-devs] [Proposal] Rights Management UI
On Mon, May 31, 2010 at 17:53, Ecaterina Valica <valicac(a)gmail.com> wrote:
Hi,
Summary Icons for standard rights:
*Space Level:*
http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Rights42Space
*Wiki Level*:
http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Rights4Proposal
Sorry: link for Wiki is
http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Rights42Wiki
Bug:
- when clicking on "more" next to the summary, all columns should expand,
not just one column at a time.
Missing:
- expand/collapse all + pagination, etc
Remarks:
- Summary view is good for quick scanning of the rights. Rights management
(changing) and inheritance explanations are available in expanded view.
- Icons presented just for: view, comment, edit, delete, admin, register,
programming. Extended rights|Expand mode are represented by "..." (more)
Thanks,
Caty
On Thu, May 27, 2010 at 11:26, Denis Gervalle <dgl(a)softec.lu> wrote:
On Thu, May 27, 2010 at 09:57, Ecaterina Valica
<valicac(a)gmail.com>
wrote:
mention
proposal
to
because
alex.busenius(a)xwiki.com
ASCII-art):
http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Rights4Proposal
--
Denis Gervalle
SOFTEC sa - CEO
eGuilde sarl - CTO
_______________________________________________
users mailing list
users(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/users
Hi,
I want to talk a bit about:
> The inheritance is a little bit particular, since allowing a given
right
at
Changing this is not hard, but it will increase complexity since we will
need a backward compatibility mode for existing wikis.
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.
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 <valicac(a)gmail.com>
wrote:
> Hi,
>
> Did:
> - source of inheritance is per rights;
> - local source of inheritance: if the a right is allowed to anyone
else
at
> the same level, it is implicitly disallowed for any others;
> - inheritance from upper levels / groups.
>
> Please see if I put the rights correctly:
> Wiki Level:
> http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Rights41Wiki
> Space Level:
>
http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Rights41Space
>
> Obs. Summary view + icons not done yet.
>
> Thanks,
> Caty
>
>
> On Sat, May 22, 2010 at 11:31, Denis Gervalle <dgl(a)softec.lu> wrote:
>
>> Hi Caty,
>>
>> This one is simpler and more easy to understand than proposal 2
(which I
>> liked but were complex). It is your best
try IMO. I agree with Caty
that
>> using icons too reduce the place taken
will not allow easy
extensions.
But
>> Alex proposal would help to have a summary view, which is nice to
have
> too.
>
> Maybe we could do both in fact. Propose a summary view (by default),
which
>> fit a single line per user, this view would present the common rights
>> (V/C/E/D/A/(R/P)) using icons, and a last icon would be used to >> 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
not
> 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 >> 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 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 >
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 >> 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 <valicac(a)gmail.com>
>> wrote:
>>
>> > On Fri, May 21, 2010 at 21:42, Alex Busenius < >> > >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 >> > >
>> > >
-------------------+-------------------------------------+--+------
>> > > 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:
> > > >
> >
>
>> > > > Wiki Prototype:
>> > > >
>> http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Rights4Wiki
>> > > > Space Prototype:
>> > > >
>>
http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Rights4Space
>> > > >
>> > > > This proposal is done by using feedback provided by Roman
Muntyanu
> and
> > > > Raluca Morosan.
> > > > Thanks,
> > > > Caty
> > > > _______________________________________________
> > > > users mailing list
> > > > users(a)xwiki.org
> > > > http://lists.xwiki.org/mailman/listinfo/users
> > > >
> > > _______________________________________________
> > > devs mailing list
> > > devs(a)xwiki.org
> > > http://lists.xwiki.org/mailman/listinfo/devs
> > >
> > _______________________________________________
> > users mailing list
> > users(a)xwiki.org
> > http://lists.xwiki.org/mailman/listinfo/users
> >
>
>
>
> --
> Denis Gervalle
> SOFTEC sa - CEO
> eGuilde sarl - CTO
> _______________________________________________
> devs mailing list
> devs(a)xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
>
_______________________________________________
users mailing list
users(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/users
1 Jun
1 Jun
9:03 a.m.
New subject: [xwiki-users] [xwiki-devs] [Proposal] Rights Management UI
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 <valicac(a)gmail.com> wrote:
On Mon, May 31, 2010 at 17:53, Ecaterina Valica
<valicac(a)gmail.com> wrote:
Also,
_______________________________________________
users mailing list
users(a)xwiki.org
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
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 <dgl(a)softec.lu> wrote:
> On Thu, May 27, 2010 at 09:57, Ecaterina Valica <valicac(a)gmail.com>
> wrote:
>
> > Hi,
> >
> > I want to talk a bit about:
> >
> > > The inheritance is a little bit particular, since allowing a given
> right
> > at
> > > lower level, will deny that same right for anybody else even if this
> > right
> > > is allowed at a higher level.
> > >
> >
> > I want to know how hard this would be to be changed.
> >
>
> Changing this is not hard, but it will increase complexity since we will
> need a backward compatibility mode for existing wikis.
>
>
> > Another question is why this has been done in the first place? Can
> someone
> > give a valid use case when this is more productive than other ways.
> >
>
> I really do not know, and I am curious as well.
>
>
> > It is very confusing and users need to do additional steps in order to
> give
> > the rights they want.
> >
>
> I completely agree, this is poor.
>
> I think is a problem of how the Groups are perceived. Only as a rights
> > mechanism or as a semantically grouping.
> >
>
> We should not decide this, since groups maybe synchronized from external
> system (ie LDAP), imposing groups for rights is not correct. By the way,
> groups may contains groups, but I am almost sure that this will work
> properly in practice.
>
>
> > If we use groups just to give rights than the current implementation
is
> > usable. But if you have groups, like
Tech team, Design team,
Marketing,
> > Happy team ... etc in order to classify
our users in other ways beside
> > rights management, giving permission to a user is breaking all the
> > inheritance from upper levels.
> >
> > Example:
> > Group A(Managers) has View (default allowed) at wiki level - this
means
> > that
> > they should be allowed to view all the pages in the wiki.
> > Group B(Tech Team) has View (explicitly denied) at spaceX level - this
> > means
> > they shouldn't be allowed to view this space.
> >
> > But I have a person (the managerX) in Group B that is supposed to see
> the
> > info in spaceX level. So the first logical move would be to give him
> allow
> > at space level (having in mind that space rights are stronger that
wiki
> > rights and the view right has been
overriden). But, if I give managerX
> view
> > right, all the other groups (incluing Managers) will be denied for
> spaceX
> > level. This means I need to know that and "repair" again all the
rights
> I
> > ALREADY set at the higher level.
> >
> > This behavior is not logical for me.
> >
>
> It is not logical for me and I imagine many others !
>
>
> >
> > A solution would be to take out managerX form Group B and leave it
just
> in
> > Managers group. Yes, this way my problem is solved, but this means
> Groups
> > are only used for Rights purposes. Group B (Tech Team) is no longer
> > semantically compact and I can't further give this group compact
tasks,
> > etc.
> >
> > Please tell if is a way to change this behavior and please have in
mind
> > XWiki 3.0, where Groups are going beyond
rights management and they
> should
> > be seen as collaboration mechanisms (which need to be semantical).
> >
>
> IMO, XWiki 3.0 should have a complete rework of the right service
> implementation, and breaks with the past.
> Since this will cause many migration issue, I am not in favor of
> progressive
> changes, and I would prefer to see a big single change that fix this,
and
> also the current discussion on script
rights.
>
> Denis
>
> Rights should be inherited from upper level and should affect only the
> > user/group where a change is made, not make some complicated
> implications
> > at
> > other levels and groups.
> >
> > Thanks,
> > Caty
> >
> > On Wed, May 26, 2010 at 16:48, Ecaterina Valica <valicac(a)gmail.com>
> wrote:
> >
> > > Hi,
> > >
> > > Did:
> > > - source of inheritance is per rights;
> > > - local source of inheritance: if the a right is allowed to anyone
> else
> > at
> > > the same level, it is implicitly disallowed for any others;
> > > - inheritance from upper levels / groups.
> > >
> > > Please see if I put the rights correctly:
> > > Wiki Level:
> > >
http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Rights41Wiki
> > > Space Level:
> > >
> http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Rights41Space
> > >
> > > Obs. Summary view + icons not done yet.
> > >
> > > Thanks,
> > > Caty
> > >
> > >
> > > On Sat, May 22, 2010 at 11:31, Denis Gervalle <dgl(a)softec.lu>
wrote:
> > >
> > >> Hi Caty,
> > >>
> > >> This one is simpler and more easy to understand than proposal 2
> (which I
> > >> liked but were complex). It is your best try IMO. I agree with Caty
> that
> > >> using icons too reduce the place taken will not allow easy
> extensions.
> > But
> > >> Alex proposal would help to have a summary view, which is nice to
> have
> > >> too.
> > >>
> > >> Maybe we could do both in fact. Propose a summary view (by
default),
> > which
> > >> fit a single line per user, this view would present the common
rights
> > >> (V/C/E/D/A/(R/P)) using icons,
and a last icon would be used to
> mention
> > >> there is more special rights either inherited, allowed or denied.
So
> we
> > >> only
> > >> need to use (and think about) a short icon representation for
common
> > >> rights,
> > >> and extended rights will be represented by a single special
> > >> representation.
> > >> Rows could be expanded individually or globally so if you want a
more
> > >> detailled information, you may
reach it either for a single user or
> all
> > at
> > >> once. Changing common rights would be allowed in collapsed mode and
> > >> expanded
> > >> mode, but changing special rights would only be allowed in expanded
> > view.
> > >>
> > >> If you want to keep the width even smaller, you may also colspan
the
> > >> user/group column over the
others, using 2 rows per user, but I am
> not
> > >> sure
> > >> it will be nice. (Could this be only when horizontal space is short
> ?)
> > >>
> > >> I really like this one because it is simple to learn without
> > documentation
> > >> and could also help learning how rights works, but there is again
> > >> some inconstancies with the current implementation. Compare to
> proposal
> > 3,
> > >> these inconsistencies may be nicely fixed and really helps
> understanding
> > >> why
> > >> the right is disallowed at any time. You can do it like this:
> > >>
> > >> - the inheritance pop-up information should be at the right level
in
> > >> the inheritance columns. The
rights are inherited and check
> > individually,
> > >> so
> > >> the precise source of inheritance is per rights, not only per user
or
> > >> group
> > >> - there is a local source of inheritance: if the a right is
allowed
> to
> > >> anyone else at the same level, it is implicitly disallowed for any
> > others.
> > >> So the source of inheritance is the local level, implying a deny
> because
> > >> the
> > >> local level has at least a specific allow. This means than when you
> drag
> > >> the
> > >> first time a right in the allow column, all other user/group at the
> same
> > >> level will have that right inherited deny from the current level.
> (For
> > >> those
> > >> who wonder and will check the source of the right service, yes,
there
> is
> > >> potential performance improvement by immediately denying when a
> > >> non-matching
> > >> allow is found, currently we continue to check right at higher
level
> for
> > >> more deny, this is not really clever)
> > >>
> > >> With these changes, I really feel that this last proposal could be
a
>
real
> >> improvement in the way rights are applied, and keeps the interface
> simple
> >> at
> >> the same time.
> >>
> >> WDYT ?
> >>
> >> Denis
> >>
> >> On Sat, May 22, 2010 at 07:57, Ecaterina Valica <valicac(a)gmail.com
> > >> wrote:
> > >>
> > >> > On Fri, May 21, 2010 at 21:42, Alex Busenius <
> alex.busenius(a)xwiki.com
> > >> > >wrote:
> > >> >
> > >> > > I like this version, it makes clear what is allowed/denied
and
> why,
> > >> but
> > >> > > it takes a lot of space. What if those rights names would be
> > replaced
> > >> by
> > >> > > big icons and placed side by side? Like this (sorry for
> ASCII-art):
> > >> > >
> > >> > >
> -------------------+-------------------------------------+--+------
> > >> > > Unregistered users | [+V] [+C] [+R] [-D] [-A] [-P] [-CC] |
|
> [-E]
> > >> > >
> > >> > >
> > >> > Big Icons:
> > >> > We are using Silk set for our icons and this is constraining.
> > >> Rights
> > >> > version 3-4 were made having rights extensibility in mind, for
use
> > cases
> > >> > like adding "captchaComment" right, or
"annotate" right, or
> > >> > "applicationXusage" right .... so I don't think is
very good if
> > >> > applications
> > >> > are gonna have to choose their custom icon to represent their
> custom
> > >> right,
> > >> > because is gonna be a mess in the UI.
> > >> >
> > >> > There are few possible icons to choose from (in order to keep the
> > >> look&feel
> > >> > unitary) and having the developers choose their own icon for the
> right
> > >> they
> > >> > extend is gonna break the UI consistency.
> > >> > I think is much easier, extensible and less visual cryptic to
> textual
> > >> > describe an extensible right.
> > >> >
> > >> > Placed side by side:
> > >> > Version 4 takes a lot of space, yes, but the problem with side by
> side
> > >> is
> > >> > that is less readable (harder to scan the rights order). Also
it's
> > >> easier
> > >> > to
> > >> > have a bigger area to select when you want to drag an item.
> > >> >
> > >> > Thanks Alex for your feedback,
> > >> > Caty
> > >> >
> > >> > >
> > >> > > Alex
> > >> > >
> > >> > >
> > >> > > On 05/21/2010 07:51 PM, Ecaterina Valica wrote:
> > >> > > > Hi,
> > >> > > >
> > >> > > > Changes:
> > >> > > >
> > >> > > > - One additional column is added: "Default /
Inherited
> Rights",
> > >> by
> > >> > > > default all rights appear in this column
> > >> > > > - By using drag'n'drop items are tossed
around between
> "Allow
> > >> > rights",
> > >> > > > "Deny rights" and "Default / Inherited
Rights"
> > >> > > >
> > >> > > > Rights Proposal 4:
> > >> > > >
> > >> >
> > >>
> >
>
http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Rights4Proposal
> > >> > > > Wiki Prototype:
> > >> > > >
> > >>
http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Rights4Wiki
>> > > > Space Prototype:
>> > > >
>>
http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Rights4Space
>> > > >
>> > > > This proposal is done by using feedback provided by Roman
Muntyanu
>> and
>> > > > Raluca Morosan.
>> > > > Thanks,
>> > > > Caty
>> > > > _______________________________________________
>> > > > users mailing list
>> > > > users(a)xwiki.org
>> > > > http://lists.xwiki.org/mailman/listinfo/users
>> > > >
>> > > _______________________________________________
>> > > devs mailing list
>> > > devs(a)xwiki.org
>> > > http://lists.xwiki.org/mailman/listinfo/devs
>> > >
>> > _______________________________________________
>> > users mailing list
>> > users(a)xwiki.org
>> > http://lists.xwiki.org/mailman/listinfo/users
>> >
>>
>>
>>
>> --
>> Denis Gervalle
>> SOFTEC sa - CEO
>> eGuilde sarl - CTO
>> _______________________________________________
>> devs mailing list
>> devs(a)xwiki.org
>> http://lists.xwiki.org/mailman/listinfo/devs
>>
>
>
_______________________________________________
users mailing list
users(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/users
--
Denis Gervalle
SOFTEC sa - CEO
eGuilde sarl - CTO
_______________________________________________
users mailing list
users(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/users
12:54 p.m.
New subject: [xwiki-users] [xwiki-devs] [Proposal] Rights Management UI
On Tue, Jun 1, 2010 at 10:03, Denis Gervalle <dgl(a)softec.lu> wrote:
Caty,
I probably have an issue with my browser (Chrome/Mac) but I cannot see the
icons :(
Fixed: thanks.
Made some screenshots with how it suppose to look like:
- Wiki:
http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Rights4Proposa…
- Space:
http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Rights4Proposa…
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/Rights4Proposa…
+ 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/Rights4Proposa…
+- 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/Rights4Proposa…
V2_wiki_expanded)
http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Rights4Proposa…
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/Rights4Proposa…
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/Rights4Proposa…
- 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/Rights4Proposa…
is equivalent to
V2_wiki)
http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Rights4Proposa…
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/Rights4Proposa…
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 <valicac(a)gmail.com> wrote:
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,
register,
beside
this
managerX
http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Rights41Space
Caty
or
am
be
the
_______________________________________________
users mailing list
users(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/users
--
Denis Gervalle
SOFTEC sa - CEO
eGuilde sarl - CTO
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
On Mon, May 31, 2010 at 17:53, Ecaterina Valica
<valicac(a)gmail.com>
wrote:
> Hi,
>
> Summary Icons for standard rights:
>
> *Space Level:*
> http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Rights42Space
> *Wiki Level*:
>
http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Rights4Proposal
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, > programming. Extended rights|Expand mode are
represented by "..."
(more)
>
> Thanks,
> Caty
>
>
> On Thu, May 27, 2010 at 11:26, Denis Gervalle <dgl(a)softec.lu> wrote:
>
>> On Thu, May 27, 2010 at 09:57, Ecaterina Valica <valicac(a)gmail.com>
>> wrote:
>>
>> > Hi,
>> >
>> > I want to talk a bit about:
>> >
>> > > The inheritance is a little bit particular, since allowing a given
>> right
>> > at
>> > > lower level, will deny that same right for anybody else even if
this
>> > right
>> > > is allowed at a higher level.
>> > >
>> >
>> > I want to know how hard this would be to be changed.
>> >
>>
>> Changing this is not hard, but it will increase complexity since we
will
>> need a backward compatibility mode for
existing wikis.
>>
>>
>> > Another question is why this has been done in the first place? Can
>> someone
>> > give a valid use case when this is more productive than other ways.
>> >
>>
>> I really do not know, and I am curious as well.
>>
>>
>> > It is very confusing and users need to do additional steps in order
to
>> give
>> > the rights they want.
>> >
>>
>> I completely agree, this is poor.
>>
>> I think is a problem of how the Groups are perceived. Only as a rights
>> > mechanism or as a semantically grouping.
>> >
>>
>> We should not decide this, since groups maybe synchronized from
external
>> system (ie LDAP), imposing groups for
rights is not correct. By the
way,
>
groups may contains groups, but I am almost sure that this will work
> properly in practice.
>
>
> > If we use groups just to give rights than the current implementation
is
> > usable. But if you have groups, like
Tech team, Design team,
Marketing,
>> > Happy team ... etc in order to classify our users in other ways > >
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 - >> > 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 > 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 <valicac(a)gmail.com>
> wrote:
> >
> > > Hi,
> > >
> > > Did:
> > > - source of inheritance is per rights;
> > > - local source of inheritance: if the a right is allowed to anyone
> else
> > at
> > > the same level, it is implicitly disallowed for any others;
> > > - inheritance from upper levels / groups.
> > >
> > > Please see if I put the rights correctly:
> > > Wiki Level:
> > >
http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Rights41Wiki
>> > > Space Level:
>> > >
>> > >
>
> > > Obs. Summary view + icons not done yet.
> > >
> > > Thanks,
> > > Caty
> > >
> > >
> > > On Sat, May 22, 2010 at 11:31, Denis Gervalle <dgl(a)softec.lu>
wrote:
>> > >
>> > >> Hi Caty,
>> > >>
>> > >> This one is simpler and more easy to understand than proposal 2
>> (which I
>> > >> liked but were complex). It is your best try IMO. I agree with
> 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
>> 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
>> 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
any
> > >> 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
>> > 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
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 <
valicac(a)gmail.com
>
>> > >> wrote:
>> > >>
>> > >> > On Fri, May 21, 2010 at 21:42, Alex Busenius <
>> alex.busenius(a)xwiki.com
>> > >> > >wrote:
>> > >> >
>> > >> > > I like this version, it makes clear what is
allowed/denied
and
> why,
> > >> but
> > >> > > it takes a lot of space. What if those rights names would be
> > replaced
> > >> by
> > >> > > big icons and placed side by side? Like this (sorry for
> ASCII-art):
> > >> > >
> > >> > >
> -------------------+-------------------------------------+--+------
> > >> > > Unregistered users | [+V] [+C] [+R] [-D] [-A] [-P] [-CC] |
|
> [-E]
> > >> > >
> > >> > >
> > >> > Big Icons:
> > >> > We are using Silk set for our icons and this is constraining.
Also,
> > >> Rights
> > >> > version 3-4 were made having rights extensibility in mind, for
use
>> > cases
>> > >> > like adding "captchaComment" right, or
"annotate" right, or
>> > >> > "applicationXusage" right .... so I don't think
is very good if
>> > >> > applications
>> > >> > are gonna have to choose their custom icon to represent
their
>> custom
>> > >> right,
>> > >> > because is gonna be a mess in the UI.
>> > >> >
>> > >> > There are few possible icons to choose from (in order to keep
>> > >> look&feel
>> > >> > unitary) and having the developers choose their own icon for
the
>> right
>> > >> they
>> > >> > extend is gonna break the UI consistency.
>> > >> > I think is much easier, extensible and less visual cryptic
to
>> textual
>> > >> > describe an extensible right.
>> > >> >
>> > >> > Placed side by side:
>> > >> > Version 4 takes a lot of space, yes, but the problem with
side
by
> side
> > >> is
> > >> > that is less readable (harder to scan the rights order). Also
it's
> > >> easier
> > >> > to
> > >> > have a bigger area to select when you want to drag an item.
> > >> >
> > >> > Thanks Alex for your feedback,
> > >> > Caty
> > >> >
> > >> > >
> > >> > > Alex
> > >> > >
> > >> > >
> > >> > > On 05/21/2010 07:51 PM, Ecaterina Valica wrote:
> > >> > > > Hi,
> > >> > > >
> > >> > > > Changes:
> > >> > > >
> > >> > > > - One additional column is added: "Default /
Inherited
> Rights",
> > >> by
> > >> > > > default all rights appear in this column
> > >> > > > - By using drag'n'drop items are tossed
around between
> "Allow
> > >> > rights",
> > >> > > > "Deny rights" and "Default / Inherited
Rights"
> > >> > > >
> > >> > > > Rights Proposal 4:
> > >> > > >
> > >> >
> > >>
> >
>
http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Rights4Proposal
> > >> > > > Wiki Prototype:
> > >> > > >
> > >>
http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Rights4Wiki
>
>> > > > Space Prototype:
> >> > > >
> >>
http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Rights4Space
> >> > > >
> >> > > > This proposal is done by using feedback provided by Roman
Muntyanu
> >> and
> >> > > > Raluca Morosan.
> >> > > > Thanks,
> >> > > > Caty
> >> > > > _______________________________________________
> >> > > > users mailing list
> >> > > > users(a)xwiki.org
> >> > > > http://lists.xwiki.org/mailman/listinfo/users
> >> > > >
> >> > > _______________________________________________
> >> > > devs mailing list
> >> > > devs(a)xwiki.org
> >> > > http://lists.xwiki.org/mailman/listinfo/devs
> >> > >
> >> > _______________________________________________
> >> > users mailing list
> >> > users(a)xwiki.org
> >> > http://lists.xwiki.org/mailman/listinfo/users
> >> >
> >>
> >>
> >>
> >> --
> >> Denis Gervalle
> >> SOFTEC sa - CEO
> >> eGuilde sarl - CTO
> >> _______________________________________________
> >> devs mailing list
> >> devs(a)xwiki.org
> >> http://lists.xwiki.org/mailman/listinfo/devs
> >>
> >
> >
> _______________________________________________
> users mailing list
> users(a)xwiki.org
> http://lists.xwiki.org/mailman/listinfo/users
>
--
Denis Gervalle
SOFTEC sa - CEO
eGuilde sarl - CTO
_______________________________________________
users mailing list
users(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/users
9 Jun
9 Jun
11:57 a.m.
New subject: [xwiki-users] [xwiki-devs] [Proposal] Rights Management UI
On 05/27/2010 10:26 AM, Denis Gervalle wrote:
+1.
On Thu, May 27, 2010 at 09:57, Ecaterina
Valica<valicac(a)gmail.com> wrote:
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.
Hi,
I want to talk a bit about:
Changing this is not hard, but it will increase complexity since we will
need a backward compatibility mode for existing wikis.
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.
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
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
12:24 p.m.
New subject: [xwiki-users] [xwiki-devs] [Proposal] Rights Management UI
On Wed, Jun 9, 2010 at 12:57, Sergiu Dumitriu <sergiu(a)xwiki.com> wrote:
On 05/27/2010 10:26 AM, Denis Gervalle wrote:
someone
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
On Thu, May 27, 2010 at 09:57, Ecaterina
Valica<valicac(a)gmail.com>
wrote:
> Hi,
>
> I want to talk a bit about:
>
>> The inheritance is a little bit particular, since allowing a given
right
at
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 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.
give a
valid use case when this is more productive than other ways.
I really do not know, and I am curious as well.
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.
the
in
progressive
> 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 > 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 > 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 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/>
2:04 p.m.
New subject: [xwiki-users] [xwiki-devs] [Proposal] Rights Management UI
On 06/09/2010 12:24 PM, Ecaterina Valica wrote:
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.
> 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. 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/
5310
days inactive
5330
days old
15 comments
5 participants
participants (5)
-
Alex Busenius -
Denis Gervalle -
Ecaterina Valica -
Guillaume Lerouge -
Sergiu Dumitriu