atom feed57 messages in org.xwiki.usersRe: [xwiki-users] [xwiki-devs] [Prop...
FromSent OnAttachments
1 earlier message
Guillaume LerougeMay 10, 2010 7:01 am 
Ecaterina ValicaMay 10, 2010 7:07 am 
Thomas MortagneMay 10, 2010 8:21 am 
Ecaterina ValicaMay 13, 2010 1:57 am 
Ecaterina ValicaMay 18, 2010 2:03 am 
Guillaume LerougeMay 18, 2010 8:08 am 
Denis GervalleMay 18, 2010 8:29 am 
Ecaterina ValicaMay 19, 2010 3:23 am 
Ecaterina ValicaMay 19, 2010 3:39 am 
Denis GervalleMay 19, 2010 6:52 am 
Ecaterina ValicaMay 19, 2010 7:33 am 
Ecaterina ValicaMay 20, 2010 9:18 am 
Guillaume LerougeMay 20, 2010 9:21 am 
Ecaterina ValicaMay 21, 2010 10:51 am 
Alex BuseniusMay 21, 2010 11:42 am 
Ecaterina ValicaMay 21, 2010 10:57 pm 
Denis GervalleMay 22, 2010 1:31 am 
Ecaterina ValicaMay 26, 2010 6:48 am 
Ecaterina ValicaMay 27, 2010 12:57 am 
Denis GervalleMay 27, 2010 1:26 am 
Ecaterina ValicaMay 31, 2010 7:53 am 
Ecaterina ValicaMay 31, 2010 7:54 am 
Denis GervalleJun 1, 2010 12:03 am 
Ecaterina ValicaJun 1, 2010 3:54 am 
Ecaterina ValicaJun 3, 2010 9:09 am 
Denis GervalleJun 4, 2010 12:42 am 
Ecaterina ValicaJun 4, 2010 9:54 am 
Alex BuseniusJun 4, 2010 10:57 am 
Ecaterina ValicaJun 4, 2010 11:23 am 
Raluca StavroJun 4, 2010 11:33 am 
Raluca StavroJun 4, 2010 11:36 am 
Alex BuseniusJun 4, 2010 12:05 pm 
Denis GervalleJun 4, 2010 3:53 pm 
Ecaterina ValicaJun 7, 2010 1:22 am 
Ecaterina ValicaJun 7, 2010 1:50 am 
Denis GervalleJun 7, 2010 2:24 am 
Ecaterina ValicaJun 7, 2010 8:00 am 
Ecaterina ValicaJun 8, 2010 2:19 am 
Denis GervalleJun 8, 2010 3:46 am 
Raluca StavroJun 8, 2010 4:44 am 
Ecaterina ValicaJun 8, 2010 6:41 am 
Denis GervalleJun 8, 2010 8:14 am 
Philip BrunettiJun 8, 2010 6:54 pm 
Caleb James DeLisleJun 8, 2010 7:31 pm 
Vincent MassolJun 9, 2010 12:25 am 
Sergiu DumitriuJun 9, 2010 2:57 am 
Ecaterina ValicaJun 9, 2010 3:24 am 
Ecaterina ValicaJun 9, 2010 3:36 am 
Sergiu DumitriuJun 9, 2010 3:45 am 
Sergiu DumitriuJun 9, 2010 5:02 am 
6 later messages
Subject:Re: [xwiki-users] [xwiki-devs] [Proposal] Rights Management UI
From:Ecaterina Valica (vali@gmail.com)
Date:Jun 3, 2010 9:09:21 am
List:org.xwiki.users

Hi Denis,

I want to thank you again for all the help you are giving :P

Please take a look at a proposal for "V3 and my 3)" version with elements from Rights2 :) http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Rights43Proposal and in "action" http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Rights43Space

The prototype is not reflecting the "desired" interaction: both inherited info and rights change appear on hover (right icon and arrow), instead of hover | click.

That "v" needs to be an arrow like the one we use in the action menus.

On Tue, Jun 1, 2010 at 19:06, Denis Gervalle <dg@softec.lu> wrote:

Caty,

Really nice and interesting post, I will try to reach that level... but without visual :\

I really think that using the collapsed view for editing would helps basic users to have a simplified and more easy interface to understand. We may even imagine that only "advanced user" (those marked so in their profile), has access to the expanded view.

I think that the collapsed view missed an additional icon that summarize the rights that are not shown. This one would only be shown if there is any non-defaulted additional right in action.

