Modify Identity for Reassign View on wtPart

[LG_10096154]

Greetings,

Little puzzled how users in a role (team members) have Reassign View on the wtPart when they don't seem to have been granted Modify Identity in ACL?

I don't see Modify Identity on the wtObject either. 

Any suggestions on how the team member could have access to that action.

I have checked ACL at context, Org and Site on wtObject and wtPart (including sub-types). I used a generic role but also check Team Members

[HelesicPetr]

Hi @LG_10096154 

Usually grant the ACL rule to the user. 

PetrH

[LG_10096154]

Interesting, I do see in Domain "User" at the site level that wtObject gets Full Control on "owner". 

I assume the "Owner" is the user who creates the wtObject.

[HelesicPetr]

Hi @LG_10096154 

If ACL is defined on the Site level or org level it can be rewrite by lower level. 

It is not so obvious but you need to check real ACL access on the object where you have a issue.

you need to go to the object and use an Edit Access Control to see what ACL are defined for the user

With a green plus add a specific user to the list and check the access for that user

And check detail by Info button

PetrH

[LG_10096154]

I followed the steps above to see the access controls on the object.

The long blue bars are Org. Short are context.

I can see that at the context they have a lot more access than I see for Team Members. The role they are in has no ACL's on it.

When I check default, I don't see those access listed?

[HelesicPetr]

Hi @LG_10096154 

What is default ? product/org or site?

You see just the defined ACL on the specific level in the policy administration 

So the result has to be always tested with user. 

Another thing is that access can be granted by lifecycle template, so if you can not see definition in the policy administration, then the access is from lifecycle. 

In other hand you need to check all domain levels where the ACL can be defined. 

PetrH

[LG_10096154]

I checked the lifecycle. it's all basic so no access controls on that.

The default is the Org level where we have most of our ACL's.

[HelesicPetr]

Hi @LG_10096154 

You need to check a context domain - product/library/org

User context is not used OOTB for general ACL definition. 

So go to the default product domain and check of the acls are defined. They have to be there shown, 

Make sure the checkbox "Include Ancestor Domains" is selected.

PetrH

[HelesicPetr]

Hi @LG_10096154 

There can be Ad-hoc ACL's on the object. Ad-hoc ACL's are not shown in the Policy Administration

You can see them in the Access Control

PetrH

[jbailey]

In the Context go to Utilities > Policy Administration

Make sure to checkmark the "Include Ancestor Domains" box and click search. This should include all policies that apply (Site, Org and Context).

If you want to filter down by object type for simplicity - that is possible as well

Something to think about is that policies can be applied based on all (applies to everyone) or to a role and "Team Members" is a role that encompasses anyone on the team that is in a defined role. Policies can also apply to the participant, or all except participant. My hunch, is there may be a policy created that prevents a normal user from changing an identity once an object has been to a specific state (like Released). That is a CM best practice that you don't reidentify objects once they are approved for use. 

[LG_10096154]

This is interesting. 

It looks like the Team Template to create a context (Project in this case) has access controls in the HTML file?

[LoriSood]

Hi @LG_10096154 

Are you trying to figure out why the Actions > Reassign View is available for the user? If you enable jcaDebug on the details page of the part, you can find out which validator is being used to enable that action. I enabled it on my system, and it's showing that the com.ptc.windchill.enterprise.part.validators.AssignViewActionValidator is used to enable the action.

I took a look at the source code for that validator class, and it looks like the action will be enabled as long as the user has Modify permission on the WTPart on the latest iteration of every revision. It doesn't check the Modify Identity permission in this case.

Regards,

Lori