Skip to main content
V
Vinay_S1-Visitor
1-Visitor
October 2, 2017
Solved

is it possible to restrict users from accessing files in different life cycle states in pdmlink?

  • October 2, 2017
  • 1 reply
  • 3435 views

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.

Best answer by MikeLockwood

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.

1 reply

M
22-Sapphire I
MikeLockwood22-Sapphire I
22-Sapphire I
October 2, 2017

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.

 

    V
    Vinay_S1-VisitorAuthor
    1-Visitor
    October 3, 2017

    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? 

    M
    22-Sapphire I
    MikeLockwood22-Sapphire IAnswer
    22-Sapphire I
    October 3, 2017

    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.

      Terms & ConditionsCookie settingsAccessibility statement