Could be caused by #26295 ? If so: I will make a PR anyway for making com_contenthistory compatible with real null dates, but this can’t be merged before PR’s for nulldates for all other components relevant for content history have been merged.

I’ll check this tonight German time and make PR if it is the nulldate thing causing this.

Completely unrelated - this is nothing to do with dates

I see ... well, if you discover for com_contenthistory or somewhere else some issues which are or might be related to dates, let me know.

is this still an issue with the workflow v3?

Yes it is still a problem.

it looks like the change is not being written to the db until you close the article?

The problem is how the workflow is implemented. The flow is the following:

1. article gets saved
2. workflow adjust the article based on the given plugins (transition)

Now the history is written in step 1, so it does not get the updated values.

The solution would be either to write the history after execution of the workflow or to update the history entry when transition is through.

@bembelimen the reason isnt that important. What matters is that without the content history the workflow loses a major bit of functionality. Arguably its more importnat with workflows than before

OK I looked at it, 2 problems one solution.

As benjamin already said the history is saved before the workflow triggers.
Solution for this, we trigger the history save a secondtime after the workflow finished adding a "version note" -> "Workflow"

Second problem, we can't revert a version and shouldn't if the workflow is active, so solution for this.
Deactivate the revert button (functionality) in the version history if workflow is active.
It's not possible to revert all workflow plugin actions even if we can revert the stage doesn't mean that the article is in the right state. Like reverting to an stage after a plugin triggered an unrepeatable action.

Second problem, we can't revert a version and shouldn't if the workflow is active, so solution for this.

why?

Editor submits a new version. Admin check it and says no so they need to revert to the previous version

Editor submits a new version. Admin check it and says no so they need to revert to the previous version

In this case if the article is already published the editor version is also live before admin review. If the article isn't live then state won't have changed. If the state has changed between the new version and the admin publishing then you're reverting multiple versions and potentially yes you wouldn't see a rollback. Potentially I guess if there is a path in workflow to revert the workflow state maybe we should execute it (or else not allow the rollback??) But kinda unsure on that

Hello

Do we have any plan with this Release Blocker issue? Do we still want to store Status and Featured of article into version history when workflow is enabled? I just look at it and think that the following might be solution:

• Revert PR #31518 so that Status and Featured still be stored into version history.
• Add method onWorkflowAfterTransition into Behaviour - Versionable plugin (same with other workflow plugins). The purpose of that method is that it can get Status and Featured from the workflow and update these values to latest version history of the item being saved

Could that be solution for this issue? I don't have experience with Workflow and it's code, so I could be wrong. Just trying to move forward with the remaining Release Blocker issues.

@bembelimen can you look at this and share your thoughts please.

My opinion is still the same: Values managed by the workflow should not be changeable by the versioning. Otherwise you can publish items without having the permission (as transitions).
The correct solution would be to implement a workflow rollback (if needed at all) and not a pseudo solution which works against the whole workflow concept.
This are two worlds: workflow disabled and workflow enabled.
So my opinion is: #31518 is the proper fix and in the future we can enhance it. But again: enabling the workflow is now a decision which is made by the admin and therefore he is changing the world and have new behaviours.

If so, can we remove Release Blocker label for this issue and move forward?

Might as well remove versions if workflow is enabled then as by design you are saying they are not compatible with each other

or document it as a known limitation when working with versions and workkflow

or document it as a known limitation when working with versions and workkflow

That could work, I think. We can live with this limitation for now and wait for real life usages feedback. If users ask for a fix , we can re-visit this later.

or document it as a known limitation when working with versions and workkflow

@bembelimen Do you think you can find the time to write such documentation? ?

https://docs.joomla.org/J4.x:Workflow#Versioning

Thanks @bembelimen .

@brianteeman Is that sufficient to close the issue, or if not, can we at least remove the "Release Blocker" label?

Thanks @bembelimen

@richard67 definitely enough for removing release blocker. Would like to see it recorded as a "known issue" somehow if possible

@brianteeman Would this be the right place? https://docs.joomla.org/Potential_backward_compatibility_issues_in_Joomla_4

Not really for me to say but if I was a new joomla user with no experience of ever using anything other than j4 but just switched on workflow and saw this problem then that would not be the place i would go. But I guess I would see it where @bembelimen wrote it. So maybe just leave it as it is.