Community Tip - You can change your system assigned username to something more personal in your community settings. X
Hi everyone,
this particular part while customizing is confusing me a lot. Please help!
Q. is it possible to restrict users from accessing CAD/NonCAD documents in different life cycle states in windchill pdmlink?
Example Scenario:
I have users userA, userB, userC, userD, userE.
I have groups groupA(uploader), groupB(viewer), groupC(approver)
I have defined custom profiles and created teams also.
Lifecycle states: Inwork -> Approved -> Obsolete
What I want is userB should be restricted to view files only in Approved state and not other files(CAD/NonCAD) in Inwork or Obsolete state. I have created a lifecycle state and designated roles and access control to only read to userB and added this lifecycle in OIR but is of no good?
Am I doing it right? or should I run any command after changing OIR to implement those changes? Kindly help.
Solved! Go to Solution.
OTB, there are many ACLs for the "TeamMembers" Role - and these can play havoc with an otherwise well-designed approach. TeamMembers (distinct from but including "Members") includes all Roles except Manager and Guest. OTB, the TeamMembes Role can pretty much do everything. This may be why the user b below can read when not desired. Drill down to the specific statement.
Short answer: Yes, absolutely both possible and essential to configure.
It's a bit complex because the Product/Library templates have a large number of both Roles and Policy Admin statements (ACL's) covering many object types - and for the "BASIC" Lifecycle template for all Doc's (CAD and non-CAD) and WTParts). There are other product templates based on other lifecycle templates.
In general, it's a five-dimensional puzzle:
- Where applied (what domain).
- To What (obeject type)
- When (at what state(s))
- Who (user, group, context Role or potentially the whole organization)
- What can they do: Read, Download, Modify, etc.
Verify what is there before / after making changes. For 10.2 and before, the tool is Manage Security; for 11.0 it's Edit Access Control. Launch from a specific object; the results are only for the current state of that object.
In general for the case you describe, it allows for:
- Users in Manufacturing have access to for example Rev A Released (the last iteration, say A.3) but are not aware that Rev B is being worked on since it's at In Work state.
- Users involved in development / change have Rev B at In Work available.
Highly recommended:
- Possibly on a test Windchill system or ok in production: create a test Product or Library and remove all ACL's, and all Roles except Manager.
- Create a few test CAD Docs / WTDocs in that context. Set each to a different state in the lifecycle.
- Add back one Role (e.g. Engineer) and add a user to the Role.
- Use Edit Access Control from each object and see what the Engineer can do.
- Gradually get comfortable and confident with applying ACL's this way.
PDMLink 11.0
I have created a user requirement lifecycle template in the organization context and have created custom roles at organization level (assuming it would be applicable to every context below it). Now I create a cad part in a folder inside my product. Here initially part will be in inwork. As mentioned earlier at this state I want only userA and userC who is assigned to approver role should be should be able to view it. userB who is in a viewer role should not be able to view it. But even if I have restricted userB for only viewing and downloading documents(cad/non-cad) in approved state, he/she is able to view it in other states also.
Instead of creating custom roles at organization context should I go with product level and assign each user to a pre-defined role or my approach of going with organization context should be fine?
OTB, there are many ACLs for the "TeamMembers" Role - and these can play havoc with an otherwise well-designed approach. TeamMembers (distinct from but including "Members") includes all Roles except Manager and Guest. OTB, the TeamMembes Role can pretty much do everything. This may be why the user b below can read when not desired. Drill down to the specific statement.