Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[18.0][MIG] fs_image #446

Open
wants to merge 32 commits into
base: 18.0
Choose a base branch
from
Open

Conversation

rousseldenis
Copy link
Contributor

@rousseldenis rousseldenis commented Feb 19, 2025

lmignon and others added 30 commits February 19, 2025 16:49
Store your image into an external filesystem
Currently translated at 100.0% (14 of 14 strings)

Translation: storage-16.0/storage-16.0-fs_image
Translate-URL: https://translation.odoo-community.org/projects/storage-16-0/storage-16-0-fs_image/es/
Currently translated at 92.8% (13 of 14 strings)

Translation: storage-16.0/storage-16.0-fs_image
Translate-URL: https://translation.odoo-community.org/projects/storage-16-0/storage-16-0-fs_image/it/
Currently translated at 100.0% (14 of 14 strings)

Translation: storage-16.0/storage-16.0-fs_image
Translate-URL: https://translation.odoo-community.org/projects/storage-16-0/storage-16-0-fs_image/it/
Fix a bug in the initialization of the image field value object when the field
is read. Before this fix, every time the value object was initialized with
an attachment, an assignment of the alt text was done into the constructor.
This assignment triggered the mark of the field as modified and an SQL update
query was generated at the end of the request. The alt text in the constructor
of the FSImageValue class must only be used when the class is initialized without
an attachment. We now check if an attachment and an alt text are provided at
the same time and throw an exception if this is the case.
rawCacheKey is properly managed by STD
Currently translated at 78.5% (11 of 14 strings)

Translation: storage-16.0/storage-16.0-fs_image
Translate-URL: https://translation.odoo-community.org/projects/storage-16-0/storage-16-0-fs_image/fr/
Before this change the creation of empty file was not supported. The issue was mainly due to the fact that at create of a FSFileValue instance with a name but without content, the name was no preserved. As result, the insert of the attachement into the DB failed since the name is a required field. If a FSFileValue instance is now created without content but with a name, the name is now preserved on an empty buffer.
Updated by "Update PO files to match POT (msgmerge)" hook in Weblate.

Translation: storage-17.0/storage-17.0-fs_image
Translate-URL: https://translation.odoo-community.org/projects/storage-17-0/storage-17-0-fs_image/
On image hover, a download button is now available to easily download the image
Updated by "Update PO files to match POT (msgmerge)" hook in Weblate.

Translation: storage-17.0/storage-17.0-fs_image
Translate-URL: https://translation.odoo-community.org/projects/storage-17-0/storage-17-0-fs_image/
Currently translated at 100.0% (15 of 15 strings)

Translation: storage-17.0/storage-17.0-fs_image
Translate-URL: https://translation.odoo-community.org/projects/storage-17-0/storage-17-0-fs_image/it/
@lmignon
Copy link
Contributor

lmignon commented Feb 24, 2025

/ocabot migration fs_image

@OCA-git-bot OCA-git-bot added this to the 18.0 milestone Feb 24, 2025
@OCA-git-bot OCA-git-bot mentioned this pull request Feb 24, 2025
21 tasks
Copy link
Contributor

@lmignon lmignon left a comment

Choose a reason for hiding this comment

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

LGTM (Code review + diff with 16.0 and functional via #449)

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.

9 participants