I’ve stated before one thing I like about openplans is the “simple” permission simple. I use the quotes because there are several caveats, one of which I’ll address here. For a particular project, the permission system is essentially a 3×4 table:
| agent\project type |
Open |
Medium |
Closed |
| anonymous | view | view | X |
| site member |
edit | view | X |
| project member |
edit | edit | edit |
| project admin |
manage | manage | manage |
This is pretty simple and intuitive I think. We also have a status of being listed on a project. That is, can people see you’re part of the team. If you’re a whistleblower at exxon, you might not want your company to see that you’re part of the ExxonIsSatan project, for instance. For a particular project, other members can see information about your affiliation according to the following rubrik:
| Listed | Not Listed |
|
| anonymous | view | X |
| site member |
view | X |
| project member |
view | view |
| project admin |
view | view |
I’m being intentionally over-verbose here for illustration. If user A wants to see information concerning member B about his affiliation with project C, how does this work?
- can user A view project C?
- can user A view member B’s affiliation with project C?
So its a cascaded permission system, if you will (or something like that, anyway). My main reason for posting this is to put this in programmatic terms and to see what others thought about this. We’re not really taking advantage of as much as we can here, and I’m tempted to say that intelligent use of roles could make this all happen behind the curtain, which would be my preference. Also, why not have a reference on line?
[Disclaimer: no exxon executives, stakeholders, or stock prices were harmed either financially or materially in the writing of this post]

No Comments
RSSNo comments yet.
Leave a comment