Community Tip - Learn all about PTC Community Badges. Engage with PTC and see how many you can earn! X
We have a requirement to prevent users from revising objects without first creating an ECR against those objects. I have searched for and found a few discussions on this topic but I wasn't able to find an actual solution.
Does anyone have a solution they would like to share?
I have thought through a few options but they all seem to require a change to the object lifecycle. Hoping to find a solution that doesn't require us update the lifecycle on all of our objects.
Thanks in advance for your expertise,
Dax
Solved! Go to Solution.
Thanks for the replies. I appreciate your expertise.
I've discovered that the requirement is they do not want to allow the user to revise after they have published the objects to a secondary system. So updating the lifecycle will and ACL's is probably the route we will take.
I did however think of a method that may work for those of you that cannot update the lifecycle.
As long as the object has an advanced lifecycle, it will have a version specific team associated to it. I haven't tested this but I believe it should work.
Well, you kind of partially have it on some things depending on how you've trained your users to use your files. If you don't have a Workflow linked to the Lifecycle Template of the objects in question (which is the OOTB default for Parts and CAD documents) they can't get to a Released state without either a Set State function (which you can configure so that only Administrators have access to it) or through the part release trigger signals that exist in Change Tasks. If you've trained your users to never physically use any part data that isn't fully released and have people enforcing that, and also have it that a CN can't be created without a CR, there's your control. They could create new revisions of stuff until the cows come home, but no one will actually use them until they go through a complete CR and CN. My company directly uses this method and it is quite effective.
Hope that helps,
Daryl
We set access permissions to the principal with code like this,you can try it.
adhoccontrolled = AccessControlHelper.manager | |
.addPermissions(adhoccontrolled, | |
wtPrincipalReference, | |
accessPermissions, AdHocAccessKey.WNC_ACCESS_CONTROL); | |
PersistenceServerHelper.manager.update(adhoccontrolled, false); | |
The last time I checked with PTC, AccessControlHelper API's were marked as unsupported. Since we cannot modify LC, adhoc role is not an option. Another option which I could think of is to create a UI validator to validate the presence of an ECR before the revise action is displayed or after revise is performed. This is detailed in Customization guide / help center
Thank you
Binesh Kumar
Thanks for the replies. I appreciate your expertise.
I've discovered that the requirement is they do not want to allow the user to revise after they have published the objects to a secondary system. So updating the lifecycle will and ACL's is probably the route we will take.
I did however think of a method that may work for those of you that cannot update the lifecycle.
As long as the object has an advanced lifecycle, it will have a version specific team associated to it. I haven't tested this but I believe it should work.
You approach should work. In a couple of workflows, we have roles defined in lifecycle states and we assign members to role through wf expression. It is relatively easy to give adhoc permissions when you have advanced life cycle template.