Saturday, May 11, 2024
5 changes · saas-17.2
Miscellaneous changes
Updating the code field of accounts can trigger a lot of recomputes. Especially during upgrades, this can lead to MemoryError. For this reason, in https://github.com/odoo/odoo/pull/125320, it was decided that only tags should be updated on `account.account` when updating a CoA. But, it can happen that a superfluous code update sneeks in through `ResCompany.reflect_code_prefix_change()`, even though the old code and the new one are the same. Avoid this unnecessary update by returning early from
Original PR description
Updating the code field of accounts can trigger a lot of recomputes. Especially during upgrades, this can lead to MemoryError. For this reason, in https://github.com/odoo/odoo/pull/125320, it was decided that only tags should be updated on `account.account` when updating a CoA. But, it can happen that a superfluous code update sneeks in through `ResCompany.reflect_code_prefix_change()`, even though the old code and the new one are the same. Avoid this unnecessary update by returning early from the function when old and new codes are the same. Forward-Port-Of: odoo/odoo#165070
Before this commit: Any IoT-box syncing to a version 16 (and >) database would not be able to start odoo service due to the `num2words` missing library. This is in practice the fault of the IoT as this library is part of odoo requirement. But to solve it it would need to recreate an IoT box OS image and asking customers to re-flash their SD card which is not convenient and time consumming. After this commit: Import conditionally num2words opw-3902183 Forward-Port-Of: odoo/odoo#165067
Original PR description
Before this commit: Any IoT-box syncing to a version 16 (and >) database would not be able to start odoo service due to the `num2words` missing library. This is in practice the fault of the IoT as this library is part of odoo requirement. But to solve it it would need to recreate an IoT box OS image and asking customers to re-flash their SD card which is not convenient and time consumming. After this commit: Import conditionally num2words opw-3902183 Forward-Port-Of: odoo/odoo#165067
This traceback occurs when the user makes the `end date` as empty while creating a new planning slot with template. To reproduce this issue: 1) Install planning 2) Create a new `planning slot` 3) click on any `template id` 4) Now remove the `end date` 5) A traceback occurs Error:- ``` TypeError: unsupported operand type(s) for -: 'bool' and 'datetime.datetime' ``` When the user removes the `end datetime` its value is `False` which leads to the above traceback when `-` is u
Original PR description
This traceback occurs when the user makes the `end date` as empty while creating a new planning slot with template. To reproduce this issue: 1) Install planning 2) Create a new `planning slot` 3)…
This traceback occurs when the user makes the `end date` as empty while creating a new planning slot with template. To reproduce this issue: 1) Install planning 2) Create a new `planning slot` 3) click on any `template id` 4) Now remove the `end date` 5) A traceback occurs Error:- ``` TypeError: unsupported operand type(s) for -: 'bool' and 'datetime.datetime' ``` When the user removes the `end datetime` its value is `False` which leads to the above traceback when `-` is used between `start` and `end` datetime. https://github.com/odoo/enterprise/blob/5600b5b754f79e5d7a253fe9db45ac8a9273d3de/planning/models/planning.py#L406-L408 Additionally, a `value error` is also occurring when the `start` date-time is empty, while calculating start-end-dates with `template` . As it returns both `datetime` and timezone. From the below lines `tzinfo` only removes when the start date time and template is present. https://github.com/odoo/enterprise/blob/5600b5b754f79e5d7a253fe9db45ac8a9273d3de/planning/models/planning.py#L621-L627 After applying this commit will resolve both issues and make the code more robust sentry-5005245970 Forward-Port-Of: odoo/enterprise#61024
Before this commit, it was impossible to force the use of 'vanilla' ISO 20022 over SEPA in every case. The 'Generic' selection value existed in the PAIN version field, but its actual meaning was to use the regular SEPA, not what the inner code of the module calls "generic SEPA", which actually corresponds to ISO 20022 without the SEPA-specific restrictions. ISO 20022 is currently automatically used a a fallback by our SEPA implementation when trying to generate a file which values would viola
Original PR description
Before this commit, it was impossible to force the use of 'vanilla' ISO 20022 over SEPA in every case. The 'Generic' selection value existed in the PAIN version field, but its actual meaning was to…
Before this commit, it was impossible to force the use of 'vanilla' ISO 20022 over SEPA in every case. The 'Generic' selection value existed in the PAIN version field, but its actual meaning was to use the regular SEPA, not what the inner code of the module calls "generic SEPA", which actually corresponds to ISO 20022 without the SEPA-specific restrictions. ISO 20022 is currently automatically used a a fallback by our SEPA implementation when trying to generate a file which values would violate the SEPA restrictions (such as a non-IBAN account or non-EUR amount). This works fine when your wish is to do SEPA and you need something more generic "by accident", and maybe your bank accepts it. In that context, we got a report from a customer with his journal configured to "Generic", who actually wished to use ISO 20022 instead of SEPA: - When making a batch payment containing a non-EUR amount or non-IBAN account, this worked fine - When making a batch payment violating none of the SEPA restrictions, SEPA was used instead of ISO 20022 When SEPA was chosen, SvcLvl node was set to "SEPA" in the file, as it is the only accepted value. This got rejected by the customer's bank, which expected only ISO 20022, in which "SEPA" is not a legit SvcLvl value. With our commit, this node will now receive "NURG" as its value. This commit is intended as a small patch to unlock customers facing this exact issue. More proper and sandboxed support for ISO 20022 will follow in master. opw-3848174 Forward-Port-Of: odoo/enterprise#62240 Forward-Port-Of: odoo/enterprise#62054
- Amounts should be matched to 99999, not 99.999. This was badly converted from previous versions when integrating these checks in the new report framework in 16.0 - The check made for grid 44 mentioned the wrong grid in its label. This had already be fixed in 15.0, but apparently crossed with the 16.0 refactoring, which undid it by mistake (probably because it moved the file) See documentation: https://eservices.minfin.fgov.be/intervat/static/help/FR/regles_de_validation_d_une_declaration.h
Original PR description
- Amounts should be matched to 99999, not 99.999. This was badly converted from previous versions when integrating these checks in the new report framework in 16.0 - The check made for grid 44 mentioned the wrong grid in its label. This had already be fixed in 15.0, but apparently crossed with the 16.0 refactoring, which undid it by mistake (probably because it moved the file) See documentation: https://eservices.minfin.fgov.be/intervat/static/help/FR/regles_de_validation_d_une_declaration.htm Forward-Port-Of: odoo/enterprise#62229 Forward-Port-Of: odoo/enterprise#61376