Change Notices Can Promote Read Only Objects???

[lhoogeveen]

Changes Notices (CN) do not respect a user's access defined in the Access Control Lists (ACL's). Read only objects can be added to the CN Resulting Objects with a Target State. Then the CN workflow runs as wcadmin so it has no problem promoting everything (including read only objects). Promotion Requests give desired error of 'Insufficient Permission for promoting an object in this context' to users on read only objects when they try to submit but Change Notices do not.

I created a ticket with PTC, but R&D said that CN's should not respect user access because the people reviewing/approving the CN should be doing it. R&D also said CN workflow can be customized using expression robots if we wish to check permissions. My thoughts: having approvers check is easier said than done when there are hundreds or thousands of Resulting Objects in a CN, and I'm not super excited about customizing/maintaining a custom CN workflow.

The net result is we keep having users accidentally change the state of read only Library objects from Released to Obsolete once or twice a month. Also, our Creo drawing formats (.frm) get set to Obsolete from users forgetting to remove them from the CN Resulting Objects list since there is no way to auto exclude drawing formats from common actions/collectors.

How have others dealt with this? Seems like a major gap in permissions for CNs.

[MikeLockwood]

Agree that this is a fundamental need, not currently addressed within Windchill.

About the only thing that I can suggest is a validation check in the workflow template, right after submission:

- identify the Product/Library in which the CN exists

- if the CN is not in the Library that holds formats (the normal case), route back to Creator if any CAD Docs on the CN are in the library that holds the formats

All can be done with fairly straight forward code.

[avillanueva]

I would not expect this to get addressed by PTC since I think the issue lie in your business process. CN OOTB workflows should never be taken as it but tailored to your organization. This means along with proper user training, sufficient checks in the workflow to present what it seems it bad behavior.  But there are a couple of things I would suggest.

• Adjust the collectors at site level for adding items to affected and resulting items to turn off cad dependencies.  That should take care of including formats along with library components as you indicated people are doing. 
• We never see more than 20-30, mostly less than 10 items on any change notice. This would be only uniquely numbered parts of our design along with their drawings and cad models. We are reviewing and releasing our designs, not all the library components that are used. Library components are handled in a different manner and administratively. 
• If our product has 1000 components and assemblies, we would release up the structure as each level matures so each CN is relatively small for folks to review. I cannot see how you get hundreds of items on the CN unless the users are default grabbing all items or are creating too many CAD models (STEP imports?).

Remember, the CNs is not allowing a user with read access to circumvent ACLs. It had to be approved by those in the workflow. CNs are more formal than promotion notices so there is the option to capture from/to changes, discussions, signoffs and rework. It would not be possible to review hundreds of objects effectively. Strong suggestion is to train users to only put on CNs your companies designs to release and train approvers to reject or edit if "junk" is added.

[TomU]

I believe the volume of data being generated at @lhoogeveen's company is significant.  Maybe he'd be willing to share what their daily / weekly object volume is and what the review/release process currently looks like...

[lhoogeveen]

We design large custom automation cells for large companies and part count can easily climb into the 1000's or higher. Each mechanical engineer probably designs 10-20 parts per day.

We have two main use cases for using CN's:

• At certain project milestones, all objects get promoted (ex: PRODUCTION (Release to machine shop to build) to FINAL (What was shipped to the customer)).
  • This is typically where the 100s or 1000's of CN Resulting Objects come from.
    • We have the default collectors setup collect all CAD and WTParts since it's easier to remove than add.
    • Importing customer data STEP files to reference in our designs can easily generate 100's of CAD objects as well. We're currently in Creo 7 and looking forward to Creo 8+ inseparable assemblies.
  • Currently using CN's, but we will probably be switching to Promotion Requests for this. PR's respect ACL's and are easier to use.
• True Change on Released CAD or WTParts (much lower quantity of parts)
  • Design change on a released (PRODUCTION or FINAL) object. One thing we like is that manufacturing can do a Change Request which feeds into a CN.

It's definitely a permissions gap. It might be a little complicated to implement a full solution considering how complicated a CN can be (multiple Change Tasks, groups of users, reassigning tasks, etc.). The 80/20 rule is probably focus on the Resulting Object permissions of person submitting the CN or the person completing the Change Task. Here's a product idea: Change Notices Should Respect User Access of Resulting Objects