Check changes attributes in TriggerOnPortalUpdate
This PR adds a feature in TriggerOnPortalUpdate to check for changes attributes (similar to TriggerOnObjectUpdate) using the new method ListPreviousValuesForUpdatedAttributes
Previously I implemented my own Trigger with this feature via an extension, but I though it might be interesting to integrate this in the core and make it available to all iTop users.
Best Lars
Hi Lars, If you want to have TriggerOnObjectUpdate working only in the context of the portal you can use a new attribute named... context to filter in which context you want your trigger to work. If this answer if ok for you, just close the PR.
Hi @eespie , I already mentioned the context attributes, but in fact it is sligthly different to this one. Using TriggerOnObjectUpdate I am not able to check the attributes after the object modification. TriggerOnObjectUpdate is the only trigger checking the OQL filter before the object modification, which makes the handling a little bit different. I.e. if some one is adding a contact to the contacts_list via portal and then writes a public log entry. I am not able to send this log entry to the newly added contact using TriggerOnObjectUpdate Using the implementation in this PR I am able to do so.
Best Lars
Hi Lars, we won't be able to work on your PR for some months.
It's not that it's good (or bad), it's just that we have some hard deadlines to meet.
We are really sorry for the delay, 💔
Discussed during technical review today: We don't feel comfortable with relying on the assumption that the TriggerOnPortalUpdate is later in the processing and therefore gives you access to changed attributes. This positioning in the CRUD could be moved.
On the other hand, in the portal you can specify which triggers you want to be activated, maybe this could save you as you could do an OQL like "SELECT TriggerOnPortalUpdate UNION SELECT TriggerOnObjectUpdate WHERE context MATCHES portal" (it's pseudo OQL). Can you check if that would do the job for you?
Check this page for more info.

Hey @Molkobain
This PR is pretty old (about 3 years). As far as I am able to remember, that time the motivation for this PR was, that
- There was no Context-Filter for TriggerOnUpdate, and
- TriggerOnUpdate was activated before object was written
Both issues are not valid anymore., which means the need for this PR might be obsolete. I forgot to update this PR / close this PR.
Cheers Lars
Thanks for the feedback!