Hi,
On Mon, May 10, 2010 at 17:33, Vincent Massol <vincent(a)massol.net> wrote:
Hi Caty,
On May 10, 2010, at 3:39 PM, Ecaterina Valica wrote:
http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Rights2Proposal#HI…
Some comments/questions:
* Lots of things to like: inheritance, "simulation", not having to cycle
through rights, autosuggest, etc
* A bit hard to understand initially (I'm not sure I fully understand yet
:))
* Not sure it's scalable. In the future applications/components will be
able to register new rights. The proposed UI may not be the best fit for
this. A single tabular view for all rights would probably fit better,
possibly with a category selector if we want to keep the proposed categories
(admin rights vs register rights vs page rights vs programming rights). In
any case we need to think about rights scalability.
I didn't knew about this part. Can you give me an example of what this
means?
A group of rights could be labeled as "Administrator" and it should contain
"View" + "Edit" + "Comment" + "Delete" +
"Admin" + "Register"?
I give this use case, when I include the "View", "Edit",
"Comment", "Delete"
- because for users is not clear that "Admin" is including them, so maybe
they should be more explicitly showed.
Another group could be labeled as "Reviewer" and this could include
"View" +
"Edit" + "Comment".
Another group could be "Developer" and could include "View" +
"Edit" +
"Delete" + "Programming".
Is this what you mean by extensible? Or extensible means that in the future
maybe you'll want to add more rights, like "Delete Comments", etc?
* Not sure I understand the "containing
spaces/pages" UI. Should the
"contain" table header be "Space" (or "Page") instead? Is
it a "simulation"
to see the rights for a given space or page?
The idea was to explicitly show the children that are gonna to inherit the
rights specified in that level. Also to show what elements have declared
other rights, than the ones specified in the level, by this overridden them.
And also is should have been acting like a navigation model towards the
children.
* In the page level view: "creator" and
"administrators" is another way of
viewing the information on the left right? (not very clear to me)
The "creator" is a special attribute and the owner can also "delete"
the
page. I decided to represent this attribute. (if he created, then he has
"edit", if "edit" than he has "view", and as a creator he
must also have
"comment" in order to take care of the page).
The "administrators" part: In the page level you can't set admins (only in
the space and wiki), but from an inheritance point of view, there are people
that have rights for that page, that's why I decided to represent them. To
be clear why "rstavro" can delete my page, even if she isn't in the
"Page
Rights" section (she is set as an admin at the space level).
* Probably not going to happen but if there are lots
of admins, listing all
admins on the right will not scale.
we can have pagination.
* Is it planned that the user profile page will also
show what the user has
access to?
yep, but not done yet.
* How are right modifications saved? A big problem
with the current UI is
that there's no save action and a lot of modifications are done unitarily
leading to lots of events sent + hard to rollback as a consequence.
http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Rights2Proposal#HU…
making changes to the rights, the "Save"/"Reset" actions are shown.
* How does it work? For example, imagine a space with
no rights at all. I
then click allow for the view rights for the admin group for ex. What
happens? Does it immediately refresh all views and put a "x" in for all
other groups and users not in the admin group?
The space is always gonna show the rights inherited from the wiki level.
Thanks for the feedback,
Caty
General comment:
* It looks powerful but complex
Good work. Let's fine tune this.
Thanks
-Vincent
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs