I am using iTop version 2.7.12 and I have a trigger on the Incident class for the gdpr attribute (values: yes, no, not_evaluated).
The problem is:
In 2.7.12, triggers only evaluate objects based on the current state after save, not on the attribute change itself.
This means I cannot reliably send an email only when gdpr changes to yes.
I would like to know:
Does iTop version 3.0+ allow triggers to detect changes in attribute values directly, so that the trigger can fire only when gdpr changes to yes without using a helper flag?
Or does exists some solution for version 2.7.12?
Thank you for your clarification.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It would either way not be a bad idea to upgrade to iTop 3.2; as 2.7 is not officially supported anymore and 3.2 is a long-term supported release.
Not sure when the OQL query is evaluated. But, you could perhaps ensure there is always a value set. And if necessary, as a workaround; just ensure the trigger only runs if the GDPR changes. Again, only if needed to work around it; you could then just select the opposite: "select all objects where GDPR is set to no" before the change. If a change of the GDPR attribute happens, it would mean it gets enabled.
Hello,
I am using iTop version 2.7.12 and I have a trigger on the Incident class for the gdpr attribute (values: yes, no, not_evaluated).
The problem is:
In 2.7.12, triggers only evaluate objects based on the current state after save, not on the attribute change itself.
This means I cannot reliably send an email only when gdpr changes to yes.
I would like to know:
Does iTop version 3.0+ allow triggers to detect changes in attribute values directly, so that the trigger can fire only when gdpr changes to yes without using a helper flag?
Or does exists some solution for version 2.7.12?
Thank you for your clarification.
It would either way not be a bad idea to upgrade to iTop 3.2; as 2.7 is not officially supported anymore and 3.2 is a long-term supported release.
Not sure when the OQL query is evaluated. But, you could perhaps ensure there is always a value set. And if necessary, as a workaround; just ensure the trigger only runs if the GDPR changes. Again, only if needed to work around it; you could then just select the opposite: "select all objects where GDPR is set to no" before the change. If a change of the GDPR attribute happens, it would mean it gets enabled.
iTop 3.0 change log seems to mention a change:
N°3245: Trigger OnObjectUpdate filters objects after their update
https://www.itophub.io/wiki/page?id=latest:release:change_log