In a script, can the source object of a copy-item be determined?

[Sean-Trane]

I am in an initialization script for an item. I can tell the difference between a newly created item from a copied item. I next need to determine the item-id of the source item that was copied from. Can this be done in a script?

Kind regards,

-Sean

[awalsh]

If the item was created with a branch (e.g. copy and paste with Share or Reference modes), then there will be a parent in the item details.  The "im viewissue --showBranches [item]" command will show the parent (if there is one) and any branches:

        Branches:
        Branch 4656 based on time Tue Apr 10 14:00:44 EDT 2018
        Branch 4673 based on time Tue Apr 10 14:01:09 EDT 2018

        Parent: Issue 4585 based on time Mon Dec 12 10:56:59 EST 2016

In the event triggers, you can use the getParent() method on the IssueBean to get the parent. This method will return null if the item has no parent. 

Note that if a user does Copy then Paste Special > Copy, this is a newly created item as  no branch is created. In this case, there is no way to tell where the content was copied from.

[Sean-Trane]

We do not use the document model, so we don't have branches, shared items, or node items. In our solution everything is a simple "flat" item.

To restate my question... When a user does a 'Copy Item...' for a flat item-type, can the item-id of the source item be determined in a script after the user hits "Apply"? 

---

[awalsh]

Sorry about the confusion. There's nothing in the item creation that indicates that the item was copied. 

One option would be to have a field with the original item id that is included in the Copy Fields. But users can unselect the copy fields. Maybe if the field was hidden to users, but visible to administrators. 

I'll play around with it more tomorrow to see if I can come up with a solution.

[Sean-Trane]

Thank you for the quick replies. Since there doesn't seem to be a mechanism for this, I'll just build one of my own.

Kind regards,

-Sean

[JensN. · Accepted solution]

Hello,

we do something like that and we use two triggers for it:

Trigger A: For each item after it has been created (via "Create Item" or similar), the item ID is copied into a separate field, e.g. "ID_for_Copy", by trigger. This means that each item will have its own ID again in an extra field.

Trigger B: This trigger looks into the field "ID_for_Copy" and checks whether the content of the field matches the ID of the item. If not, the trigger will enter this value in a relationship field.

If an item is copied now, the following happens: The target item is created and the fields contained in it are filled with the contents of the source item. The field "ID_for_Copy" therefore contains the ID of the source item, because Trigger A wasn't run until now. Trigger B runs first and it links the source item into the relation field of the target item. Trigger A then runs after Trigger B and overwrites the field "ID_for_Copy" with the new item's own ID. In the end I have a new item with a relationship field to its source item. This relationship field is only filled if the new item was created by a copy, but not if it was created directly by "Create Item".

Maybe you can use something out of it...

cheers, Jens

[Sean-Trane]

Hi Jens,

Thank you... That is essentially what we need. I wanted to be sure that the Integrity engine didn't have this capability before I started building my own solution.

Kind regards,

-Sean