|
Volker Weber points to a known but important issue regarding Groove's rolebased security model :
If you share a Groove space with a number of people, you can assign roles to them. They can be either manager, participant or guest. You can now define which permissions those roles have, both at the space or the individual tool level. Now let's assume you have one tool that contains data, which only managers are supposed to see, and you assign read permission only to managers. Participants and guests can see this tool tab but not the data in it. Everything is fine so far, although I would prefer to hide the tool completely. Now, here is the problem: If a participant duplicates the space he will automatically be manager of the duplicate and see all the data in the managers only tool. How bad is that?
Ray Ozzie sheds some light on this issue on his weblog :
Empirically our user interface hasn't helped the user to understand the difference between "tool access" and "data access", e.g. here's someone currently struggling with this issue - who thought that disabling the tool's UI also removed the data from his computer while it was disabled. That if you can't see it, it must not be there. And his point is very well taken: it's not his fault that our UI didn't make it clear that just the tool's UI was being disabled. We'll clearly be revisiting the Permissions user interface design in the next major release of the product. And in an effort to help people to understand the issue, we've updated the product's Web-based documentation, the release notes, the knowledge base, etc.
Ashok Hingorani suggests, in my opinion, the most logical solution on the Grooveforums : why not simply add this one more critical permisssion and the manager can decide whether space duplicates can be made at all. that way it is win win for all, the bug becomes a feature :)
|
|
