cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Showing results for 
Search instead for 
Did you mean: 

Community Tip - Did you get called away in the middle of writing a post? Don't worry you can find your unfinished post later in the Drafts section of your profile page. X

Container design question as it relates to ECR/ECN activites

JoePriest
10-Marble

Container design question as it relates to ECR/ECN activites

We are talking about our Container Design Strategy for PDMLink and we are curious as to how you organize your data (drawings, models, parts). Do you put your PD data in the same container as your supporting MFG data? I ask because as we think about how that data will change (ECR/ECN) and how the Team is organized, we are concerned about how the right people are identified across containers so as to be able to participate on the same collective change. We have some requirements internally where we don’t allow MFG to see unreleased PD data (there are some exceptions). This would lend itself to either folder level authorizations (which we want to avoid for complexity/performance reasons) or having separate containers for their data which gives us the problems of the Change Team being identified by the first item placed on the ECR / ECN. Maybe our data requirements are unique…maybe not. Thanks.

1 REPLY 1

Joe, Assuming 9.1?

Your requirements are not unique. Keep in mind you can soft type containers and folders and parts / documents to drive ACL creation. You do not soft type solely to add attributes.

Add additional more specific roles to the team. Don't say desinger, say designer type x.

Also do not forget ad hoc acl creation. When the change process is going you can iterate through affected data and grant temporary modify or read access etc.

I'm suggesting for our system to implement create permission, but deny modify to everything, unless there is a pending ECN or work authorization to change it.

There is also security labels, role profiles, and actions that can be disabled per container. And more can be added via roleaccessprefs.xml.

The more time you think this through upfront, the easier production support will be.

You can also use multiple organizations where MFG users are placed using principal administrator into a separate MFG organization. Enable search and sharing of users on that 2nd org as well disable ability to have separate containers in that org. When users of a different organization are members of a role of a container of a different organization, they ONLY have read and download access. Even if they are team members of the container. You have to explicity grant additional ACL's. Multiple is a lot less riskier in 9.x! Use them where they make sense to make system administration EASIER!

In general, you want to avoid patching with ACL's as much as possible.

E-mail me if you have any questions.


Hope that helps,
David DeMay


Sent from my Verizon Wireless BlackBerry
Announcements


Top Tags