-
-
Notifications
You must be signed in to change notification settings - Fork 174
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
[16.0][FIX] base_bank_from_iban: Handle correctly non IBAN accounts #206
[16.0][FIX] base_bank_from_iban: Handle correctly non IBAN accounts #206
Conversation
If any non IBAN account is provided, there's an ugly log with traceback each time, polluting tests and system logs: ``` INFO prod odoo.addons.base_bank_from_iban.models.res_partner_bank: Could not find bank from IBAN Traceback (most recent call last): File ".../addons/base_bank_from_iban/models/res_partner_bank.py", line 34, in _add_bank_vals bank = self._get_bank_from_iban(vals["acc_number"]) File ".../addons/base_bank_from_iban/models/res_partner_bank.py", line 42, in _get_bank_from_iban iban = schwifty.IBAN(acc_number) File ".../python/site-packages/schwifty/iban.py", line 77, in __init__ self.validate(validate_bban) File ".../python/site-packages/schwifty/iban.py", line 175, in validate self._validate_characters() File ".../python/site-packages/schwifty/iban.py", line 185, in _validate_characters raise exceptions.InvalidStructure(f"Invalid characters in IBAN {self!s}") schwifty.exceptions.InvalidStructure: Invalid characters in IBAN XXXXXX ``` This commit removes that traceback catching the proper exception, and handling it accordingly, and also removing an extra INFO log that was not adding value.
b64d4eb
to
1da90fe
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
T
@@ -1,5 +1,5 @@ | |||
# Copyright 2017 Tecnativa - Carlos Dauden | |||
# Copyright 2022 Tecnativa - Pedro M. Baeza | |||
# Copyright 2022,2024 Tecnativa - Pedro M. Baeza |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well, I have adapted the format to not put as ending date, but "continuing" date. I want to highlight that it has been touched in these 2 years.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So what should I put in a module that for example has been modified in the years: 2016, 2017, 2020 and 2023?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would put 2016,2023
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
And when would the usual 2016-2023 be used?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well, @sbidoul put that note because he says that putting that notation means that the copyright ends on that date, which is right, so I have somehow invented this variant to highlight some work between several years, only putting the first and the last you have touched it.
/ocabot merge patch |
On my way to merge this fine PR! |
Congratulations, your PR was merged at 5164a97. Thanks a lot for contributing to OCA. ❤️ |
If any non IBAN account is provided, there's an ugly log with traceback each time, polluting tests and system logs:
This commit removes that traceback catching the proper exception, and handling it accordingly, and also removing an extra INFO log that was not adding value.