Community Tip - New to the community? Learn how to post a question and get help from PTC and industry experts! X
We need to perform some procesing logic when an item is moved from one document into another. We have setup a trigger rule that contrians Document ID != Document ID[New Value], but the script never fires when I cut-content and paste-content. With a little debugging, I'm finding that tne Document ID of the destination document is not available to me in scripts.
Can someone explain to me how to setup a trigger that fires when the Document ID changes for an Item?
Note: In the Trane Solution, the Document model is mostly disabled in this context. No branching, versioning, etc. The document is merely a container and there is no hierarchy to the node items.
Solved! Go to Solution.
Hi Sean,
Have you tried the following:
1. setup a trigger rule "Contains [new value]" <> "Contains"
This should fire everytime you manually edit the content of an document is moved.
2. Also check "Contains" <> undefined
That should filter the creation of new nodes
3. inside the triggerscript you can now use the ID of the new and old related Items to get their Document ID.
If they do not match, run whatever you want to do in your script.
BTW: You should keep in mind that any ruel based trigger has and effect on your systems performance. If the trigger takes a signifcant amount of time to complete, the users will notice a "slowly responding" UI.
HTH Matthias
Hi Sean,
as far as I know, the Document ID is a computed field.
I am not shure whether the trigger rule you defined really catches these type of fields.
Your rule definitely works for a "manual" edits.
But it seems that (comparable to changes in a source-link field) the rule is simply not evaluated when the result of the DocumentID computation changes.
A workaround might be a daily or hourly scheduled trigger that uses a "historical" query to identity the Itmes that have a changed Document ID.
HTH
Matthias
Hi Matthias,
Thanks for the quick response. A schedule-based trigger is not sufficient for our use-case. When a user moves a requirement from one document to another, we need to fire an event and perform some processing logic. Once the requirements are in a new document, the user will want to imediately work on them. So waiting is not an option.
Our first thought was to use the contains relationship, and that worked for a while. Unfortunately it does work when hierarchies are present. Although we currently are not using hierarchies for these types, we are building some prototypes that use parts of the hierarchical functionality of the Document Model. So the solution to this problem needs to work whether there is a hierarchy in place, or not.
We switched to a trigger based on changing the Document ID, because it seemed the most straightforward - simply fire off a script when the document changes. Unfortunately, that does not provide the needed functionality. If there are other ways to accomplish the functionality that we need, we are open to them. Please make suggestions, our knowledge of the Integrity engine and the "Document Model" is limited.
Regards,
-Sean
Hi Sean,
Have you tried the following:
1. setup a trigger rule "Contains [new value]" <> "Contains"
This should fire everytime you manually edit the content of an document is moved.
2. Also check "Contains" <> undefined
That should filter the creation of new nodes
3. inside the triggerscript you can now use the ID of the new and old related Items to get their Document ID.
If they do not match, run whatever you want to do in your script.
BTW: You should keep in mind that any ruel based trigger has and effect on your systems performance. If the trigger takes a signifcant amount of time to complete, the users will notice a "slowly responding" UI.
HTH Matthias
Hi Matthias,
1) Yes.. This is where we started and ran into issues when there is a hierarchy in place.
2) Yes... We had that at one point, and had mixed results.
3) We were trying to avoid all the complex code associated with this approach.
- If the "Contains/Contained by has changed", fire the script.
- In the script, find the old "Root Node" and the new "Root Node", the Document ID doesn't seem viable as the new and old value don't seem to be both available in a script.
- If if the "Root Node" is the same, do nothing. If the "Root Node" is different, then iterate over the delta issues and all of its childrent (children's children (.... for all levels)) and perform the logic we need performed.
All we need to do is to perform some reset logic when a requirement moves from one document to another. If we have to build #3, we can. A simpler, and less fragile approach is much more desirable.
-Sean