[18.0][MIG] fs_attachment: Migration to 18.0 #403

Also fix typo into summary

Avoid recompute of new columns when installed on an existing database

Allows to provide configuration parameters through server environement files.

Remove code used to try to read file from the root filesystem and write into the specialized filesystem. This code was used to try to provide a way to manage staging environments by reusing the same filesystem storage but with a different directory_path depending of the environement. A simpler method is to configure use a different filesystem storage by environement. If a production database is restored in pre production env, you can declare a new filesystem storage with a different code to store the attachements by default and configure the filesystem storage from the production with information allowing to read documents stored in it but not to modify or delete existing documents. This make the implementation far more simple.

To create a new cursor, just ask to the current registry.... Loading a registry is very time consuming and could lead to deadlocks...

…ds to different FS storages

Fix image streaming Fix image streaming with resize Fix content size whithout x-send-file

This code was initially used to magically know if we need to obfusc or not the filename into the database. Since this option is now explicit, we can safely remove-it. Moreover, without this code it's now possible to migrate old storage_file contents to the new fs_* addons

… attachement

Add history for commit included from OCA#285 and the author to the contributors list

Before this change, users with basic access rights was no more able to create an attachment. The problem was caused by the need to access system information to determine in which file system the attachment should be created, when this sensitive information is not accessible to everyone. The change consists of reading this information in sudo to bypass this security restriction in this specific context.

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

Avoid error when the directory_path is not set on the storage when computing the attachement

When manipulating the file system api through a local variable named *fs*, we observed some strange behavior when it was wrongly redefined in an enclosing scope as in the following example: *with fs.open(...) as fs*. This commit fixes this issue by renaming the local variable and therefore avoiding the name clash.

Currently translated at 36.9% (24 of 65 strings) Translation: storage-16.0/storage-16.0-fs_attachment Translate-URL: https://translation.odoo-community.org/projects/storage-16-0/storage-16-0-fs_attachment/it/

Before this change, when the fs_url was computed the computed value was always reassigned to the fs_url attribute even if the value was the same. In a lot of cases the value was the same and the reassignment was not necessary. Unfortunately this reassignment has as side effect to mark the record as dirty and generate a SQL update statement at the end of the transaction.

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

fs.storage is protected as it contains credentials. It must be accessed sudo when needed for regular users manipulating ir.attachments.

Let "image.png" be an image. Thumbnails might be created with a path such as "38/5b/image-128.png". Before, the path was forgotten when updating the attachment, so accessing the file would crash, making the record inaccessible.

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

If say click-odoo-update fails partway, the columns are already created and the following tentative update fails because the columns exist.

…en the new mimetype doesn't match the old one

Updated by "Update PO files to match POT (msgmerge)" hook in Weblate. Translation: storage-17.0/storage-17.0-fs_attachment Translate-URL: https://translation.odoo-community.org/projects/storage-17-0/storage-17-0-fs_attachment/

The method _check_force_db_for_default_attachment_rules() encountered issues when used with a constraints() decorator due to the computed field use_as_default_for_attachments, which is not stored in the database. This fix consists in replacing the constraints() decorator with a directly invoked method.

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

When trying to get access to files stored into an external filesystem, don't crash if the files cannot be accessed. This is necessary to avoid blocking Odoo's operation if an external system is not accessible.

…h res_field != False

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[18.0][MIG] fs_attachment: Migration to 18.0 #403

[18.0][MIG] fs_attachment: Migration to 18.0 #403

Commits on Oct 15, 2024

[18.0][MIG] fs_attachment: Migration to 18.0 #403

Are you sure you want to change the base?

[18.0][MIG] fs_attachment: Migration to 18.0 #403

Commits on Oct 15, 2024