Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Fix/file version event dispatch#12896

Open
m-kreis wants to merge 3 commits into
concretecms:9.5.xfrom
m-kreis:fix/file-version-event-dispatch
Open

Fix/file version event dispatch#12896
m-kreis wants to merge 3 commits into
concretecms:9.5.xfrom
m-kreis:fix/file-version-event-dispatch

Conversation

@m-kreis
Copy link
Copy Markdown

@m-kreis m-kreis commented May 6, 2026

  • add new event for file version deletion: on_file_version_delete
  • update file name and prefix before dispatching on_file_version_approve

If I swap a file in the file manager, a new version is created in the save() method of concrete/src/File/Import/FileImporter.php. In there the getVersionToModify() executes duplicate() on the existing file version and then approve() on the duplicated file version (concrete/src/Entity/File/Version.php). In approve() the event on_file_version_approve is fired. But unless updateFile() is called, the duplicated file has the old name and prefix but already the new file version id. This leads to a file version passed to the event with inconsistent data. So I moved updateFile() to getVersionToModify() between duplicate() and approve(). For updateFile() I need the new file name and the prefix. As the only call to getVersionToModify() which requests a forceCreateNew is from the file importer the impact of the change seemed reasonably small.

Copy link
Copy Markdown
Member

@aembler aembler left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

getVersionToModify is not the appropriate place for this. The method's purpose is to get a new file version, but only if conditions allow it (e.g. the person working on the file is different that then previous version, or if the file version is older than a particular timestamp threshold.) The prefix and new file name do not belong here, and swapping method arguments isn't something we should do.

This should be done in a different way, without modifying this file and changing its arguments.

@m-kreis m-kreis force-pushed the fix/file-version-event-dispatch branch from d0ff6c7 to 11f34af Compare May 7, 2026 14:19
@m-kreis
Copy link
Copy Markdown
Author

m-kreis commented May 7, 2026

I don't think it can be done without modifying getVersionToModify(), as duplicate() followed by approve() will always trigger on_file_version_approve with inconsistent data.

Proposing this:

  • Approving should not be the responsibility of getVersionToModify() (inconsistent data in on_file_version_approve, unexpected side effect)
  • Denying should not be the responsibility of duplicate() (leaves the file with no approved version, unexpected side effect)
  • Instead, leave it to the caller of getVersionToModify() to approve the version if a new version was created and the approved version was the most recent one.

@aembler
Copy link
Copy Markdown
Member

aembler commented May 14, 2026

  1. I disagree, I think we need to keep this behavior the same. It is this way for a reason.
  2. I do agree about this. I think if we don't auto approve the new version, we should leave the old version approved.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants