[16.0][OU-ADD] sale_purchase #4061
Conversation
|
/ocabot migration sale_purchase Depends on : |
| ---Models in module 'sale_purchase'--- | ||
| ---Fields in module 'sale_purchase'--- | ||
| sale_purchase / product.template / service_to_purchase (boolean) : not stored anymore | ||
| # DONE: post-migration, convert to company-dependent field |
There was a problem hiding this comment.
For better reading (as this file doesn't have syntax highlighting, on contrary than on Python, where I recommend to not put empty lines inside methods due to this), please put an empty line in between each block:
| # DONE: post-migration, convert to company-dependent field | |
| # DONE: post-migration, convert to company-dependent field | |
| # DONE: post-migration, convert to company-dependent field | ||
| ---XML records in module 'sale_purchase'--- | ||
| DEL ir.model.constraint: sale_purchase.constraint_product_template_service_to_purchase | ||
| # DONE: post-migration, delete XML-ID |
There was a problem hiding this comment.
What this actually means is that the DB constraint has been removed.
v15: https://github.com/odoo/odoo/blob/06919a232251cbd68a28500757aef5cd2e3363a0/addons/sale_purchase/models/product_template.py#L13
v16: https://github.com/odoo/odoo/blob/17151f5c369dce7ca5d38c5fd0db8dceab5cfab7/addons/sale_purchase/models/product_template.py#L14
so you need to remove the constraint as well in the DB.
| # the product.template.service_to_purchase field became company-dependent. | ||
| # this means that it is no longer stored in the product_template table, | ||
| # but in the ir_property table. | ||
| # | ||
| # for such cases, openupgrade.convert_to_company_dependent() should | ||
| # normally be used, but that function does not seem to support converting | ||
| # a field to company-dependent without changing its name at the same time. | ||
| # moreover, it stores boolean values even when they are false (what odoo | ||
| # does not), and it creates values for all companies, which does not make | ||
| # sense when a record is linked to a particular company only. |
There was a problem hiding this comment.
This is something to be put as docstring of the method IMO, as it describes what the method is going to do.
| # the product.template.service_to_purchase field became company-dependent. | |
| # this means that it is no longer stored in the product_template table, | |
| # but in the ir_property table. | |
| # | |
| # for such cases, openupgrade.convert_to_company_dependent() should | |
| # normally be used, but that function does not seem to support converting | |
| # a field to company-dependent without changing its name at the same time. | |
| # moreover, it stores boolean values even when they are false (what odoo | |
| # does not), and it creates values for all companies, which does not make | |
| # sense when a record is linked to a particular company only. | |
| """The product.template.service_to_purchase field became company-dependent. | |
| this means that it is no longer stored in the product_template table, | |
| but in the ir_property table. | |
| For such cases, openupgrade.convert_to_company_dependent() should | |
| normally be used, but that function does not seem to support converting | |
| a field to company-dependent without changing its name at the same time. | |
| moreover, it stores boolean values even when they are false (what odoo | |
| does not), and it creates values for all companies, which does not make | |
| sense when a record is linked to a particular company only. | |
| """ |
There was a problem hiding this comment.
Anyway, your considerations are not totally correct:
but that function does not seem to support converting a field to company-dependent without changing its name at the same time
I don't fully understand what you mean, but the usual method is to rename the origin column in pre-migration (for preservation purposes, but also for not confusing people browsing DB schema thinking that the applied value is the one in the column), and then call this other method in post.
it stores boolean values even when they are false
This can be considered a bug of the method (or something that has changed across versions, and should be split the behavior inside the method), but it should be fixed there in openupgradelib.
It creates values for all companies, which does not make sense when a record is linked to a particular company only.
This is a temporary condition. If you empty the company field after migration, you expect to have the same value for the rest of the companies as it was previous the migration, so we can't limit it.
Maybe for not over-heading the table, a ir.property without company_id can be created for this, but we should not how Odoo acts when you change the value in one company in this case. Is it modified for all the companies as the existing ir.property has no company?
So in summary, we shouldn't add so many code for something that is a recurrent problem and should be handled in the library.
|
Superseded by #4366 |
No description provided.