Skip to main content
P
ptc-14350001-Visitor
1-Visitor
December 2, 2010
Question

Locking Change Activity Tasks

  • December 2, 2010
  • 9 replies
  • 2166 views

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.

9 replies

avillanueva
avillanueva23-Emerald I
23-Emerald I
December 2, 2010
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.


    P
    ptc-14350001-VisitorAuthor
    1-Visitor
    December 2, 2010

    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
    avillanueva23-Emerald I
    23-Emerald I
    December 2, 2010
    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.


    E
    ericstarkman10-Marble
    10-Marble
    December 2, 2010
    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
    avillanueva23-Emerald I
    23-Emerald I
    December 2, 2010
    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.


    P
    ptc-14350001-VisitorAuthor
    1-Visitor
    December 2, 2010

    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

    M
    MikeLockwood22-Sapphire I
    22-Sapphire I
    December 2, 2010
    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.
    R
    rdrennen1-Visitor
    1-Visitor
    December 2, 2010
    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
    avillanueva23-Emerald I
    23-Emerald I
    December 2, 2010
    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.


    Terms & ConditionsAccessibility statement