Locking Change Activity Tasks

[ptc-1435000]

Let me first explain the problem.

We currently use an ECN for the release of items (parts, documents and CAD drawings/models)in PDMLink v9 M040. The items being released are added to the Resulting Objects of the Change Task associated to the ECN. A fairly complex workflow is initiated which includes peer review, approval, and authorisation steps in the Release Process.

The lifecycle that the items pass throughduring this workflow are IN-WORK, UNDER REVIEW, PRE-RELEASED and RELEASED

Once the release process completes and the items are setto RELEASED,the user can look at the changes related to the item to look at the release history.

We have a local requirement to allow selected users to perform very simple "typo" corrections (e.g. spelling mistakes)to RELEASED information. The process here relies on raising a Problem Report and Problem Report Action which allows the assignee of the action permission to set the item back to IN-WORK, make the amendment, and then re-release at the same REVISION. The item will iterate due to the check-out/check-in.

Now the problem: if a user looks at the Change Task associated to the initial release,the Resulting Objects on the task now show the latest iteration ... not the iteraion when the original release took place.

So my question: does anyone know of a method to"lock" a Change Task so that the iteraion showing for the Affected/Resulting Objects are fixed at the point that theChange Task is completed?

Many thanks for any help.

[avillanueva]

Well, nothing really changes with the change task. Its tied to the
version, not any specific iteration. Imagine the case if you add items
to a change task to stage an ECN, during the course of the ECN release,
it when back for rework, changes made and finally approved. If it was
tied to the iteration, each time, the user would have to delete the old
and re-add the new. Ugh!



I believe it is possible to snap a baseline against the ECN at the time
of release but changing the default display would have be a UI change
(to reference the baseline) I suspect.

[ptc-1435000]

Thanks Antonio,

I am looking to "freeze" the Change Task once it reaches the lifecycle state of Resolved (i.e. the task has been completed.) I take your point that we certainly would not want to lock the Change Task to specific iteration of the objects as the change or release was in progress. Definite 'Ugh' !

I was thinking about baseline, but was also wondering if the "Change Modification Tracking" functionality could offer anything?

[avillanueva]

But I think you will run into the probably of how the change task is
linked to the changeables. Its not by iteration but by version so there
is nothing to freeze. It will show you the latest iteration of that
version.

[ericstarkman]

Ian,



I like Antonio's suggestion (previous email). The connection between the
Change Task and resulting items, at the database level, is to a version, not
an iteration. I believe changing that would be a massive customization, may
not even be possible without modifying a bunch of source code. Revision
tracking on the Change Task wouldn't help, because the Change Task itself
isn't changing when you change the items.



I do think what you describe is, conceptually, a baseline. A baseline is a
"snapshot" -- it tells you exactly what iterations were in effect at a
specific moment in time.



So to me, it seems the interesting question is where to draw the line in
investing to automate this. My initial thinking is to stop at level 1, or
maybe level 2, but you could go as far as makes sense for your organization
given the cost of developing and maintaining the solution, and the value of
having the information easily accessible. Level 3 is a pretty significant
change to OOTB behavior so I would strongly discourage it.



Level 0) Have a user procedure to create a baseline at time of release, and
have a user procedure to look at the baseline to find out what iteration was
in effect at time of release.

Level 1) Have the workflow programmatically create the baseline at time of
release, and have a user procedure to look at the baseline to find out what
iteration was in effect at time of release. This wouldn't change any OOTB
code.

Level 2) Have the workflow programmatically create the baseline at time of
release, and add a feature to the Change screen to display the baseline, if
it exists. Clicking on the baseline would jump to the OOTB baseline page.
While this is a customization (you'd be modifying the OOTB Change screen),
you're only adding a small piece of code to it, which would invoke a module
you'd develop separately, so in the scheme of things it's a relatively minor
one -- it's additive.

Level 3) Have the workflow programmatically create the baseline at time of
release, and modify (customize) the OOTB screen to (behind the scenes) check
for the baseline, and if found, use that to control what iteration is
displayed. This would be a more significant customization since you're
reworking a whole section of an existing screen.



The other interesting question to me is exactly how far your users will be
tempted to stretch the definition of a "typo"! 🙂



-Eric

[avillanueva]

I am not being judgmental or anything but you also have to raise the
question if the practice of iterating released items on the Problem
Report for minor corrections is a good practice. Its seems the two
requests are conflicting.

[ptc-1435000]

Thanks Antonio. I am trying hard to persuade the company to stop the practise of allowing "small amendments" on released information. In my mind it breaks basic configuration management principles. Once it's released, it's released. Right?

Thanks also to you Eric for your suggestions and you are right. One person's typo is another's major change!

I had to pose the question to the forum though. You have confirmed both my view on the practice of amending and also that the business are asking for something in the tool that is not available simply OOTB (out of the box).

-Ian

[MikeLockwood]

Promotion includes the optional "Lock" transition, which is poorly documented but which does essentially what is described below - change the state of the objects being promoted to a safe state at which no one can Modify.

Change does not include this concept - we wondered why from the beginning and were worried about it.

We've been using change requests / notices / tasks for one year now (as of next week) and have completed ~ 5,000 of them. In fact, we find that the presence of the red triangle icon (pending change exists) has been enough to prevent the issues that we thought might occur and that a lock transition would address. In our opinion, it's best to leave this as provided.

Regarding "typos" and similar corrections, we've taken a very hard line. If those who need to approve do so without catching these things and allow the data to go to Released, then we force going thru another entire change to a new Revision. It's painful to those involved but worth it - these types of changes have slowed to a very, very small trickle. It's really not a good thing (as others have said) to have multiple Iterations at Released for a given Rev, and makes the audit trail very muddy.

[rdrennen]

I was also looking for a solution to lock resulting objects of a change
task when the task reaches a under review state. PTC Tech support said
this would require a customization.

I have entered an enhancement request for this type of functionality.

Ray

Ray Drennen
MCAD Administrator
Otis Elevator Company
5 Farm Springs Rd.
Farmington, CT 06032
860-676-5619 - voice
860-353-1356 - eFax

ray.drennen@otis.com <">mailto:ray.drennen@otis.com>

[avillanueva]

There is a method in the ECN workflow, the WorkflowProcessHelper, that
changes the state of ALL changeables on ALL tasks for the ECN. It would
be a customization to have it triggered from the Task workflow but this
is a minor alteration.