This is a signal that extended

rights are in use (See it like the grey box of Windows when special rights are setup, which is inviting to go into advanced view to know more). This one would be obviously not editable, and should probably work like the ... or replace it ? In place of the ... . Concerning the ..., I am not sure, but I would also prefer to see a textual link "advanced" in small font, and only visible when row is hovered.

http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Rights43Proposal#HRowhover

Order of right are not significant, so I would prefer that in all view, these where in the same order, with the basic right first (V/C/E/D/A/P) and the additional right in their order of registration (hope that it will stay constant... or we will have to find a way to keep them ordered). The "right" part of each icon should be grayed if the right is inherited and not grayed if the right is set locally, this improve the information provided in V3.

http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Rights43Proposal#HAfterclick

The problem with this icons (taken from Silk) is that there is little difference for View, Comment, Admin icons between the two states (inherited, locally set) - but this is something we can easily improve (by changing the icons and looking for some more contrast). Example: This is how they look when all rights are set locally (full color) http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Rights43Proposal/fullColors.png

I also think that the +/- (which is never grayed) could be nearer to the right icon. Maybe you could use a green V and a read "stop" in place of +/- ?

The other mockup versions (like http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Rights41Space) used v/x for the allow/deny representation, and yes, I agree that they are more suited than +/-.

The problem is that we are using in XWiki, X to represent delete, so having two xX was too much, that's why I introduced +/-. Maybe we can find another solution.

Regarding the collapsed view, I see three possibilities to investigate for allowing edition while improving readability (note that readability has the same issue in expanded view, but it seems to be less annoying) :

1) use V3, but when hovering a row, use V2 on that row and allow drag/drop (keeping V2 until drop even is hover is temporary lost). Not sure this will be nice in practice ? see 2)

2) use a presentation in 4 columns, for both collapsed and expanded view, the first column behing a read-only summary like V3, and the 3 column being an ordered V1. However, dragging from summary would be allowed. The 3 detailed column could be shown only when a drag is started from summary, or with a global horizontal expansion button... Basic user would have access to this, but not necessarily to vertical row expansion. Not sure this is not an increase in complexity ? so, see 3)

3) use V3, and a similar interface to what we have in current right management interface. Since saved are postponed (not like we have currently), using this one may be both practical and could helps the transition for existing user as well. With all the belts and whistle added to clearly state changes and inheritance, this will be similar but really better than what we have.

If we go for V3 and my 3) proposal, I also wonder if the current table header is well done. I do not like it when nothing is expanded since it is confusing, too large, and not significant. It will be even more unexpected if you follow me on the "advance user" case, when a basic user look at it. Maybe you could try a changing header, only expanding when there is expanded row, or, you could move the expanded header in each expanded row, keeping a simplified header at the top.

WDYT ?

Denis

Other problem that this proposal has is the representation of "advanced rights". If we don't like the textual description and we want to add icons, IMO we have two solutions:

A) use the same abstract icon, but with different color, ex. a key or lock icon with color representation ("blue" for "programming", "green" for "captchaComment", etc) - the problem here is for the people that have some kind color blindness and will not distinguish between some color tones (this is the case when we gonna have lots of "advanced" | non default rights)

B) use the same abstract icon and with an order index (like numbers 1, 2, etc or characters A, B, etc)

These representations are based on the fact that "advanced rights" will be added by other developers and the icon will not be custom made for a specif right.

Another thing we need to consider for this proposal is how the filtering is gonna be made.

On Tue, Jun 1, 2010 at 12:54, Ecaterina Valica <vali@gmail.com> wrote:

On Tue, Jun 1, 2010 at 10:03, Denis Gervalle <dg@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/Rights4Proposal/wiki42View.png

- Space:

http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Rights4Proposal/space42View.png

Anyway this seem to me nice, but I am not sure you should prevent changing rights in summary mode. I think that summary mode should allow simple right management, and for 'casual' or less knowledgeable users, this should be the only mode used. This is not only a summary, but also a simplified interface.

WDYT ?

I had your vision (changing rights in summary mode) in mind when I started prototyping. Let me show you some versions:

V1_space) First version took the exact order from the extended view (first Allow, second Deny rights)

http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Rights4Proposal/spaceTest1.png

+ this version lets the user drag its right to the appropriate column +- has the same representation as the extended version --- there is no scanability: if I want to see the status of "delete" right for different groups/users I have to search for them (making me dizzy :P ) + there is no gapping space between rights

