Skip to main content
T
23-Emerald IV
TomU23-Emerald IV
23-Emerald IV
February 21, 2023
Question

Promotion Request - Process & Team Selection Loophole

  • February 21, 2023
  • 2 replies
  • 3499 views

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?

 

    2 replies

    MarcoTosin
    21-Topaz I
    MarcoTosin21-Topaz I
    21-Topaz I
    February 22, 2023

    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

     

     

    Marco
    T
    Tyler.E5-Regular Member
    5-Regular Member
    July 7, 2023

    @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
      23-Emerald I
      avillanueva23-Emerald I
      23-Emerald I
      July 7, 2023

      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. 

       

      avillanueva_2-1688743207242.png

       

      Terms & ConditionsAccessibility statement