Community Tip - You can subscribe to a forum, label or individual post and receive email notifications when someone posts a new topic or reply. Learn more! X
Version: Windchill 12.1
Use Case: Phase Access Control
Description:
Remind me please. Is the Phase Access Control on the Lifecycle for a Role the Role in the Context Team or is it applied to the member on the role in the process?
What I am wondering is if a named role has edit at a lifecycle phase, do all members of the context team also have edit at that phase or is it just the members of the process itself that are in that Role.
I think it's just the process members, just want to check.
PTC is not clear on this.
Thanks.
Hi @LG_10096154
Thank you for your question.
Your post appears well documented but has not yet received any response. I am replying to raise awareness. Hopefully, another community member will be able to help.
Also, feel free to add any additional information you think might be relevant. It sometimes helps to have screenshots to better understand what you are trying to do.
Best regards,
Thanks @Catalina
From what I know at this point (unless someone chimes in) is that the Phase control only applies to the members of the process at that phase (state) and not the context team role of the same name.
It is a more focused why of applying access when needed to just that process object and not applying it to all process objects of the same type at the same state for all users in that Role.
Hi @LG_10096154
The ACL defined on the lifecycle is depended on the process role, not the context role.
So you can manage an access individually for an each workflow process.
PetrH
Yes, that does seem to be the case. It's also rather odd how PTC uses team templates and context roles. If there are used in a role "approver" in the team template it will pick those people for the "instance" (workflow) but it will also add anyone else it finds in that same named Role in the context team.
So, if we have phase access in the lifecycle for a Role, we would need to use a different named Role in the context to give blanket access to the workflow object at that state.