Thursday, October 31, 2024
14 changes · saas-17.2
Miscellaneous changes
…line Steps to reproduce: - Create two taxes T1 and T2 of 17% with two tax grids lines (+) and (-) - Configure a payment term of 2% discount - Create a payment of `-762.20` for a partner with a reference 'ref123' - Create and confirm a bill for the same partner, with a ref 'ref123', with the payment term and two lines; L1{'amount': 739.95 , 'tax': T1} L2{'amount': 37.8, 'tax':T2} - In Dashboard > Bank > select the transaction Issue: The last line tax will be 0.14 (difference of one 1
Original PR description
…line
Steps to reproduce:
- Create two taxes T1 and T2 of 17% with two tax grids lines (+) and (-)
- Configure a payment term of 2% discount
- Create a payment of `-762.20` for a partner with a reference 'ref123'
- Create and confirm a bill for the same partner, with a ref 'ref123', with the payment term and two lines; L1{'amount': 739.95 , 'tax': T1} L2{'amount': 37.8, 'tax':T2}
- In Dashboard > Bank > select the transaction
Issue:
The last line tax will be 0.14 (difference of one 1)
Cause:
The rounding issues sum up and we arbitrarily assign it to the last tax line (which can result in an unbalance).
Solution:
Instead, we assign this difference to the "biggest" base line (as the change will proportionnaly be smaller). While doing so, we keep consistencies between the tax lines.
opw-3966041
Forward-Port-Of: odoo/odoo#182386A problem was left to be fixed in the previous PR: What was to be considered the url and label was sometimes incorrectly computed with html_keep_url. As it is used in other places, we simply don't use it anymore, but extract the needed part from it: how a link is safely rendered. Task-3502174 Forward-Port-Of: odoo/odoo#184290 Forward-Port-Of: odoo/odoo#176074
Original PR description
A problem was left to be fixed in the previous PR: What was to be considered the url and label was sometimes incorrectly computed with html_keep_url. As it is used in other places, we simply don't use it anymore, but extract the needed part from it: how a link is safely rendered. Task-3502174 Forward-Port-Of: odoo/odoo#184290 Forward-Port-Of: odoo/odoo#176074
There was a typo in the test, which was breaking tests when they ran without demo data. This commit fixes it. [broken test builds](https://runbot.odoo.com/web#id=56563&menu_id=424&cids=1&action=573&model=runbot.build.error&view_type=form) Forward-Port-Of: odoo/odoo#185659
Original PR description
There was a typo in the test, which was breaking tests when they ran without demo data. This commit fixes it. [broken test builds](https://runbot.odoo.com/web#id=56563&menu_id=424&cids=1&action=573&model=runbot.build.error&view_type=form) Forward-Port-Of: odoo/odoo#185659
When guessing the language at install (or upgrade) we cannot trigger a pre-fetch of all fields of `res.company` because some of its columns may be not initialized yet. One way to trigger this behaviour is to add a stored field whose default value uses translations, while at the same time adding any other stored field. If the translation is fetched in a sudo environment we can get an error when the System partner has `NULL` language. Steps to reproduce: 1. On a cleanly initialized DB (only `b
Original PR description
When guessing the language at install (or upgrade) we cannot trigger a pre-fetch of all fields of `res.company` because some of its columns may be not initialized yet. One way to trigger this…
When guessing the language at install (or upgrade) we cannot trigger a pre-fetch of all fields of `res.company` because some of its columns may be not initialized yet. One way to trigger this behaviour is to add a stored field whose default value uses translations, while at the same time adding any other stored field. If the translation is fetched in a sudo environment we can get an error when the System partner has `NULL` language.
Steps to reproduce:
1. On a cleanly initialized DB (only `base`) add any extra language (en_GB would do).
2. Open Users & Companies (show inactive users) open System user.
3. Open Related Partner.
3. In the form view of the System partner set the language to None.
4. Try to install via the command line a module with the fields as described above (see below for a code example).
We get an error like:
```
2024-10-30 08:48:40,831 41180 INFO test_16 odoo.modules.registry: module mymodule: creating or updating database tables
2024-10-30 08:48:40,839 41180 ERROR test_16 odoo.sql_db: bad query: SELECT "res_company"."id" AS "id", "res_company"."name" AS "name"
... <many more fields, redacted> ... "res_company"."bar" AS "bar", "res_company"."foo" AS "foo" FROM "res_company" WHERE "res_company".id IN (1)
ERROR: column res_company.foo does not exist
LINE 1: ...e" AS "write_date", "res_company"."bar" AS "bar", "res_compa...
```
The solution we propose is to skip the prefetch of `res.company` fields when we are in the process of guessing the language. In this case the language is correctly picked from the System partner's company.
This issue has been observed in many upgrades to 18, but it's present in older Odoo versions as well. The language field in `res.partner` is not required, thus it is also possible to set the language to `NULL` via code.
Example data observed in upgrades:
```
> select id,name,active,lang from res_partner where lang is null
+----+-----------------------+--------+--------+
| id | name | active | lang |
|----+-----------------------+--------+--------|
| 4 | Public user | False | <null> |
| 5 | Default User Template | False | <null> |
| 6 | Portal User Template | False | <null> |
| 2 | System | False | <null> |
+----+-----------------------+--------+--------+
```
There may be other standard flows that lead to such setup where System partner has no language set.
Example inherit of `res.company` that triggers the issue:
```py
class A(models.Model):
_inherit = "res.company"
bar = fields.Many2one(
comodel_name="ir.sequence",
default=lambda self: self.env["ir.sequence"].sudo().create({"name": _("Dummy")}),
required=True,
)
foo = fields.Integer()
```
Standard example of this code pattern that triggers the issue during upgrades to 18:
https://github.com/odoo/odoo/blob/dd71d998/addons/account/models/company.py#L140-L152
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#185810*l10n_fr,l10n_fr_facturx_chorus_pro,l10n_fr_fec,l10n_fr_invoice_addr, l10n_fr_pos_cert Related to https://github.com/odoo/enterprise/pull/73048 Forward-Port-Of: odoo/odoo#185847 Forward-Port-Of: odoo/odoo#185817
Original PR description
*l10n_fr,l10n_fr_facturx_chorus_pro,l10n_fr_fec,l10n_fr_invoice_addr, l10n_fr_pos_cert Related to https://github.com/odoo/enterprise/pull/73048 Forward-Port-Of: odoo/odoo#185847 Forward-Port-Of: odoo/odoo#185817
**Steps to reproduce:** - Install l10n_cl - Switch to a Chilean company (e.g. CL Company) - Activate a foreign currency (e.g. USD) - Make sure that the rate of the foreign currency is not 1 For example: * Unit per CLP: 0.001057876419 * CLP per Unit:945.29 - Create an invoice in USD with 2 lines having different amount: * 15.80 * 15.00 - Save the invoice - Print the invoice **Issue:** On the printed invoice, a slightly different currency rate is displayed for each invoice l
Original PR description
**Steps to reproduce:** - Install l10n_cl - Switch to a Chilean company (e.g. CL Company) - Activate a foreign currency (e.g. USD) - Make sure that the rate of the foreign currency is not 1 For…
**Steps to reproduce:** - Install l10n_cl - Switch to a Chilean company (e.g. CL Company) - Activate a foreign currency (e.g. USD) - Make sure that the rate of the foreign currency is not 1 For example: * Unit per CLP: 0.001057876419 * CLP per Unit:945.29 - Create an invoice in USD with 2 lines having different amount: * 15.80 * 15.00 - Save the invoice - Print the invoice **Issue:** On the printed invoice, a slightly different currency rate is displayed for each invoice line. **Cause:** The currency rate to display is computed for each invoice line, based on the following formula: `abs(self.balance) / self.price_subtotal` However, the value of balance is rounded to the unit because of the CLP currency and therefore it generates a different rate when trying to compute it. **Solution:** Compute the rate from the total values instead of the subtotal of each line. The real rate configured on the currency cannot be used because it can be modified after the creation of the invoice. opw-4242448 Linked enterprise PR: https://github.com/odoo/enterprise/pull/73035 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#185230
**Description of the issue/feature this PR addresses:** It is needed to be able to create Factura B for a foreign customer. Legal reference: Here is some useful documentation : https://servicioscf.afip.gob.ar/publico/abc/ABCpaso2.aspx?id=8555970 https://www.afip.gob.ar/EspaciosdeDialogoInstitucional/documentos/Acta-15-Espacio-de-Dialogo-AFIP-Camaras-Empresariales-14-11.pdf **Current behavior before PR:** It is not possible to create Factura B for a foreign customer. **Desired b
Original PR description
**Description of the issue/feature this PR addresses:** It is needed to be able to create Factura B for a foreign customer. Legal reference: Here is some useful documentation : https://servicioscf.afip.gob.ar/publico/abc/ABCpaso2.aspx?id=8555970 https://www.afip.gob.ar/EspaciosdeDialogoInstitucional/documentos/Acta-15-Espacio-de-Dialogo-AFIP-Camaras-Empresariales-14-11.pdf **Current behavior before PR:** It is not possible to create Factura B for a foreign customer. **Desired behavior after PR is merged:** It is possible to create Factura B for a foreign customer. Task Adhoc side: 30008 Task latam side: 913 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#185160 Forward-Port-Of: odoo/odoo#176604
Steps to reproduce the bug: - Create a storable product “P1”: - UoM: gram - Create a component “C1” - UoM: gram - Create a BoM for P1: - quantity: 1kg - Component: 1g of C1 - Create a Mo to produce 1kg of P1 - Confirm the MO - Create a landed cost: - Apply on manufacturing order - Select the created MO - Add a landed product with a unit price of 25 - Validate the landed cost - Go to the linked valuation layer Problem: A value of (25 * 1000) is
Original PR description
Steps to reproduce the bug:
- Create a storable product “P1”:
- UoM: gram
- Create a component “C1”
- UoM: gram
- Create a BoM for P1:
- quantity: 1kg
- Component: 1g of C1
- Create a Mo to produce 1kg of P1
- Confirm the MO
- Create a landed cost:
- Apply on manufacturing order
- Select the created MO
- Add a landed product with a unit price of 25
- Validate the landed cost
- Go to the linked valuation layer
Problem:
A value of (25 * 1000) is added instead of only $25
opw-4252901
Forward-Port-Of: odoo/odoo#185725Update the OWL lib. Release notes: https://github.com/odoo/owl/releases/tag/v2.4.1 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#185965
Original PR description
Update the OWL lib. Release notes: https://github.com/odoo/owl/releases/tag/v2.4.1 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#185965
…creating accrued revenue entries Problem: When using the generate accrued revenue entries action on a sale/purchase order where the first order line is a section or note leads to an invalid account move being created. The move contains a line with not account set. Purpose of this PR: To make sure only product lines are taken into account when generating these entries How to reproduce: 1) Create and confirm a sale order where the first order line is a section or note and the next con
Original PR description
…creating accrued revenue entries Problem: When using the generate accrued revenue entries action on a sale/purchase order where the first order line is a section or note leads to an invalid account move being created. The move contains a line with not account set. Purpose of this PR: To make sure only product lines are taken into account when generating these entries How to reproduce: 1) Create and confirm a sale order where the first order line is a section or note and the next contains a product 2) Run the Accrued Revenue Entry contextual action 3) Fill the Accrual Account and Amount fields with arbitrary data and hit Create Entry 4) Error appears, a move line is generated with no account --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#183230
Currently, sending a Bis 3 xml on Peppol raises errors if an early payment discount is set on the invoice (the Belgian one: "Always (upon invoice)", for instance: "2/7 Net 30"). An example xml can be found in the attachments. It raises the error: ``` [BR-E-01]-An Invoice that contains an Invoice line (BG-25), a Document level allowance (BG-20) or a Document level charge (BG-21) where the VAT category code (BT-151, BT-95 or BT-102) is "Exempt from VAT" shall contain exactly one VAT breakdo
Original PR description
Currently, sending a Bis 3 xml on Peppol raises errors if an early payment discount is set on the invoice (the Belgian one: "Always (upon invoice)", for instance: "2/7 Net 30"). An example xml can be found in the attachments. It raises the error: ``` [BR-E-01]-An Invoice that contains an Invoice line (BG-25), a Document level allowance (BG-20) or a Document level charge (BG-21) where the VAT category code (BT-151, BT-95 or BT-102) is "Exempt from VAT" shall contain exactly one VAT breakdown (BG-23) with the VAT category code (BT-118) equal to "Exempt from VAT" ``` Looking at the documentation on [1], we realize we lack an additional VAT breakdown in the xml. [1] https://einvoice.belgium.be/en/article/business-expert-group-overview task-4283933 Forward-Port-Of: odoo/odoo#185138
Monaco is sharing the same CoA as France, therefore we should use l10n_fr when installing account with a company from Monaco. opw-4197369 Forward-Port-Of: odoo/odoo#181462 Forward-Port-Of: odoo/odoo#181333
Original PR description
Monaco is sharing the same CoA as France, therefore we should use l10n_fr when installing account with a company from Monaco. opw-4197369 Forward-Port-Of: odoo/odoo#181462 Forward-Port-Of: odoo/odoo#181333
Versions -------- - 16.0 _(sale_product_configurator)_ - 17.0+ _(website_sale_product_configurator)_ Steps ----- 1. Enable Dutch language; 2. go to eCommerce; 3. switch to mobile view; 4. go to a product which has optional products; 5. add to cart. Issue ----- There's not enough space in the configurator to properly display the "Toevoegen aan winkelmandje" button. Cause ----- The view isn't mobile-responsive. Solution -------- Replace the button with a simple cart ico
Original PR description
Versions -------- - 16.0 _(sale_product_configurator)_ - 17.0+ _(website_sale_product_configurator)_ Steps ----- 1. Enable Dutch language; 2. go to eCommerce; 3. switch to mobile view; 4. go to a product which has optional products; 5. add to cart. Issue ----- There's not enough space in the configurator to properly display the "Toevoegen aan winkelmandje" button. Cause ----- The view isn't mobile-responsive. Solution -------- Replace the button with a simple cart icon to ensure consistency between localisations while keeping things simple. opw-4198786 Forward-Port-Of: odoo/odoo#185936 Forward-Port-Of: odoo/odoo#185133
Commit [1] optimized the `has_group` util to avoid a RPC for information that is already in the session_info. The problem is that it supposed that this information would always be available in there, which was already not the case for the frontend `session_info` when this was done. This commit simply makes the util not cache a value if there was actually no found value, and thus let the util falls back to making a RPC if needed. Note that in 18.0, the user service is actually not a service
Original PR description
Commit [1] optimized the `has_group` util to avoid a RPC for information that is already in the session_info. The problem is that it supposed that this information would always be available in there,…
Commit [1] optimized the `has_group` util to avoid a RPC for information that is already in the session_info. The problem is that it supposed that this information would always be available in there, which was already not the case for the frontend `session_info` when this was done. This commit simply makes the util not cache a value if there was actually no found value, and thus let the util falls back to making a RPC if needed. Note that in 18.0, the user service is actually not a service anymore (since commit [2]) and is the only truth of information about user data (since commit [3]), so this makes this even more important. We could consider adding the same group information in the frontend session_info in the future, but in general we want to avoid loading any useless information for visitors and would not mind the extra RPC for connected ones when it comes to the website. [1]: https://github.com/odoo/odoo/commit/da257e9d572047617cdfaac33fbe47983e8ab30d [2]: https://github.com/odoo/odoo/commit/3fb72654a898eb5c5b1c89279b0638dab8e3881d [3]: https://github.com/odoo/odoo/commit/182b0554882a2eeb5d86c9cb6fdaed6618b2615b Related to task-4290643 Forward-Port-Of: odoo/odoo#185479