Promotion Request - Process & Team Selection Loophole

[TomU]

Promotion requests are normally controlled by specific workflow process and roles available in each context.  Creating a new promotion request for objects in one context will automatically use the roles and processes from that same context.

This all falls apart though when objects from multiple contexts are added to the same promotion request, especially when the promotion request is created from a search result.  *ANY* context can be selected, even contexts that have nothing to do with the objects on the promotion request.

In my opinion, this is a serious loophole with significant security implications.  This allows the wrong workflow processes to be used, and the wrong people to grant approval, either intentionally or unintentionally.

Is anyone aware of a preference or other method to prevent this behavior?  I imagine something could probably be done with customization, but this really seems like it shouldn't be necessary for such a core capability of the system.  What's the point of defining rules of behavior for a product or library if the users can easily skirt around them with no warning or limitation?  How is this considered acceptable PLM behavior?

• https://www.ptc.com/en/support/article/CS374467
• https://www.ptc.com/en/support/article/CS332418
• https://www.ptc.com/en/support/article/CS223801

[Marco_Tosin]

Tom,
I fully agree with your point of view, in fact we too had to find a way to handle codes that are created or changed as a result of a change (ECN).

We no longer use promotions with the exception of a few rare cases.

So we solved it this way, obviously with heavy customization of the system.

Each code that is created or revised is associated with a WTPart of type project or modification (this is our way of handling codes that arise as a result of new projects and modifications to codes already in production).

Each project/modification WTPart has roles defined in the Team tab.

When a code is created or revised the user performing the action is required to link the code to a project or modification.

In this way each code is automatically populated in the team with the users in the roles defined in the project/modification.

Obviously, the codes can be found in different contexts, either product type or in libraries.

The project or modification manager is responsible for populating the Team roles, which are then used by the ECN workflow to allocate tasks to the various users to be performed to complete the modification.

Some examples of these roles are:

Lab Technician
Design contact person
Industrializer
Sample manager
Quality contact person
Master data manager
Project manager
Tooling manager
Product certification manager

[Tyler.E]

@TomU, 

Were you able to find a solution to this problem?

I cannot understand how PTC considers this to be working to specification. It doesn't make sense to me that it is so easy to bypass the rules and Approvers that should be associated with an object.

In our implementation, we have contexts assigned to each type of product we manufacture as well as a context for each manufacturing plant.

Because of this "loophole", I could have Manufacturing Engineers that end up assigned to review CAD changes on products that they'll never produce!

I'm still new to workflows and don't know what the code needs to look like yet, but below is my pseudocode for a possible work-around.

After Promotion Request has been created:

• Get PR context
• Get a list of all objects on PR
• Get list of object contexts
  • Check if object contexts match 
    • No - terminate workflow and notify Owner That all objects on PR must exist in the same context
    • Yes - Continue
• Check if PR context == Object context
• No - terminate workflow and notify Owner That the context for the PR must match the objects on the PR
• Yes - Continue

It's not ideal, I'd prefer for users to be able to make these changes in the Wizard, but it's the best idea I've had so far.

I'm curious to hear how you've moved forward.

Tyler

[avillanueva]

Agreed that the OOTB has holes you can drive a truck through but @Marco_Tosin suggest customization is needed. Any time your need to have the system follow a business rule, its needs to be coded in or via administrator checks. Assume that users can and will not follow expected behavior. 

• Add a step in the PR workflow for an admin to validate everything looks good, if not correct or reject.
• Code in rules via expression robots that enforce business rules as @Tyler.E suggested.

Every site is different so who approves and how things work are going to vary from site to site. 

[d_graham]

@Tyler.E 

Tyler, you have describe the scenarios to very well defined. These scenarios can be stopped in their tracks during both the Promotion Request creation and editing rather than in a workflow after creation. If done in a workflow others need to get involved and things come to a halt until someone does something.

All of this can be prevented/caught during Promotion Request creation and editing using your own validator and data utility.

A listen can also be used to prevent this during creation and editing.

Either way the user would be notified with a pop up window telling them EXACTLY which objects on their Promotion Request do not comply with the standards and what to do to fix it.

This is my preferred l way to go because it stops the user in their tracks and at the same time it teaches them which allows them to fix the problem on their own without the need to get anyone else involved and the Promotion Request created/edited without delay.

David

[HelesicPetr]

Hi @Tyler.E 

I would say the fastest way how to achieve it is customization and listener during PR creation as @d_graham has mentioned.

I also advice to create an idea to add a preference that can allow or disallow the PR creation with objects from just one context because I agree that this option should be OOTB available.

PetrH

[TomU]

Hi @Tyler.E,

We ended up paying @d_graham to build a listener to check for this during promotion request creation and then stop the user in their tracks if the objects don't all match the context selected for the PR.  This completely stopped the problem.  The only disadvantage is that if objects from different contexts need to be approved, they must each be on their own separate promotion requests.  This can be a little tricky sometimes depending on the dependencies between the objects since we have other rules in place that also prevent objects from being released unless all of their dependent objects are also released.