Workflow allows items that should not be allowed - New objects

[STEVEG]

I have found a severe issue.  Or what I consider is a severe issue in workflows.

I had a user that created a change notice and attached a model and its drawing to it in the Resulting objects table.

They submitted the CN for approval but the reviewer noticed there were no files in the table.  The assignee asked to have it sent back but they said the files ARE there.

They asked me as the org admin to look at it.  When I reviewed it even I couldn’t see the files on the Resulting Objects table.  I logged in as that user and was able to see them.

It turns out the Resultant Objects table had NEW objects in it.  The user never checked them in but the workflow allowed them to add the files to the table.  We have code in our workflow that won't allow the assignee to complete the task of the CN with checked out objects. The objects are new so technically they are not checked out.

We contacted PTC about this and technical support said it is not possible to restrict Users from associating New objects created in Workspace with Change Objects like Change Request even if the Objects are not Checked in in Windchill and that this is a current product limitation.  <MIND BLOWN!!!>

They suggest a product enhancement or customization.  Customization?  This should be standard functionality.  Something that should have been thought of to restrict.  How could they allow new items to be attached to a workflow?

Does anyone have any thoughts on this?  I can’t believe that tech support would suggest this should be an enhancement or customization.

[BenLoosli]

Objects not checked in should not be allowed to be added to any workflow, change notice, change request or promotion. This should be the system default across the board and PTC should upgrade the code to do this. It should not be a customer customization.

[TomU]

If the behavior you want (or don't want) wasn't explicitly spelled out during development, then by definition the software is 'working to spec', regardless of how illogical the behavior may be.  The only supported solution is to create a product idea and then try to convince product management it needs to change.  Hopefully the product manager will agree and fight for development hours to get it changed at some point in the future.

[STEVEG]

I get it @TomU 

It's just disappointing in this case this is what we have to resort to.

Would any ptc product manager like to jump in on this?

[RandyJones]

I agree that this should be the default OOTB however since you already have in place code to check for Checked Out objects you can probably add checking for new objects in that same code. One can use the following to check for new objects:

EPMWorkspaceHelper.manager.getNewObjects(WTCollection objects)

[RandyJones]

We also have "error/ignorant/What were they thinking/etc" checking in our Change Notice process that prevents the user from selecting Complete. And thanks to you Steve I have just added this check to the long list of items that get checked. User now gets "flagged" with this:

New item: needs checked in.

[TomU]

The core issue here is most likely how brand new objects are treated in the database. As soon as a new object is uploaded to the database, the 'statecheckoutinfo' column shows the status of the object as 'c/i', meaning 'checked in', even though the object has never actually been checked in. Once the object has been checked in, future working copies will show 'wrk' (for working), which makes sense. It's only the first version, when something is brand new, that behaves oddly.  It really should be 'new' or 'wrk', not 'c/i'.

New Object - Uploaded but never checked in

Object after being checked in:

Object checked out (and working copy automatically created behind the scenes):

[JeffZemsky]

@STEVEG please send me the Case Number

[STEVEG]

@JeffZemsky I sent you a message with the case number.

[lhoogeveen]

We recently had a user add library objects (to which they only have read access) to a Change Notice Resulting Objects. Since WCADMIN has the ability to modify all files, the Change Notice workflow had no problem changing the state from Released to Service Only. ☹️ Not sure how to protect against this and have the CN respect the user access. Ideas?

[BjoernRueegg]

I have also had discussions about this problem. At the moment I have two suggestions:

1. Prohibit adding "standard" parts to a change task. This is only possible if the parts have their own type
2. Creating a business rule to check if the object is in a prohibited context.

[STEVEG]

Something else the tech support person said was that they reviewed some older cases and found that the functionality is working in this way since earlier Windchill Releases like Windchill 9.0.

So we don't know if this was introduced at 9.0 or has always been like that.

[d_graham]

@STEVEG 

It’s doable to prevent users from adding objects in WS that are not checked in as Resulting or Affected to a Change Activity.

The same problem was posed to me a while back by a company I help out.

The code works for new (never been checked in) and old.

We know that the dB checkout info for this scenario will be c/i (see Tom’s post), but there are other attributes to check that can be used to determine if the object is new and not yet actually checked in by the user.

The code can both stop the user in their tracks when they attempt to add the object to Resulting or Affected or do some check later on in workflow.

I prefer the stop in tracks option.

A listener detects when an object is added as Resulting or Affected. Listener runs code and throws exception if the object is deemed not checked in.

Problem solved!

My guess is when TS said “it is not possible to restrict users …” they meant it’s not OOTB.

It’s not OOTB usually translate to means fun problem to solve. 😁

David