V2_space) Tried to fix the dizziness by providing same order/position for rights

http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Rights4Proposal/spaceTest2.png

+- this version lets the user drag its right to the appropriate column, but the user has not control over the position he choose to drop the target: the right will appear on the column it's suppose to be +- doesn't have the same representation as the extended version (allowed/denied order broke, determined order present) + scanability: it's easy to scan for the searched column/position - gap space between rights: ex. evalica-DenyDelete: some users might not like that gap and may not understand why is there (is it a bug?)

See also: V2_wiki)

http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Rights4Proposal/wikiTest2.png

V2_wiki_expanded)

http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Rights4Proposal/wikiTest21.png

As you see in V2) has the same functionality as the expanded version. The main benefit is that is occupying less space, but we still need the expanded view for the Inherited/detailed information for each right.

The down side of version 2

http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Rights4Proposal/wikiTest2.png

is that if I want to *summarize *a global state for a given right (ex see for what users 'delete' is allowed/denied) at a global level, not at a group/user level, the same dizziness effect appears (I have to search for 'delete' right in three columns, for all the users)

V3) is the current proposal, it compresses the 3 column spread information in one view.

http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Rights4Proposal/space42View.png

- this version doesn't lets the user drag its right to the appropriate column +- doesn't have the same representation as the extended version + scanability: it's easy to scan for the searched column/position at a * global* level + there is no gapping space between rights

V3_wiki)

http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Rights4Proposal/wikiTest3.png

is equivalent to V2_wiki)

http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Rights4Proposal/wikiTest2.png

I prefer V3) over V2): + Summary does what is suppose to: give a global summary of existing rights, without being concerned of the type of the right (inherited, locally allowed, locally denied) + Good Readability +/- Doesn't allow rights to be dragged around. I prefer changing rights in expanded mode because there you also have more information, like source of the inheritance + 3 columns.

Being compact it's easier to understand the "local source of inheritance" for a given right. For example, allowing "view" right for 'evalica' will deny it for 'unregistered users' and 'registered users'. Being on the same column is easier to look for the change and see it in action (being highlighted).

http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Rights4Proposal/space42View.png

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 <vali@gmail.com> wrote:

On Mon, May 31, 2010 at 17:53, Ecaterina Valica <vali@gmail.com> wrote:

Hi,

Summary Icons for standard rights:

*Space Level:*

http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Rights42Space

*Wiki Level*:

http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Rights4Proposal

Sorry: link for Wiki is

http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Rights42Wiki

Bug: - when clicking on "more" next to the summary, all columns should expand, not just one column at a time.

Missing: - expand/collapse all + pagination, etc

Remarks: - Summary view is good for quick scanning of the rights. Rights management (changing) and inheritance explanations are available in expanded view. - Icons presented just for: view, comment, edit, delete, admin, register, programming. Extended rights|Expand mode are represented by "..." (more)

Thanks, Caty

On Thu, May 27, 2010 at 11:26, Denis Gervalle <dg@softec.lu> wrote:

On Thu, May 27, 2010 at 09:57, Ecaterina Valica < vali@gmail.com> wrote:

Hi,

I want to talk a bit about:

The inheritance is a little bit particular, since allowing a

given

right

at

lower level, will deny that same right for anybody else even

if

this

right

is allowed at a higher level.

I want to know how hard this would be to be changed.

Changing this is not hard, but it will increase complexity since

we

will

need a backward compatibility mode for existing wikis.

Another question is why this has been done in the first place?

Can

someone

give a valid use case when this is more productive than other ways.

I really do not know, and I am curious as well.

It is very confusing and users need to do additional steps in

order

to

give

the rights they want.

I completely agree, this is poor.

I think is a problem of how the Groups are perceived. Only as a

rights

mechanism or as a semantically grouping.

We should not decide this, since groups maybe synchronized from external system (ie LDAP), imposing groups for rights is not correct. By

the

way,

groups may contains groups, but I am almost sure that this will work properly in practice.

If we use groups just to give rights than the current

implementation

is

usable. But if you have groups, like Tech team, Design team, Marketing, Happy team ... etc in order to classify our users in other ways beside rights management, giving permission to a user is breaking all the inheritance from upper levels.

Example: Group A(Managers) has View (default allowed) at wiki level -

this

means

that they should be allowed to view all the pages in the wiki. Group B(Tech Team) has View (explicitly denied) at spaceX level

-

this

means they shouldn't be allowed to view this space.

But I have a person (the managerX) in Group B that is supposed

to

see

the

info in spaceX level. So the first logical move would be to give

him

allow

at space level (having in mind that space rights are stronger

that

wiki

rights and the view right has been overriden). But, if I give

managerX

view

right, all the other groups (incluing Managers) will be denied

for

spaceX

level. This means I need to know that and "repair" again all the

rights

I

ALREADY set at the higher level.

This behavior is not logical for me.

It is not logical for me and I imagine many others !

A solution would be to take out managerX form Group B and leave

it

just

in

Managers group. Yes, this way my problem is solved, but this

means

Groups

are only used for Rights purposes. Group B (Tech Team) is no longer semantically compact and I can't further give this group compact tasks, etc.

Please tell if is a way to change this behavior and please have

in

mind

XWiki 3.0, where Groups are going beyond rights management and

they

should

be seen as collaboration mechanisms (which need to be semantical).

IMO, XWiki 3.0 should have a complete rework of the right service implementation, and breaks with the past. Since this will cause many migration issue, I am not in favor of progressive changes, and I would prefer to see a big single change that fix

this,

and

also the current discussion on script rights.

Denis

Rights should be inherited from upper level and should affect only

the

user/group where a change is made, not make some complicated implications at other levels and groups.

Thanks, Caty

On Wed, May 26, 2010 at 16:48, Ecaterina Valica <

vali@gmail.com>

wrote:

Hi,

Did: - source of inheritance is per rights; - local source of inheritance: if the a right is allowed to

anyone

else

at

the same level, it is implicitly disallowed for any others; - inheritance from upper levels / groups.

Please see if I put the rights correctly: Wiki Level:

http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Rights41Wiki

Space Level:

http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Rights41Space

Obs. Summary view + icons not done yet.

Thanks, Caty

On Sat, May 22, 2010 at 11:31, Denis Gervalle <dg@softec.lu> wrote:

Hi Caty,

This one is simpler and more easy to understand than proposal

2

(which I

liked but were complex). It is your best try IMO. I agree

with

Caty

that

using icons too reduce the place taken will not allow easy

extensions.

But

Alex proposal would help to have a summary view, which is

nice

to

have

too.

Maybe we could do both in fact. Propose a summary view (by

default),

which

fit a single line per user, this view would present the

common

rights

(V/C/E/D/A/(R/P)) using icons, and a last icon would be used

to

mention

there is more special rights either inherited, allowed or

denied.

So

we

only need to use (and think about) a short icon representation for common rights, and extended rights will be represented by a single special representation. Rows could be expanded individually or globally so if you

want

a

more

detailled information, you may reach it either for a single

user

or

all

at

once. Changing common rights would be allowed in collapsed

mode

and

expanded mode, but changing special rights would only be allowed in

expanded

view.

If you want to keep the width even smaller, you may also

colspan

the

user/group column over the others, using 2 rows per user, but

I

am

not

sure it will be nice. (Could this be only when horizontal space is

short

?)

I really like this one because it is simple to learn without documentation and could also help learning how rights works, but there is again some inconstancies with the current implementation. Compare

to

proposal

3,

these inconsistencies may be nicely fixed and really helps understanding why the right is disallowed at any time. You can do it like this:

- the inheritance pop-up information should be at the right

level

in

the inheritance columns. The rights are inherited and check individually, so the precise source of inheritance is per rights, not only per

user

or

group - there is a local source of inheritance: if the a right is

allowed

to

anyone else at the same level, it is implicitly disallowed

for

any

others.

So the source of inheritance is the local level, implying a

deny

because

the local level has at least a specific allow. This means than

when

you

drag

the first time a right in the allow column, all other user/group

at

the

same

level will have that right inherited deny from the current

level.

(For

those who wonder and will check the source of the right service,

yes,

there

is

potential performance improvement by immediately denying when a non-matching allow is found, currently we continue to check right at

higher

level

for

more deny, this is not really clever)

With these changes, I really feel that this last proposal

could

be

a

real

improvement in the way rights are applied, and keeps the

interface

simple

at the same time.

WDYT ?

Denis

On Sat, May 22, 2010 at 07:57, Ecaterina Valica <

vali@gmail.com

wrote:

On Fri, May 21, 2010 at 21:42, Alex Busenius <

alex@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

http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Rights4Space

This proposal is done by using feedback provided by

Muntyanu

and

Raluca Morosan. Thanks, Caty