Ready for reviews.

👍

I would like to discuss about what we should do about these Binary(attachment=True) fields. There is several solutions.

The pros of the implementation proposed in this PR:

• allow to select the same image (attachment) several times for different galleries without any additional space
• small PostgreSQL dumps as the images are stored in the filestore
• no data loss on migrated fields when uninstalling the module

Cons:

• the UX with this attachment_id field isn't very convenient

Another method is to add a new binary field file_db_store_attachment with attachment=True, linked to a new backend db_attachment. This way we can manage these two kind of storage: binary in database (db) and binary as attachment (db_attachment). Then the pre_init_hook function could migrate Binary(attachment=True) fields (e.g. in product.template https://github.com/odoo/odoo/blob/9.0/addons/product/product.py#L538) by updating the relevant data in the ir_attachment table (res_model, res_id and res_field).

Pros:

• small PostgreSQL dumps as the images are stored in the filestore
• good UX, a normal binary field on the form as it is now

Cons:

• bad UX, choose between Database and Database/Attachment is unclear (maybe add the possibility to enable/disable the different storage backends for integrators, another problem for another PR)
• unable to select the same image several times, each use needs to be stored
• uninstalling the module will not recover the migrated ir.attachment records

IMO the implementation in this PR is great. (code review 👍 btw)

I would also say that the migration of image records into an unrecoverable table could be a big red flag in terms of using this module. As a sys admin, I naturally shy away from something that migrates my data without a way to walk it back.

code review 👍