Repository navigation
[19.0][FIX] fs_attachment: don't upload files forced to DB - #674
Closed
HviorForgeFlow wants to merge 1 commit into
Closed
HviorForgeFlow wants to merge 1 commit into
HviorForgeFlow wants to merge 1 commit into
Conversation
Since Odoo 19, ir.attachment create() and _set_attachment_data() write the file after _get_datas_related_values() for every attachment when the storage is not 'db', including the ones fs_attachment forces to the database through force_db_for_default_attachment_rules. The file is then uploaded to the storage for nothing: it is referenced by no attachment and only removed later by the fs.file.gc, and the write fails when the storage is unreachable, so an attachment meant to be kept in the database cannot be written while the storage is down. Skip the write in _file_write when the content was forced to the database in the current transaction and no attachment references the file. Contents shared with an attachment kept in the storage, and the files written by AttachmentFileLikeAdapter, are still written. Assisted-by: Claude Opus 5.5
Contributor
|
Hi @lmignon, |
lmignon
reviewed
Sep 28, 2026
Comment on lines
+387
to
+397
| if checksum not in self.env.cr.cache.get( | ||
| "fs_attachment_forced_to_db_checksums", () | ||
| ): | ||
| return False | ||
| store_fname = f"{location}://{self._get_fs_path(location, bin_data)}" | ||
| self.flush_model(["store_fname"]) | ||
| self.env.cr.execute( | ||
| "SELECT 1 FROM ir_attachment WHERE store_fname = %s LIMIT 1", | ||
| (store_fname,), | ||
| ) | ||
| return not self.env.cr.fetchone() |
Contributor
There was a problem hiding this comment.
For sure this code is written by Claude and is a 🤮 hack...
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Since Odoo 19,
ir.attachmentcreate()and_set_attachment_data()write the file after_get_datas_related_values()for every attachment when the storage is not 'db', including the ones fs_attachment forces to the database throughforce_db_for_default_attachment_rules. The file is then uploaded to the storage for nothing: it is referenced by no attachment and only removed later by thefs.file.gc, and the write fails when the storage is unreachable, so an attachment meant to be kept in the database cannot be written while the storage is down (e.g. menu icons during a module update).Skip the write in
_file_writewhen the content was forced to the database in the current transaction and no attachment references the file. Contents shared with an attachment kept in the storage, and the files written byAttachmentFileLikeAdapter, are still written.Regression tests included: no file written on create/write, create succeeds with the storage unreachable, and shared contents are still written in both orders.
Assisted-by: Claude Opus 5.5