Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[14.0][MIG] l10n_eu_product_adr #109

Merged
merged 16 commits into from
Aug 29, 2022

Conversation

StefanRijnhart
Copy link
Member

@StefanRijnhart StefanRijnhart commented Apr 27, 2021

14.0.1.0.0 (2021-05-04)
~~~~~~~~~~~~~~~~~~~~~~~
* [BREAKING] Gather dangerous goods attributes on a new model adr.goods,
  and replace all product attributes with a Many2one on this model.
  Remove all other unused or unclear attributes.
* [ADD] XML data for the dangerous goods table from the 2019 edition,
  including translations in 3 languages.

@StefanRijnhart
Copy link
Member Author

@i-vyshnevska I have observed some points to improve this module; https://github.com/OCA/community-data-files/pull/109/files#diff-d967fda5116ea9b63e06dd49e2557fbfc802b8b6476598adcc50acd9d8b890b5R49-R73. Do you agree, or are there good reasons for some of the current design choices? What part of the specifications does great.class refer to?

@i-vyshnevska
Copy link
Member

@StefanRijnhart your comments looks reasonable, what I can say would be good to have one more POV as work was based on just one customer requirements, also related report appeared to be more specific for the country

@simahawk
Copy link

@StefanRijnhart is this ready now?

@StefanRijnhart
Copy link
Member Author

@simahawk thank you for your interest. I've now pushed the latest version as accepted by our customer. I believe it is more correct as it allows for multiple entries in the dangerous goods table with the same UN number, distinguished by different packing instructions or limited quantities. It does mean however that the already very bare migration from the previous version was invalidated entirely so I removed it.

@StefanRijnhart StefanRijnhart marked this pull request as ready for review September 14, 2021 09:48
Copy link
Member

@i-vyshnevska i-vyshnevska left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

in new version we not distinguish good and waste

l10n_eu_product_adr/models/adr_label.py Outdated Show resolved Hide resolved
@StefanRijnhart
Copy link
Member Author

in new version we not distinguish good and waste

@i-vyshnevska sorry, I don't know what you mean by this comment. Can you clarify?

from collections import defaultdict

from lxml import etree
from openpyxl import load_workbook # pylint: disable=W7936
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, but this is not necessary in recent versions of Odoo. The linked page (now) mentions this as well:

This rule doesn't apply neither to Odoo >= v12, as an unmet dependency in an uninstalled module doesn't block the service thanks to this commit:

Comment on lines +70 to +78
if len(goods.un_number) != 4:
raise ValidationError(
_(
"UN Number %s is invalid because it does not have "
"a length of 4."
)
% goods.un_number
)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We had to implement that as well. I don't recall why, but the our customer has some cases where the unnumber isn't a 4 digits long string. Here's where I implemented the solution we agreed on https://github.com/OCA/delivery-carrier/compare/0278821af40dc8fef2fc2518f53038a37bb07deb..0758137ff35a9a0e3170b641d566749de802df00

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It would be interesting to hear when such a number can appear, because no such number appears in any of the specs I've seen!

Comment on lines 10 to 13
is_dangerous = fields.Boolean(help="This product belongs to a dangerous class")
adr_goods_id = fields.Many2one("adr.goods", "Dangerous Goods")
adr_class_id = fields.Many2one(
"adr.class", related="adr_goods_id.class_id", readonly=True
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since the dangerous attributes can vary from a variant to another, we moved those fields from product.template to product.variant.
see this PR #112

Could you please do the same?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Alright, I will take care of that.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See new commit [RFR] l10n_eu_product_adr: allow different adr goods per variant

Copy link
Member

@mmequignon mmequignon left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

functional tests ok, even if it'll break a lot of module which depends on this one ^^'
However, @i-vyshnevska knows better about this.

@i-vyshnevska
Copy link
Member

in new version we not distinguish good and waste

@i-vyshnevska sorry, I don't know what you mean by this comment. Can you clarify?

previously we had two classes to distinct dangerous "good" and "waste" (products which producing dangerous staff after they used) they treated differently in reports etc

@Highcooley
Copy link

in new version we not distinguish good and waste

@i-vyshnevska sorry, I don't know what you mean by this comment. Can you clarify?

previously we had two classes to distinct dangerous "good" and "waste" (products which producing dangerous staff after they used) they treated differently in reports etc

since our customer does not work with dangerous waste at the moment, I think we can ignore this.

Copy link
Member

@mmequignon mmequignon left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@StefanRijnhart
We discussed internally about this, and it does not provide a way to tell that a product is valid or not, regarding the limited_qty.
I provided you a possible solution in the comments.
Thanks!

"vehicles.)"
),
)
limited_quantity = fields.Char()
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This one should be different

