[18.0][MIG] website_sale_product_attachment: Migration to 18.0

[ChristianSantamaria]

Standard migration to v18 using oca-port

[ChristianSantamaria]

@pilarvargas-tecnativa, @victoralmau Could you take a look at it?
I'm also getting an error in the tests and I can't resolve it. Do you have any ideas?

[victoralmau]

I'm not entirely sure but I think this will solve the tests.

[ChristianSantamaria]

Let's go 🎉! Thank you very much, @victoralmau .

[victoralmau]

Functional review OK

Please note that although the feature in core v17 allows you to list attachments in the product page, it only includes attachments linked to that product, which still makes this module necessary, IMO.

[pedrobaeza]

/ocabot migration website_sale_product_attachment

[pedrobaeza]

I see that the core functionality is pretty much the same as this module:

It's the same to include the document as product attachment and configure it to be published than linking it other way IMO...

[victoralmau]

I see that the core functionality is pretty much the same as this module:

It's the same to include the document as product attachment and configure it to be published than linking it other way IMO...

IMO, there's a big difference. In core, if there are some common files for, say, 20 products, you'll have to upload the file (and create 20) for each product. With this module, you can use the same file and link it across all 20 products. It's true that the behavior could be "unified," but it might be more confusing to unify it than to keep it separate as it is now.

[pedrobaeza]

At low level, it's the same, as upload the file 20 times only means one time to take the space, as having the same hash, it doesn't require more space, and for the user it's the same to upload the file 20 times than to link it. They have to do 20 operations the same.

[victoralmau]

I seem to remember there's an option (in the form view of an attachment) that allows you to link the products to which it applies, so you can link all 20 products in a single operation without adding the same attachment 20 times. Also, if you need to change something (instructions for "same" products), having to delete them all and upload them again isn't very intuitive, but it could be done.

This also applies to v17.

[pedrobaeza]

That's the only advantage, but what we should do is to provide that features with the core feature, not the replace it with yet another similar one. I will definitively go with not migrating this module and create extra modules to cover that feature.

[victoralmau]

Thinking about this again, even though this module isn't exactly necessary i think it's appropriate to reuse it., IMO the right thing to do would be:

• Rename the module website_sale_product_attachment_multi (or another name) + PR to Openupgrade to rename the module.
• Modify the code to add the necessary extra field (website_product_ids, for example) to ir.attachment.
• Modify the code to allow linking from the product/template form view all the attachments you want (perhaps many2many_tags).
• Modify the “Documents” smart button (or create a new one called "Website Documents", although that would be more confusing) from the product/template form view to show “all attachments” that will be displayed on the website.
• Modify whatever is necessary on the website to display all attachments on the product page of the website.

What do you think about this?

[pedrobaeza]

I still think it doesn't bring enough value to keep it, at least on our migration path, which should be: consider this module as merged in website_sale, and convert the published attachments to product.document (I think that's the model).

[victoralmau]

I still think it doesn't bring enough value to keep it, at least on our migration path, which should be: consider this module as merged in website_sale, and convert the published attachments to product.document (I think that's the model).

Sorry to bring this up again.

I'm preparing the migration script in Openupgrade to create the corresponding product.document records (https://github.com/odoo/odoo/blob/18.0/addons/product/models/product_document.py# L10) that correspond and define them with shown_on_product_page=True (https://github.com/odoo/odoo/blob/18.0/addons/website_sale/models/product_document.py) but... I still think it's not possible.

Let's imagine that someone is using this module and has, for example, 100 product.template records with website_attachment_ids defined. The linked attachments (ir.attachment) are not linked to any res_model and res_id (e.g., “common” manuals that apply to many products)..

The “Documents” smart-button for a product are those linked to that record (to that product.template): https://github.com/odoo/odoo/blob/18.0/addons/product/models/product_template.py#L632 + https://github.com/odoo/odoo/blob/18.0/addons/product/models/product_template.py#L1462 Therefore, the migration script will be useless.

I still think that the behavior of this module is not possible with core, but I don't want to insist.

[pedrobaeza]

OK, apart from the product.document records, you have to create the corresponding ir.attachment, linked to the products. Remember that the content is not duplicated, as it's a reference to the file checksum.

[victoralmau]

Okay, so if I understand correctly, if one attachment that is not linked to anything is now linked to 20 products, with this new approach I will have to create 20 attachments (each linked to one product template). Can you confirm that this is correct? (I hope no one wants to change that file later or “link” it to more products, as they will have to create new attachments).

[pedrobaeza]

Yes, that's it. I know you are seeing this as something tremendous, but the cases where the same file is shared between several products is not so frequent, and if so, then the tool to build instead of keeping this module is one that allows to do "massive replacements" over product.document model.

[github-actions]

There hasn't been any activity on this pull request in the past 4 months, so it has been marked as stale and it will be closed automatically if no further activity occurs in the next 30 days.
If you want this PR to never become stale, please ask a PSC member to apply the "no stale" label.