[18.0][MIG] uom_category_active: Migration to version 18.0#2221
[18.0][MIG] uom_category_active: Migration to version 18.0#2221
Conversation
|
@takahii03 Thanks for the migration! Commit history must be preserved. Can you please follow the steps described in https://github.com/OCA/maintainer-tools/wiki/Migration-to-version-18.0#technical-method-to-migrate-a-module-from-170-to-180-branch? |
Currently translated at 100.0% (3 of 3 strings) Translation: product-attribute-16.0/product-attribute-16.0-uom_category_active Translate-URL: https://translation.odoo-community.org/projects/product-attribute-16-0/product-attribute-16-0-uom_category_active/it/
…se an error. Swith from an onchange logic to an create / write logic to be sure to handle all the cases
4e2c612 to
023b9db
Compare
|
@yostashiro |
yostashiro
left a comment
There was a problem hiding this comment.
LGTM as far as the migration is concerned. Just a couple points...
| /> | ||
| </xpath> | ||
| <xpath expr="//field[@name='name']" position="after"> | ||
| <field name="active" options='{"always_reload": True}' /> |
There was a problem hiding this comment.
I think this option is of no use.
| <field name="active" options='{"always_reload": True}' /> | |
| <field name="active" /> |
In fact, I think this field presentation is redundant with the ribbon implementation, although it's not a migration issue.
There was a problem hiding this comment.
Would you consider adding another commit to extend the search view?
<record id="uom_categ_view_search" model="ir.ui.view">
<field name="name">uom.category.view.search</field>
<field name="model">uom.category</field>
<field name="inherit_id" ref="uom.uom_categ_view_search"/>
<field name="arch" type="xml">
<xpath expr="//field[@name='uom_ids']" position="after">
<filter name="inactive" string="Archived" domain="[('active', '=', False)]"/>
</xpath>
</field>
</record>
Hi, all.
The changes are mostly standard migration steps, with the exception of renaming a test class name to better align with current naming conventions.
Everything else followed the usual migration process.
Could you could take a look @angelmoya ?