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