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. 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
_______________________________________________
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