Hi Caty,
On May 10, 2010, at 3:39 PM, Ecaterina Valica wrote:
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.
* 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?
* In the page level view: "creator" and "administrators" is another
way of viewing the information on the left right? (not very clear to me)
* Probably not going to happen but if there are lots of admins, listing all admins on the
right will not scale.
* Is it planned that the user profile page will also show what the user has access to?
* 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.
* 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?
General comment:
* It looks powerful but complex
Good work. Let's fine tune this.
Thanks
-Vincent