Hi Caty,
On Thu, Jun 3, 2010 at 18:09, Ecaterina Valica <valicac(a)gmail.com> wrote:
This is pleasure to participate especially because you provide really good
proposals.
I would also like to see others participating, currently the discussion is
becoming to much bilateral IMO.
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.
I am not sure what are really your intend. I think that the big tooltips
describing the rights should be the only tooltips, and should be show on
hover only after a small timeout (like the yellow one currently). Clicking
any where on the +/- icon or v would then open the menu.
Is it what you try ?
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 <dgl(a)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#H…
Sorry to insist, but the information regarding the advanced rights is still
missing in collapsed mode.
I really would like to have a indicator that some advanced rights has been
set locally or not without having to go advanced mode. Else, you will have
to expand all rows to check that information, which is not practical.
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#H…
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/Rights43Propos…
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.
I think we need some polishing on the icons used. Building them specifically
would be nice, but I do not know if you or anyone want to have a try at
that. My feeling is that the couple +/- or better v/x and the right icon
should be built together and closer to each other providing the information
as a whole and not giving the impression of two part. Using a v for
suggesting the menu is nice, could be even improved by styling some "button
like" borders on hover.
All menus could also be improved by using the inheritance arrow married with
+/- (or v/x) to show immediately what will be the right if inheritance is
used.
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.
Why not just use the big Icons from the menu (using the inheritance arrow
married with +/- as proposed above), and directly followed by the v arrow.
All this in front of the text ?
Using a generic icon will not improve information and detailed view of
advanced right in collapsed mode is not expected.
It is not clearly shown on your samples, how multiple advance right would be
shown. I think one per row is nice, or if you want to limit space, 2 or 3 at
most, shown in columns ?
I also wonder is this would help or not to also extends basic rights in
advanced mode, showing the icons and the text ?
Another thing we need to consider for this proposal is how the filtering is
gonna be made.
Good point. Here is some proposal for each column:
1) a dropdown list proposing local (default), global or both ?
2) a textbox which filter on names
3) a dropdown list proposing all (default), hide inherited only, and maybe
the list of rights, showing only rows where the selected right is set
locally ?
WDYT ?
Denis
On Tue, Jun 1, 2010 at 12:54, Ecaterina Valica <valicac(a)gmail.com>
wrote:
> 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…
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
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…
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:
>
> > 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:
> >>
> >> > 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
> >>
> >
> >
> _______________________________________________
> 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
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs