Wednesday, April 23, 2025
20 changes · saas-18.1
Resolved issues and error corrections
This fix aligns the default Point of Sale loading limit with the intended value so stores load the expected number of records by default. It also centralizes these default values to reduce the chance of similar inconsistencies in future updates.
Original PR description
- In this PR (https://github.com/odoo/odoo/pull/199923) we set a default system parameter to define the number limit of partner to load in PoS by default (set to 20000). - But since this PR (https://github.com/odoo/odoo/pull/184417) the default value was was changes from 20000 to 5000. - To avoid making new similar issues, these defaults values are now extracted as constant class. 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
Miscellaneous changes
Before this commit, if the tour steps was "edit input" then "click second element dropdown", the tour was stuck and was backwarding to the "edit input" because during a moment the dropdown had only one element (the loading). Now, the loading will be taken in account to wait for the next mutation observer for the case of a dropdown TASK-ID: 4623449 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#205874
Original PR description
Before this commit, if the tour steps was "edit input" then "click second element dropdown", the tour was stuck and was backwarding to the "edit input" because during a moment the dropdown had only one element (the loading). Now, the loading will be taken in account to wait for the next mutation observer for the case of a dropdown TASK-ID: 4623449 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#205874
Steps: - Install hr_timesheet_attendance. - Set the timezone (for both user and calendar) to Europe/Zurich. - Create Attendance records: [03/01/2025: 00:25:36, 03/01/2025: 10:25:59] - Create a Timesheet for 03/01/2025. - Open the Timesheet Attendance Report and group by day. - Check Attendance Hours and Timesheet Hours: Attendance Hours : Timesheet Hours 02/01/2025: 10 : 00 03/01/2025: 00 : 08 Issue: Attendance was shown as one day earlier
Original PR description
Steps: - Install hr_timesheet_attendance. - Set the timezone (for both user and calendar) to Europe/Zurich. - Create Attendance records: [03/01/2025: 00:25:36, 03/01/2025: 10:25:59] - Create a Timesheet for 03/01/2025. - Open the Timesheet Attendance Report and group by day. - Check Attendance Hours and Timesheet Hours: Attendance Hours : Timesheet Hours 02/01/2025: 10 : 00 03/01/2025: 00 : 08 Issue: Attendance was shown as one day earlier than expected. Reason: The check_in date was incorrect because it was using UTC instead of the employee's local time zone. Fix: Converted check_in to the employee's local time zone before extracting the date. issue:https://github.com/odoo/odoo/issues/169592 task-4320477 Forward-Port-Of: odoo/odoo#206713 Forward-Port-Of: odoo/odoo#192434
This commit fixes an issue with the slide.slide and slide.channel models from website_slides. When a user tries to send a message via the chatter the default_recipients and suggested_recipients added the attendees for slides and courses. This means that everytime someone sends a message on slide.channel or slide.slide potentially hundreds of people would be spammed. To fix this, we override in both models _mail_get_partner_fields. This method is supposed to return the name of the fields link
Original PR description
This commit fixes an issue with the slide.slide and slide.channel models from website_slides. When a user tries to send a message via the chatter the default_recipients and suggested_recipients added the attendees for slides and courses. This means that everytime someone sends a message on slide.channel or slide.slide potentially hundreds of people would be spammed. To fix this, we override in both models _mail_get_partner_fields. This method is supposed to return the name of the fields linked to customers. In the case of the above models, we don't want to send a message to all the attendees (they were stored in partner_ids which is the default field read). Thus by returning an empty list we block the computation of suggested_recipients and default_recipients. Letting full control to the user sending the email which people to notify. task-4736015 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#206474
Steps to reproduce the issue: - Create a storable product “P1” - Create a Bill of Materials: - Finished product: 1 unit of P1 - Components: - 1 unit of C1 - Create a manufacturing order to produce 10 units of P1 - Confirm the MO - Split the MO into two: - This creates two new MOs, each for 5 units: - “WH-MO-001” - ”WH-MO-002” - For the first MO (WH-MO-001): - Set Quantity Produced to 1. - Validate it and choose to create a backorder. Problem: - The b
Original PR description
Steps to reproduce the issue: - Create a storable product “P1” - Create a Bill of Materials: - Finished product: 1 unit of P1 - Components: - 1 unit of C1 - Create a manufacturing order to produce 10…
Steps to reproduce the issue:
- Create a storable product “P1”
- Create a Bill of Materials:
- Finished product: 1 unit of P1
- Components:
- 1 unit of C1
- Create a manufacturing order to produce 10 units of P1
- Confirm the MO
- Split the MO into two:
- This creates two new MOs, each for 5 units: - “WH-MO-001” - ”WH-MO-002”
- For the first MO (WH-MO-001):
- Set Quantity Produced to 1.
- Validate it and choose to create a backorder.
Problem:
- The backorder is incorrectly named “WH-MO-001-003” instead of the expected WH-MO-003.
- Additionally, the original MO is renamed “WH-MO-001-001”, which is unexpected.
- However, if you perform the same steps on the second MO (WH-MO-002), the backorder is correctly named “WH-MO-003”, and the original name remains unchanged.
Root cause:
- When the original MO is first split, each resulting MO receives a backorder sequence:
- First split MO (WH-MO-001): backorder_sequence = 1
- Second split MO (WH-MO-002): backorder_sequence = 2
- When creating a backorder from an MO with backorder_sequence = 1, the following logic is triggered:
- https://github.com/odoo/odoo/blob/18.0/addons/mrp/models/mrp_production.py#L1844
- Since the condition if backorder_sequence > 1 is false for WH-MO-001:
- https://github.com/odoo/odoo/blob/18.0/addons/mrp/models/mrp_production.py#L1782
- So the name + seq_back is added:
https://github.com/odoo/odoo/blob/18.0/addons/mrp/models/mrp_production.py#L1784
opw-4686959
Forward-Port-Of: odoo/odoo#205760Another check on the object received by the IoT Box containing certificate keys was always returning False, resulting in the certificate never being applied to the box. The object returned by odoo.com is a dictionary containing either: - 'error': 'an error message', - 'result': False (always False), or: - 'private_key_pem', - 'x509_pem', - 'subject_cn'. So checking `response.get("result")` would always return `False`, even if the server returned a certificate. Forward-Port-Of: odoo
Original PR description
Another check on the object received by the IoT Box containing certificate keys was always returning False,
resulting in the certificate never being applied to the box.
The object returned by odoo.com is a dictionary containing either:
- 'error': 'an error message',
- 'result': False (always False),
or:
- 'private_key_pem',
- 'x509_pem',
- 'subject_cn'.
So checking `response.get("result")` would always return `False`, even if the server returned a certificate.
Forward-Port-Of: odoo/odoo#206605
Forward-Port-Of: odoo/odoo#206499is_freelancer is not passed, but freelancer is as value to the XML opw-4634677 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 Forward-Port-Of: odoo/odoo#206127
Original PR description
is_freelancer is not passed, but freelancer is as value to the XML opw-4634677 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 Forward-Port-Of: odoo/odoo#206127
Before this commit, when Chromium was running in kiosk mode under Wayland, it would not detect that the input device was a touchscreen. This resulted in touchscreen-specific code (such as hiding the cursor in the self-order kiosk) not working. After this commit, we pass the `--touch-events` flag to Chromium when running in kiosk mode, which forces touch events to be enabled. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odo
Original PR description
Before this commit, when Chromium was running in kiosk mode under Wayland, it would not detect that the input device was a touchscreen. This resulted in touchscreen-specific code (such as hiding the cursor in the self-order kiosk) not working. After this commit, we pass the `--touch-events` flag to Chromium when running in kiosk mode, which forces touch events to be enabled. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#206025
**Before this PR:** - In a fullscreen mode, mail preview was visible only on the top half of the screen. - Traceback when changing name of the image. - 'Create and edit' option when creating a new tag. **After this PR:** - String of `reward_message` will be changed to 'Thank You Message'. - Only 'Create' option will displayed while creating a new tag. - Mail preview will be visible in the center of the screen. - 'Add to Templates' in mass_mailing preview will no longer be visible. T
Original PR description
**Before this PR:** - In a fullscreen mode, mail preview was visible only on the top half of the screen. - Traceback when changing name of the image. - 'Create and edit' option when creating a new tag. **After this PR:** - String of `reward_message` will be changed to 'Thank You Message'. - Only 'Create' option will displayed while creating a new tag. - Mail preview will be visible in the center of the screen. - 'Add to Templates' in mass_mailing preview will no longer be visible. Task-4387904 Forward-Port-Of: odoo/odoo#198470
Steps: - Install `web_studio` - Enable debug mode - Open Users view - Open studio - Select any users fields (Users Types for example) - Click on More - Traceback Similar fix: https://github.com/odoo/enterprise/pull/50249 https://github.com/odoo/enterprise/pull/60321 This commit add a dialog preventing the users from accessing fields properties. opw-4700432 Forward-Port-Of: odoo/enterprise#83636 Forward-Port-Of: odoo/enterprise#83415
Original PR description
Steps: - Install `web_studio` - Enable debug mode - Open Users view - Open studio - Select any users fields (Users Types for example) - Click on More - Traceback Similar fix: https://github.com/odoo/enterprise/pull/50249 https://github.com/odoo/enterprise/pull/60321 This commit add a dialog preventing the users from accessing fields properties. opw-4700432 Forward-Port-Of: odoo/enterprise#83636 Forward-Port-Of: odoo/enterprise#83415
**Steps to reproduce:** - Install Accounting - In Bank journal settings, make sure that there's no Outstanding Payments account - Create a bill for a customer - Confirm it - Create a second bill for the same customer - Confirm it - Go to the bills list - Select the 2 created bills - Create a payment via "Pay" button: * Journal: Bank * Payment Method: Manual Payment * Group Payments: [checked] - Do not validate the payment - Go to "Accounting / Vendors / Payments" - Selec
Original PR description
**Steps to reproduce:** - Install Accounting - In Bank journal settings, make sure that there's no Outstanding Payments account - Create a bill for a customer - Confirm it - Create a second bill for…
**Steps to reproduce:** - Install Accounting - In Bank journal settings, make sure that there's no Outstanding Payments account - Create a bill for a customer - Confirm it - Create a second bill for the same customer - Confirm it - Go to the bills list - Select the 2 created bills - Create a payment via "Pay" button: * Journal: Bank * Payment Method: Manual Payment * Group Payments: [checked] - Do not validate the payment - Go to "Accounting / Vendors / Payments" - Select the created payment and create a batch - Validate the batch payment => The payment status of both bills is "In Payment" - From Accounting dashboard, go to transactions of Bank journal (reconciliation widget) - Create a new transaction for the previous customer with the amount of the batch payment - In the reconciliation widget, go to "Batch Payments" tab - Select the created batch payment - Validate to reconcile - Check the bills list **Issue:** Only one of the bills has its payment status set to "Paid", the other one staying in "In Payment" status. **Cause:** In the method that checks which account move lines are included in the batch payment, we loop on each linked move line and take the "min" between the remaining amount of the batch payment and the amount of the move line until the remaining amount reaches 0. However, for vendor bills, these amounts are negative and taking the "min" amount returns the remaining amount directly, resulting in only having 1 move line set to reconcile. opw-4595006 Forward-Port-Of: odoo/enterprise#83634
### Steps to reproduce: - Create a task in Field Service - Navigate to the product's catalog through the smart button - Add some products to the SO - Filter with 'Added products' - Notice the quantity bar is not shown ### Cause: This is happening as when click on the product smart button we are passing the order_id in the context to get the order lines info https://github.com/odoo/enterprise/blob/6e7525e0e0c2858e028694e9227077b2275d88c5/industry_fsm_sale/static/src/components/pr
Original PR description
### Steps to reproduce: - Create a task in Field Service - Navigate to the product's catalog through the smart button - Add some products to the SO - Filter with 'Added products' - Notice the quantity bar is not shown ### Cause: This is happening as when click on the product smart button we are passing the order_id in the context to get the order lines info https://github.com/odoo/enterprise/blob/6e7525e0e0c2858e028694e9227077b2275d88c5/industry_fsm_sale/static/src/components/product_catalog/kanban_model.js#L21-L26 but if we still didn't create an order for this task order_id will be false, so it won't have an order to fetch its data and will just add the default data where the quantity will be 0 https://github.com/odoo/enterprise/blob/6e7525e0e0c2858e028694e9227077b2275d88c5/industry_fsm_sale/models/sale_order.py#L45-L48 ### Fix: If we have a fsm_task we can fallback on its order_id if order_id is false. opw-4712922 Forward-Port-Of: odoo/enterprise#83396
Forward-Port-Of: odoo/enterprise#81174
Original PR description
Forward-Port-Of: odoo/enterprise#81174
The UAN, PAN and ESIC number fields on the IN employee have a unique constraint. However, they are not set to not being copied upon record duplication, which would cause duplication impossible. This PR fixes the issue by not copying the value of those field upon duplication. task-4708324 Forward-Port-Of: odoo/enterprise#83029
Original PR description
The UAN, PAN and ESIC number fields on the IN employee have a unique constraint. However, they are not set to not being copied upon record duplication, which would cause duplication impossible. This PR fixes the issue by not copying the value of those field upon duplication. task-4708324 Forward-Port-Of: odoo/enterprise#83029
Most tests of the module need to create a sale order, which requires the `group_sale_salesman` at least. Set this group. https://runbot.odoo.com/odoo/error/163649 Forward-Port-Of: odoo/enterprise#83802
Original PR description
Most tests of the module need to create a sale order, which requires the `group_sale_salesman` at least. Set this group. https://runbot.odoo.com/odoo/error/163649 Forward-Port-Of: odoo/enterprise#83802
Can't create a payment for an inactive currency. So activate the currency. https://runbot.odoo.com/odoo/error/161659 Forward-Port-Of: odoo/enterprise#83812
Original PR description
Can't create a payment for an inactive currency. So activate the currency. https://runbot.odoo.com/odoo/error/161659 Forward-Port-Of: odoo/enterprise#83812
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
-- Context -- When no seller is defined on the product that is included in the approval request, you cannot generate an RFQ. Adding a seller in the product should allow creating the RFQ without re-setting the request to draft. -- Behavior before the fix -- You had to reset the request to draft before being able to generate the RFQ when a seller has been added to the product. -- Behavior after the fix -- You can. There was a missing field in the depends of the compute method for the sell
Original PR description
-- Context -- When no seller is defined on the product that is included in the approval request, you cannot generate an RFQ. Adding a seller in the product should allow creating the RFQ without re-setting the request to draft. -- Behavior before the fix -- You had to reset the request to draft before being able to generate the RFQ when a seller has been added to the product. -- Behavior after the fix -- You can. There was a missing field in the depends of the compute method for the seller ids. task-4680780 Forward-Port-Of: odoo/enterprise#82874
Fix certificate generation for AR companies when other LATAM countries are installed. opw-4584457 Forward-Port-Of: odoo/enterprise#82527
Original PR description
Fix certificate generation for AR companies when other LATAM countries are installed. opw-4584457 Forward-Port-Of: odoo/enterprise#82527
This error shows up in 18.2, possibly because by waiting more for browser responses #206271 made it more likely that this error would have the time to be sent back down the pipe (also might be a change in chatter impl which makes 18.2 more sensible). However it's likely a global issue: when the tour "click[s] on ticket", it does a full page navigation then triggers the async load of a chatter which can take a pretty long while. It seems like one of the tour teardown steps can cause the loadin
Original PR description
This error shows up in 18.2, possibly because by waiting more for browser responses #206271 made it more likely that this error would have the time to be sent back down the pipe (also might be a change in chatter impl which makes 18.2 more sensible). However it's likely a global issue: when the tour "click[s] on ticket", it does a full page navigation then triggers the async load of a chatter which can take a pretty long while. It seems like one of the tour teardown steps can cause the loading of the chatter bundle to get cancelled, which is then raised as an exception. The error is triggered from `getBundle` while reading the response body, but it just wraps and forwards the error it gets, and swallowing all bundle errors is probably a bad idea... https://runbot.odoo.com/odoo/error/134748 Forward-Port-Of: odoo/enterprise#83871