When an object changes through a form, its modification date changes. But the same doesn't happen when the article transitions between workflow states.
I wonder if this is the desired behavior.
We have a specific case in our website, in which we would like that the modification date was also updated after a workflow state change.
We need to sync some data between two systems, and we are using the modification date as an indicator of potential changes. If the modification date is different between the objects in the two systems, we resync its data.
The workflow state is also part of the data that the systems share. The problem is though, when only the state changes, the modification date doesn't change, so the object won't be synced.
I guess we can create our own handler to update the modification date when the workflow state changes...
But I was also interested to know if somebody else has the same issue; or what is the thought behind not changing the modification data of objects upon workflow state changes?
I guess in our case, the state is used almost as if it was an attribute of the object itself, maybe it isn't like this for all cases?
Margarida via Plone Community wrote at 2024-2-5 12:37 +0000:
...
When an object changes through a form, its modification date changes. But the same doesn't happen when the article transitions between workflow states.
I wonder if this is the desired behavior.
I think this is the case:
Think of a publication workflow.
There an author creates/modifies content
and an editor publishes it.
The modification date most naturally specifies the date of the last
content modification;
the editor action may determine the publication date.
We have a specific case in our website, in which we would like that the modification date was also updated after a workflow state change.
You can associate scripts with workflow actions.
Such a script could update an objects modification date.
We need to sync some data between two systems, and we are using the modification date as an indicator of potential changes. If the modification date is different between the objects in the two systems, we resync its data.
The workflow state is also part of the data that the systems share. The problem is though, when only the state changes, the modification date doesn't change, so the object won't be synced.
An object's state for all workflows is typically maintained in the
attribute workflow_history, usually a PersistentMapping.
You could base your synchronization decision on both the
modification date and the _p_serial (it documents the time of the
last modification or a persistent object (not regarding modifications
of persistent subobjects) of workflow_history.
But I was also interested to know if somebody else has the same issue; or what is the thought behind not changing the modification data of objects upon workflow state changes?
"modification date" refers to content modifications;
a workflow can define its own date variable if it thinks this
interesting, e.g. a "publication date" in a "publish" transition.
the workflow changes have a date, you can use it directly to build a new date method that checks the recent date one between the modification date and the latest transition workflow one. You can apply this method to every dexterity object using zcml. You can follow this discussion:
I did something similar but with an index. The index calculate the most recently updated one between the object modification date and the portlet modification date (because portlets assigned directly to the object are part of the content).