Tuesday, April 22, 2025
19 changes · 18.0
Enhancements to existing features
Users now see a warning when they turn on the accounting audit trail. This helps prevent surprises because the setting cannot be turned off once accounting entries already exist.
Original PR description
Description: Adding a warning message when checking the option to enable the audit trail as this option can't be disabled if there are any existing move lines. opw-4596812 opw-4346608 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update pins a supporting connection library to a specific version, helping keep the system's installation requirements consistent and predictable. It is an internal maintenance change with no direct impact on day-to-day user workflows.
Original PR description
Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Resolved issues and error corrections
Point of Sale users can now find customers even when they type phone numbers with spaces. This fixes a mismatch between how phone numbers are stored for search and how staff may naturally enter them, making checkout customer lookup more reliable.
Original PR description
Before this commit, it was not possible to find a partner when searching with a phone number that included spaces. This was because the phone number was stored in the search string without spaces, while the user input could included them. opw-4652338 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Miscellaneous changes
Despite #205190 we still have sometimes a broken cursor, most of the time because of a websocket request. This is because this stable solution cannot catch a cursor without cookie that is executed after the browser closes, or during the next test. Checking the logs: 2025-04-11 05:18:04,048 13 INFO 78181227-16-0-all odoo.tests.common: Opening a test cursor without specified test on request /websocket in /knowledge/tests/test_knowledge_form_ui.py:TestKnowledgeUI.test_knowledge_main_flow 20
Original PR description
Despite #205190 we still have sometimes a broken cursor, most of the time because of a websocket request. This is because this stable solution cannot catch a cursor without cookie that is executed…
Scrap orders now consistently require a company before related stock operations can continue. This prevents incomplete scrap records from causing unexpected errors or inconsistent inventory behavior.
Original PR description
Issue Before This Commit: ------------------------------ The 'company' field was required but not validated in relevant triggers for scrap orders. This allowed operations to proceed even when the 'company' field was unset, leading to unexpected issues and inconsistent behavior. Steps to reproduce: ------------------------------ 1. Enable multi-step routes. 2. Create a new scrap order and add a product. 3. Remove the company from the company field. With This Commit: ------------------------------ - Added a check for 'company' in relevant triggers to ensure that operations only proceed if a company is set. - This fix guarantees that the 'company' field is always set (required), preventing errors and maintaining consistent behavior in scrap orders. task-4497387
This change prevents certain internal performance tests from failing when results vary unpredictably in automated test runs. It helps keep validation pipelines stable while avoiding false alarms that do not reflect product issues.
Original PR description
Some of the tests are not deterministic on the runbot. Avoid raising errors in these cases. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix ensures the US payroll accounting module imports its missing views as intended. It helps prevent setup or display issues for users relying on US payroll accounting screens.
Original PR description
Coming From: https://github.com/odoo/enterprise/pull/69708
Despite #205190 we still have sometimes a broken cursor, most of the time because of a websocket request. This is because this stable solution cannot catch a cursor without cookie that is executed after the browser closes, or during the next test. Checking the logs: 2025-04-11 05:18:04,048 13 INFO 78181227-16-0-all odoo.tests.common: Opening a test cursor without specified test on request /websocket in /knowledge/tests/test_knowledge_form_ui.py:TestKnowledgeUI.test_knowledge_main_flow 2025-04-11 04:56:57,155 13 INFO 78181121-16-0-all odoo.tests.common: Opening a test cursor without specified test on request /websocket in /test_sale_product_configurators/tests/test_sale_product_configurator.py:TestProductConfiguratorUi.test_02_product_configurator_advanced That indicates that we are in the case where the request don't have a cookie, despite the route being called from a chrome. It is most likely due to the fact that the browser cookie are cleared at the end of a browser js call, before navigating to about:blank 2025-04-11 04:56:57,119 13 INFO 78181121-16-0-all odoo.addons.test_sale_product_configurators.tests.test_sale_product_configurator.TestProductConfiguratorUi: Deleting cookies and clearing local storage It is actually easy to reproduce by adding a sleep before navigating to about:blank in browser.clear(). We can see that the websocket route is still called periodically at the end of a test. This error will occur when this request is made just between the cookies are cleared and the page navigates to about:blank. One possibility is to avoid to clear the cookie since the user profile is deleted after the browser is stopped, but unfortunately in this version the browser is kept between tests of the same class. It is maybe not sufficient but navigating to a blank page before removing the cookies should reduce the possibility of having a request without cookie reaching the server. In this case a sleep after about:blank, before clearing the cookie shows that we don't have repeated call to /websocket anymore. Another possibility is to check if the request is a websocket request and to not open a cursor in that case if we don't have a cookie identifying the test. This cannot be done for all requests since it is possible that some call are made when generating a pdf, or any call that would open a TestCursor without being inside a browser_js or url_open Combining both solution should hopefully highly reduce this error. A final decision was made to also forbid any request coming after a browser_js. - browser_js is the main source of request reaching the server asynchronously. Other ways to create a request on the server is synchronous with the test and will wait for the result. - After a browser js, it is unlikely to make another request outside an url_open or browser_js. It was the case for some xmlrpc requests, the dirty solution was to make the test non strict during this request. Those tests could still be a small cause of randomness. Note: The explicit deletion of the session cookie is also removed, it is not needed since all cookies are cleared just after, and having a request that could reach the server without session cookies feels a little like a good solution to have random access error. Forward-Port-Of: odoo/odoo#206510 Forward-Port-Of: odoo/odoo#206006
The issue was introduced by: https://github.com/odoo/odoo/commit/90158f647ba610b31499555641c9db8450b49c4c The issue has been fixed by: https://github.com/odoo/odoo/commit/b1666c61bbc9d7e7b920483e168c6048ecde011c This commit is adding a test for it. **Steps to reproduce:** - Install Accounting and purchase_stock - Activate a foreign currency (e.g. Euro) - Create a PO: * Vendor: [any] * Currency: EUR * Product: [any with a Unit Price and a tax] * Payment Terms: [any] (e.g
Original PR description
The issue was introduced by: https://github.com/odoo/odoo/commit/90158f647ba610b31499555641c9db8450b49c4c The issue has been fixed by:…
The issue was introduced by: https://github.com/odoo/odoo/commit/90158f647ba610b31499555641c9db8450b49c4c The issue has been fixed by: https://github.com/odoo/odoo/commit/b1666c61bbc9d7e7b920483e168c6048ecde011c This commit is adding a test for it. **Steps to reproduce:** - Install Accounting and purchase_stock - Activate a foreign currency (e.g. Euro) - Create a PO: * Vendor: [any] * Currency: EUR * Product: [any with a Unit Price and a tax] * Payment Terms: [any] (e.g. 15 Days) - Confirm the PO - Validate the receipt order - Go to "Accounting / Vendors / Bills" - Create a new bill - In "Auto-Complete" field, select the created PO **Issue:** A traceback is raised due to a division by zero. **Cause:** The bill and its lines are created from some information coming from the PO. In the computation of the needed terms of the bill, a computation of the taxes is called on the lines (i.e. _compute_all_tax). During that computation, the rate is computed as followed: (*) rate = line.amount_currency / line.balance if line.balance else line.currency_rate and later, rate is used as followed: 'balance': tax['amount'] / rate When "purchase_stock" module is not installed, there is no issue because "_prepare_account_move_line" method from "purchase.order. line" model doesn't initialized "amount_currency" nor "balance". Therefore, the result of (*) falls back on "line.currency_rate" which is not zero. However, when "purchase_stock" module is installed, "balance" is initialized in "_prepare_account_move_line" but not "amount_currency", leading a result of 0 for (*). opw-4681735 Forward-Port-Of: odoo/odoo#205233
Unbuilding a returned product will break the stock valuations. To reproduce the issue: 1. Create a FIFO product 2. Produce 3. Deliver 4. Return 5. Unbuild Issue: Looking at the remaining qties of the SVL, we see that the layer of the unbuild didn't consume the quantity of the return. This may lead to more important issues in the stock valuation. When processing the unbuild, we `_run_fifo` to consume the existing SVLs. To do so, we first try to find the candidates. Here is the p
Original PR description
Unbuilding a returned product will break the stock valuations. To reproduce the issue: 1. Create a FIFO product 2. Produce 3. Deliver 4. Return 5. Unbuild Issue: Looking at the remaining qties of the…
Unbuilding a returned product will break the stock valuations. To reproduce the issue: 1. Create a FIFO product 2. Produce 3. Deliver 4. Return 5. Unbuild Issue: Looking at the remaining qties of the SVL, we see that the layer of the unbuild didn't consume the quantity of the return. This may lead to more important issues in the stock valuation. When processing the unbuild, we `_run_fifo` to consume the existing SVLs. To do so, we first try to find the candidates. Here is the problem: since [1], in case of an unbuild, we force to use the SVL of the MO only. This will not work with the above use case: the SVL of the MO has been consumed by the delivery. Therefore, we don't find any candidate. This is the reason why we have some inconsistencies on the layers. Instead of getting the SVL of the MO only, we should simply give it the priority and be able to find some other candidates. [1] https://github.com/odoo/odoo/commit/49565cdd9007ac66a3b835dc073777e2e6c48f2c OPW-4683083 Forward-Port-Of: odoo/odoo#206450
<b>Steps to produce:</b> 1) Install CRM 2) In debug mode, open the stages from the crm configuration 3) Give a long text to Requirements with spaces to the stage 'new' 4) Now open my pipeline and hover on the new stage <b>Issue:-</b> When the user gives a long text with spaces to the requirements in the first stage, It is overflowing the screen. <b>Solution:-</b> Add the class text-prewrap to the tooltip of the kanban header. So the "formatted text" is respected for the k
Original PR description
<b>Steps to produce:</b> 1) Install CRM 2) In debug mode, open the stages from the crm configuration 3) Give a long text to Requirements with spaces to the stage 'new' 4) Now open my pipeline and hover on the new stage <b>Issue:-</b> When the user gives a long text with spaces to the requirements in the first stage, It is overflowing the screen. <b>Solution:-</b> Add the class text-prewrap to the tooltip of the kanban header. So the "formatted text" is respected for the kanban stage. opw-4623639 Forward-Port-Of: odoo/odoo#206193
Steps to reproduce the issue: - Add a popup with a 0.0001 days config. - Visit the page as a non-connected user. - The popup opens at some point. - Close the popup. - Wait 10 seconds. - Refresh the page ---> The popup never reappears. This issue comes from the fact that we were setting a non-integer value for the cookie expiration. The "max-age" attribute does not accept float values, so the cookie is treated as a "session" cookie. It only expires when the session ends, which can be e
Original PR description
Steps to reproduce the issue: - Add a popup with a 0.0001 days config. - Visit the page as a non-connected user. - The popup opens at some point. - Close the popup. - Wait 10 seconds. - Refresh the…
Steps to reproduce the issue: - Add a popup with a 0.0001 days config. - Visit the page as a non-connected user. - The popup opens at some point. - Close the popup. - Wait 10 seconds. - Refresh the page ---> The popup never reappears. This issue comes from the fact that we were setting a non-integer value for the cookie expiration. The "max-age" attribute does not accept float values, so the cookie is treated as a "session" cookie. It only expires when the session ends, which can be effectively "never" on some browsers that keep sessions open indefinitely. This used to work before commit [1] because we were also setting an "expires" attribute. When the "max-age" attribute was invalid, the browser would fallback to the "expires" attribute. Since that commit removed the "expires" attribute, the only remaining value (max-age) is invalid, and the popup never reappears as expected. This fix ensures the value used in "max-age" is always an integer, avoiding any invalid cookie behavior. [1]: https://github.com/odoo/odoo/commit/006ee1fc470eabdcbde68077259cf543633d6490 task-4690318 Forward-Port-Of: odoo/odoo#206429
Description of the issue/feature this PR addresses: Current behavior before PR: Project users can't subscribe partners in projectw which visibility is set to 'Invited internal users': - Set a project to that visibility type. - Create a task. - Assign a user outside the project who just has 'Project user' permissions to that task. - With that user: in the task, try to subscribe a partner to the chatter. - With that user: in the chatter, try to mention a partner who's not subscribed
Original PR description
Description of the issue/feature this PR addresses: Current behavior before PR: Project users can't subscribe partners in projectw which visibility is set to 'Invited internal users': - Set a project to that visibility type. - Create a task. - Assign a user outside the project who just has 'Project user' permissions to that task. - With that user: in the task, try to subscribe a partner to the chatter. - With that user: in the chatter, try to mention a partner who's not subscribed to the task's thread. The user couldn't subscribe any user due to permission issues on project.project. Desired behavior after PR is merged: User's are able to operate normally where access is granted. OPW-4725100 MT-9830 cc @moduon @rafaelbn @EmilioPascual --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#206298 Forward-Port-Of: odoo/odoo#205908
Even though uploaded image was .png it gives such error, reason behind this was `DecompressionBombWarning` occurred in `PIL (Pillow)`  Before this PR: - When uploading an image that is too large, the error message notification was showing wrong message. After this PR: - The error message notification will show the correct message. task-4606136 --- I confirm I have signed the CLA and
Original PR description
Even though uploaded image was .png it gives such error, reason behind this was `DecompressionBombWarning` occurred in `PIL (Pillow)`  Before this PR: - When uploading an image that is too large, the error message notification was showing wrong message. After this PR: - The error message notification will show the correct message. task-4606136 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#205864 Forward-Port-Of: odoo/odoo#199564
The test introduced in 5734ba9 opens the product catalog, filters it, then adds a product and updates its quantity. The problem is that when the product is already visible in the catalog (before filtering), the next steps can be triggerred while the filtering is still being processed. Once the filtering is done, the state of the product in the catalog is "reverted" to how it was when the filtering was called. This might be inconsistent with the state expected by the step the tour is currently in
Original PR description
The test introduced in 5734ba9 opens the product catalog, filters it, then adds a product and updates its quantity. The problem is that when the product is already visible in the catalog (before filtering), the next steps can be triggerred while the filtering is still being processed. Once the filtering is done, the state of the product in the catalog is "reverted" to how it was when the filtering was called. This might be inconsistent with the state expected by the step the tour is currently in. We can solve this by adding a different product to be filtered out. This allows to add a blocking step that just waits for the catalog not to include the new product. Fixes runbot errors: [162099](https://runbot.odoo.com/odoo/error/162099) [163417](https://runbot.odoo.com/odoo/error/163417) Forward-Port-Of: odoo/odoo#206219
Steps to Reproduce: - Open the Planning app. - Click on the avatar of a resource. - Refresh the page, then click on the avatar of a resource again. Issue: - A traceback error occurs when clicking on the avatar after a page refresh, likely due to component destruction or incomplete loading. Solution: - Consolidated multiple RPC calls into a single method in the parent component to avoid issues with component destruction during super.onWillStart. - Modified onWillStart to ensur
Original PR description
Steps to Reproduce: - Open the Planning app. - Click on the avatar of a resource. - Refresh the page, then click on the avatar of a resource again. Issue: - A traceback error occurs when clicking on the avatar after a page refresh, likely due to component destruction or incomplete loading. Solution: - Consolidated multiple RPC calls into a single method in the parent component to avoid issues with component destruction during super.onWillStart. - Modified onWillStart to ensure hr_access data is fetched without risking lifecycle conflicts. task-4210513 Forward-Port-Of: odoo/odoo#187171
Steps to reproduce: - Switch to Dark Mode (Version Enterprise). - Go to Website --> Edit Mode. - Drag and drop any snippet. - Select the snippet --> background color --> Custom tab. - Bug: The white color is dark, and the black is a white color. This commit fixes the issue by copying the variables: Black, White, and their opacity variants from the website preview to the snippet menu, so they are used in the color picker instead of the backend ones. Note that this commit also fixes a
Original PR description
Steps to reproduce: - Switch to Dark Mode (Version Enterprise). - Go to Website --> Edit Mode. - Drag and drop any snippet. - Select the snippet --> background color --> Custom tab. - Bug: The white color is dark, and the black is a white color. This commit fixes the issue by copying the variables: Black, White, and their opacity variants from the website preview to the snippet menu, so they are used in the color picker instead of the backend ones. Note that this commit also fixes another bug: the "bg-black-15" color was incorrect in the colorpicker before this commit because that class does not exist in the backend. task-4690318 Forward-Port-Of: odoo/odoo#206492
According to [last update from PGCE](https://www.boe.es/buscar/act.php?id=BOE-A-2007-19884&tn=1&p=20241221) and the accounting standards inside it: >3.º Principios contables La contabilidad de la empresa y, en especial, el registro y la valoración de los elementos de las cuentas anuales, se desarrollarán aplicando obligatoriamente los principios contables que se indican a continuación: > >1. Empresa en funcionamiento. Se considerará, salvo prueba en contrario, que la gestión de la empresa
Original PR description
According to [last update from PGCE](https://www.boe.es/buscar/act.php?id=BOE-A-2007-19884&tn=1&p=20241221) and the accounting standards inside it: >3.º Principios contables La contabilidad de la…
According to [last update from PGCE](https://www.boe.es/buscar/act.php?id=BOE-A-2007-19884&tn=1&p=20241221) and the accounting standards inside it: >3.º Principios contables La contabilidad de la empresa y, en especial, el registro y la valoración de los elementos de las cuentas anuales, se desarrollarán aplicando obligatoriamente los principios contables que se indican a continuación: > >1. Empresa en funcionamiento. Se considerará, salvo prueba en contrario, que la gestión de la empresa continuará en un futuro previsible, por lo que la aplicación de los principios y criterios contables no tiene el propósito de determinar el valor del patrimonio neto a efectos de su transmisión global o parcial, ni el importe resultante en caso de liquidación. > >En aquellos casos en que no resulte de aplicación este principio, en los términos que se determinen en las normas de desarrollo de este Plan General de Contabilidad, la empresa aplicará las normas de valoración que resulten más adecuadas para reflejar la imagen fiel de las operaciones tendentes a realizar el activo, cancelar las deudas y, en su caso, repartir el patrimonio neto resultante, debiendo suministrar en la memoria de las cuentas anuales toda la información significativa sobre los criterios aplicados. > >2. Devengo. Los efectos de las transacciones o hechos económicos se registrarán cuando ocurran, imputándose al ejercicio al que las cuentas anuales se refieran, los gastos y los ingresos que afecten al mismo, con independencia de la fecha de su pago o de su cobro. > >3. Uniformidad. Adoptado un criterio dentro de las alternativas que, en su caso, se permitan, deberá mantenerse en el tiempo y aplicarse de manera uniforme para transacciones, otros eventos y condiciones que sean similares, en tanto no se alteren los supuestos que motivaron su elección. De alterarse estos supuestos podrá modificarse el criterio adoptado en su día; en tal caso, estas circunstancias se harán constar en la memoria, indicando la incidencia cuantitativa y cualitativa de la variación sobre las cuentas anuales. > > 4. Prudencia. Se deberá ser prudente en las estimaciones y valoraciones a realizar en condiciones de incertidumbre. La prudencia no justifica que la valoración de los elementos patrimoniales no responda a la imagen fiel que deben reflejar las cuentas anuales. > > Asimismo, sin perjuicio de lo dispuesto en el artículo 38 bis del Código de Comercio, únicamente se contabilizarán los beneficios obtenidos hasta la fecha de cierre del ejercicio. Por el contrario, se deberán tener en cuenta todos los riesgos, con origen en el ejercicio o en otro anterior, tan pronto sean conocidos, incluso si sólo se conocieran entre la fecha de cierre de las cuentas anuales y la fecha en que éstas se formulen. En tales casos se dará cumplida información en la memoria, sin perjuicio de su reflejo, cuando se haya generado un pasivo y un gasto, en otros documentos integrantes de las cuentas anuales. Excepcionalmente, si los riesgos se conocieran entre la formulación y antes de la aprobación de las cuentas anuales y afectaran de forma muy significativa a la imagen fiel, las cuentas anuales deberán ser reformuladas. > > Deberán tenerse en cuenta las amortizaciones y correcciones de valor por deterioro de los activos, tanto si el ejercicio se salda con beneficio como con pérdida. > > 5. No compensación. Salvo que una norma disponga de forma expresa lo contrario, no podrán compensarse las partidas del activo y del pasivo o las de gastos e ingresos, y se valorarán separadamente los elementos integrantes de las cuentas anuales. > > 6. Importancia relativa. Se admitirá la no aplicación estricta de algunos de los principios y criterios contables cuando la importancia relativa en términos cuantitativos o cualitativos de la variación que tal hecho produzca sea escasamente significativa y, en consecuencia, no altere la expresión de la imagen fiel. Las partidas o importes cuya importancia relativa sea escasamente significativa podrán aparecer agrupados con otros de similar naturaleza o función. > > En los casos de conflicto entre principios contables, deberá prevalecer el que mejor conduzca a que las cuentas anuales expresen la imagen fiel del patrimonio, de la situación financiera y de los resultados de la empresa. For item 5, assets and liabilities, income and expenses shall not be offset, unless required or permitted by a standard. Therefore, group 55 accounts should be presented: - On the assets side if they have a debit balance. - On the liabilities side if they have a credit balance. - Without offsetting each other. @moduon MT-9820 @chklop @jco-odoo @rafaelbn Forward-Port-Of: odoo/enterprise#82976
Steps to Reproduce: - Open the Planning app. - Click on the avatar of a resource. - Refresh the page, then click on the avatar of a resource again. Issue: - A traceback error occurs when clicking on the avatar after a page refresh, likely due to component destruction or incomplete loading. Solution: - Consolidated multiple RPC calls into a single method in the parent component to avoid issues with component destruction during `super.onWillStart`. - Modified `onWillStart` to ensure `h
Original PR description
Steps to Reproduce: - Open the Planning app. - Click on the avatar of a resource. - Refresh the page, then click on the avatar of a resource again. Issue: - A traceback error occurs when clicking on the avatar after a page refresh, likely due to component destruction or incomplete loading. Solution: - Consolidated multiple RPC calls into a single method in the parent component to avoid issues with component destruction during `super.onWillStart`. - Modified `onWillStart` to ensure `hr_access` data is fetched without risking lifecycle conflicts. task-4210513 Forward-Port-Of: odoo/enterprise#75121
Sale orders have to be created during the test, which can fail if the test user does not have the right ACLs. The creation of the SOs seem to be just setup for what the tests want to check, so just sudo into them. https://runbot.odoo.com/odoo/error/163653 Forward-Port-Of: odoo/enterprise#83717
Original PR description
Sale orders have to be created during the test, which can fail if the test user does not have the right ACLs. The creation of the SOs seem to be just setup for what the tests want to check, so just sudo into them. https://runbot.odoo.com/odoo/error/163653 Forward-Port-Of: odoo/enterprise#83717