Ronan - Wednesday, December 1, 2010 1:50 PM:
Hello,
In this post I'm not expecting a precise answer, because the case depends a lot on client requirements; my goal is more to get some feedback and ideas. Here we go:
- How would you implement per-project permissions?
Typical client use case: "Bob is part of projects P1 and P2, Alice is part of project P3. Bob shouldn't see documents 'belonging' to project P3, and Alice shouldn't see documents 'belonging' to projects P1 and P2" - How would you avoid/limit the obvious segregation consequences of this approach (i.e. implement exceptions)? PLM is all about data reuse, so while considering Project at the top of the data structure seems fine initially (note: this is the structure of Windchill for example), it kinda creates per-project data silos, and ends up hindering reuse possibilities.
In my experience this is a very common query from clients. Point 1 can be addressed (methods responding to OnGet events for example), but point 2 is tougher. How would you address both of them? What is your approach with clients requesting 1 but failing to see the consequences mentioned in 2?
Thanks.
Brian - Wednesday, December 1, 2010 10:32 PM:
Hi Ronan,
I have been pondering the same question.
For one client the solution was relatively simple. We would just use one database per project. Not very sophisticated and definitely creating silos but there is enough separation between the projects that it wasn't considered an issue.
Using this approach it might be possible to run a per project database and then set up a behind the scenes share/update for "common" documents via SQL. Still not very nice as approaches go.
I like the idea of "tagging" items (any items) with one or more "project" references and giving users access to specific "tags". Tags relationships would be a very low level relationship type that should be automatically created whenever a new item type is created and would therefore allow anything to be tagged.
Be default I think Items would be available to all users but a "Default" tag could be applied based on the Logged on User for creation of new Items. Users who have access to multiple "Tags" get a choice of what tags to apply to any item they create.
The later access of information would be through a combination of the "Tags" and the current Permissions model. The Tags applying first then the standard permission model.
When a user logs on their default tag is read and all data access subsequent to that is filtered first by the "tag" or "tags" assigned to them.
It adds a level of complexity to all data transactions and therefore is not something that all customers would want.
This would also give you the ability to retrieve all item types based on a certain "tag". All Items that are common across multiple tags and items that have no tags attached at all (these would be visible to everyone based on their normal permissions model).
So far I have only thought about this and not tried to implement any of it.
It has the feel of needing to be "core" code so that you can't get around it in methods unless you are very deliberate (like Granting permission in a method) though I have toyed with the idea of building a prototype system based on this arrangement.
Cheers,
Brian
Ronan - Thursday, December 2, 2010 9:44 AM:
Hi Brian,
I like your idea of tags, and I second your feeling that it should be "core" code, because it has to be: 1. low-level and secure (like you mentioned), 2. homogeneous across all ItemTypes, and 3. "understood" by the rest of the application.
With point 3 I mean "not causing side effects in parts of the app because expected data isn't accessible": for example I played with methods replacing OnGet and faced some weird cases, like where relationship data was visible but not item data (meaning for example a BOM where you can see the structure --relationship data-- but not the part names/numbers --item data--). All this to say that it's quite low-level and looks hard to do properly via normal methods without lots of workarounds and edge cases.
To be continued... thanks for your feedback.
RobMcAveney - Thursday, December 2, 2010 10:46 AM:
Aras is working on a "Team Permissions" feature for a near-term future release. Each item may have a pointer to a Team (a set of identities with optional role assignments). Permissions may then be assigned to the entire team or to a role within the team. Teams may be unique to an item or shared between items. The intent is to enable customers to have shared "project teams" that can be referenced by all items that belong to that project.
The next step would be to provide pointers to multiple teams and a mechanism to union/intersect team membership to calculate permissions. I like Brian's idea of tags to allow for multiple pointers. I think the hardest part is to optimize performance in such an open-ended model. It sounds like there may be enough interest out there to pool resources to get this feature developed. Would you guys be willing to collaborate on a specification that we can use as a starting point?
Rob
Brian - Thursday, December 2, 2010 4:07 PM:
Hi Rob,
More than happy to collaborate on this or other developments. I see this as an important issue as many clients have multiple groups (teams) working on different data and especially in a Defence Classified environment they need clear separation of data.
Send me an email direct to [email protected] and we can open discussions.
Cheers,
Brian.
Ronan - Tuesday, December 7, 2010 9:43 AM:
Hi Rob & Brian,
I'll be glad to collaborate on this spec. Good last point from Brian: it will also help for projects requiring defence compliance (ITAR, etc).
You can reach me at rjouchet {at} processia.com
Bye
