cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Showing results for 
Search instead for 
Did you mean: 

We are happy to announce the new Windchill Customization board! Learn more.

Disallow Revise without an ECR

dwilliams
6-Contributor

Disallow Revise without an ECR

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

1 ACCEPTED SOLUTION

Accepted Solutions
dwilliams
6-Contributor
(To:dwilliams)

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.

  1. Remove the revise permission for the current user roles.
  2. Add a new revise permission for a new role not on the context team.
  3. With the change process workflow, use an expression robot to assign the new role to the objects version team and assign the group or users to that role.

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.

View solution in original post

6 REPLIES 6

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

dwilliams
6-Contributor
(To:dwilliams)

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.

  1. Remove the revise permission for the current user roles.
  2. Add a new revise permission for a new role not on the context team.
  3. With the change process workflow, use an expression robot to assign the new role to the objects version team and assign the group or users to that role.

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.

Hi Dax

I know that you have answered your question. Please also vote for the existing idea!

Top Tags