Suggested change
limited_quantity = fields.Char()
limited_quantity = fields.Float()
limited_quantity_uom = fields.Many2one("uom.uom")

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK. I will not commit your suggestion directly because of the implications, but I will have a look at this.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See new commit "[IMP] l10n_eu_product_adr: distinct uom for limited quantity" in this PR for this.

)
adr_label_ids = fields.Many2many(
"adr.label", related="adr_goods_id.label_ids", readonly=True
)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
)
)
limited_quantity = fields.Boolean("Limited Qty", compute="_compute_limited_quantity", store=True)

With the compute method like so

@api.onchange("adr_goods_id", "adr_goods_id.limited_quantity_uom", "adr_goods_id.limited_quantity", "uom_id", )
def _compute_limited_quantity(self):
    for record in self:
        compare product's uom_qty with adr.goods uom_qty:
        product.limited_qty = adr.good uom_qty < product uom_qty

We should also ensure than the adr.label uom has the same uom family as the product one.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm sorry, but my customer is a bulk trader. They trade in pallets, or gallons, and the individual subpackaging is encoded in the product name rather than the UoM of the product. So what suits your requirements is not generally valid.

@mmequignon
Copy link
Member

@StefanRijnhart
Hello Stefan, I see that you put this PR back in progress.
Could you please list what you will do, and give us a raw estimate of how many time it will take?
Thank you!

@StefanRijnhart
Copy link
Member Author

@mmequignon I tried to indicate in my comments what I was going to refactor:

I hope to finish it this week on Monday or Tuesday.

@StefanRijnhart StefanRijnhart force-pushed the 14.0-mig-l10n_eu_product_adr branch 4 times, most recently from ee881f5 to 88ba907 Compare November 16, 2021 16:23
@StefanRijnhart
Copy link
Member Author

I've rebased. As for the status, I'm considering to let this one slip because as expected this does not align well with the team that provided the previous implementation, and I think the communication has not been easy for either side. Also, I'm not working for the project that required this anymore and I'm a bit of a hippie so I prefer to work with bicycles rather than with dangerous goods anyway 😁

@marylla
Copy link
Contributor

marylla commented Jun 16, 2022

@bosd The runboat is now working, so you can test it. :) I would too but I don't know enough about this topic to test it properly.

@bosd bosd mentioned this pull request Jun 22, 2022
8 tasks
Copy link
Contributor

@bosd bosd left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM!

@OCA-git-bot
Copy link
Contributor

This PR has the approved label and has been created more than 5 days ago. It should therefore be ready to merge by a maintainer (or a PSC member if the concerned addon has no declared maintainer). 🤖

@marylla
Copy link
Contributor

marylla commented Jul 26, 2022

@jgrandguillaume Can we please merge this one?

@bosd
Copy link
Contributor

bosd commented Jul 27, 2022

Maybe @OCA/community-data-files-maintainers can help

@simahawk simahawk requested a review from mmequignon July 28, 2022 06:02
@simahawk
Copy link

simahawk commented Jul 28, 2022

FYI On our side we are waiting for @mmequignon to get back to this for a final review.
We have many other modules depending (and blocked) on this and we need to check how they are impacted after the last changes.
To name some:

@simahawk
Copy link

/ocabot merge nobump

@OCA-git-bot
Copy link
Contributor

This PR looks fantastic, let's merge it!
Prepared branch 14.0-ocabot-merge-pr-109-by-simahawk-bump-nobump, awaiting test results.

@OCA-git-bot
Copy link
Contributor

Congratulations, your PR was merged at 0a70233. Thanks a lot for contributing to OCA. ❤️

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.