Daily updates from Odoo
Navigate
Branch
Wednesday, February 7, 2024
58 changes
20 changes
Enhancements to existing features
Dropdown menus across many enterprise apps have been updated to use a shared, more consistent behavior. This should make menus easier to navigate, improve keyboard support, and reduce display issues such as menus appearing behind other content.
Original PR description
We currently have too many different implementation of the same concern: an input with a dropdown/popover/select menu that can be customized, display a list of elements, let the user navigate with the keyboard, can be closed with escape, can be closed with an outside click. Also, the current navigation systems does not handle inputs properly. This commit addresses that by doing multiple things: - It tries to improve the Dropdown component with a cleaner props API while keeping its ease of use. - The navigation has been improved to support inputs and better customization. - The Dropdown now uses the popover/overlay service which will cause less z-index issues. *Following tasks will convert some of the current components (like Autocomplete) to make use of the new Dropdown component.* Project task: [3266145](https://www.odoo.com/mail/view?model=project.task&res_id=3266145&access_token=7a09516e-1a2d-4970-a909-0f5099588055)
Subscription users now see clearer wording, more complete status information, and better pricing details throughout the interface. The update improves day-to-day usability by showing currency on MRR, highlighting recurring pricing periods, tracking plan changes, and correcting labels and empty-state messages.
Original PR description
This commit aims to: 1. Correct validation error message when saving a subscription with recurring products and no recurring plan (replace 'subscription' plan with 'recurring' plan) 2. Track recurring plan changes (ie.. monthly --> yearly) 3. Add currency symbol on MRR 4. Change empty list message of "to renew" 5. Show the first recurring price of the list with the period on the product card in kanban view 6. Correct "Activity Plans" view name 7. Add missing "renewed" tag on the subscription form Task: 3679449
The project sharing experience now uses clearer wording aligned with the Knowledge sharing tool, making it easier for users to understand who can view shared projects. Invite options are also tightened so users can only select partners with appropriate project access rights.
Original PR description
Revise 'Share' button behavior in project view to align with Knowledge sharing tool - Change 'share to web' to 'share with anyone' - Modify 'publish and share with anyone' to 'anyone can view' - Rename 'article published' to 'project shared' - Eliminate 'no access' permission - Restrict partner selection during invite to users with project access rights task-2893621
Spreadsheet pivot autofill was adjusted to avoid unnecessary copying while preserving the original pivot setup. This should make the action more efficient and reduce the chance of unintended changes behind the scenes.
Original PR description
adaptation to avoid mutating the pivot definition See community PR
Resolved issues and error corrections
Fixed an issue where editing cells in account reports could trigger an error when debug mode was enabled. This helps accounting users and support teams work with editable reports more reliably during troubleshooting or configuration.
Original PR description
Editing an editable cell within account reports while in debug mode previously resulted in a traceback error. This issue was due to the strict props validation enabled in debug mode, where the `close` prop was being passed to the `AccountReportEditPopover` component without being defined in its list of accepted props. To address this, the `close` prop has now been duly added to the component's props list, ensuring smooth functionality and eliminating the error. task-3717423
Code cleanup and technical improvements
Spreadsheet missing-cell checks now run only when a user opens the dialog to insert a specific pivot cell, instead of during every spreadsheet evaluation. This reduces unnecessary processing, especially for dashboards or spreadsheets not being edited, while keeping the feature in the spreadsheet editing area where it belongs.
Original PR description
This commit moves the cell missing logic from the pivot model to spreadsheet edition. The objective is twofold: * It's not necessary to recompute the missing cells when the spreadsheet is not open in edition mode. (e.g. dashboard) * The missing cells feature is a feature of spreadsheet_edition, so it makes sense to move it to the spreadsheet_edition module. This commit also changes the way the missing cells are computed. The missing cells are now computed **only** when the user opens the spreadsheet dialog to insert a specific pivot cell. This is more efficient than recomputing the missing cells at each evaluation. Task: 3724263
Miscellaneous changes
This commit is a fix for the FontAwesomeIconSelector component. The regex being used didn't consider some added icons (using other font-family), or alterations of existing ones. Such selectors ".fa.fa-tiktok:before" were matching, resulting in icons being present from the list. But those icons cannot be used properly as a FontAwesome icon, since they may use another font-family, or alter the content value described from the scss. Now, only icons with selectors matching ".fa-[xxx]:before
Original PR description
This commit is a fix for the FontAwesomeIconSelector component. The regex being used didn't consider some added icons (using other font-family), or alterations of existing ones. Such selectors ".fa.fa-tiktok:before" were matching, resulting in icons being present from the list. But those icons cannot be used properly as a FontAwesome icon, since they may use another font-family, or alter the content value described from the scss. Now, only icons with selectors matching ".fa-[xxx]:before" are found, and the list no longer display invisible icons. Forward-Port-Of: odoo/enterprise#56034
For whatever reason, groupby didn't do its job. Anyway, it is more readable to groupby using a dict i/o itertools.groupby. task-3582248 Forward-Port-Of: odoo/enterprise#50159
Original PR description
For whatever reason, groupby didn't do its job. Anyway, it is more readable to groupby using a dict i/o itertools.groupby. task-3582248 Forward-Port-Of: odoo/enterprise#50159
It generates a lot of urls that will return 403 since it is restricted by country. Forward-Port-Of: odoo/enterprise#55928
Original PR description
It generates a lot of urls that will return 403 since it is restricted by country. Forward-Port-Of: odoo/enterprise#55928
### Steps to reproduce - Install **Payroll** app - Create two companies each belonging to different countries, for example: - Company A in US - Company B in AE - In **Company A**, create a salary structure with a salary rule that belong to Company A -US- - Using **Company A**, In the payroll app, Go to > **Reporting** > **Payroll** and click on the **MEASURES** dropdown button, U can see the newly created salary rule. Try clicking on it. Everything works fine. - Now switch to **Company
Original PR description
### Steps to reproduce - Install **Payroll** app - Create two companies each belonging to different countries, for example: - Company A in US - Company B in AE - In **Company A**, create a salary…
### Steps to reproduce - Install **Payroll** app - Create two companies each belonging to different countries, for example: - Company A in US - Company B in AE - In **Company A**, create a salary structure with a salary rule that belong to Company A -US- - Using **Company A**, In the payroll app, Go to > **Reporting** > **Payroll** and click on the **MEASURES** dropdown button, U can see the newly created salary rule. Try clicking on it. Everything works fine. - Now switch to **Company B**, create a salary structure with a salary rule that belong to **Company B** -AE- - Using **Company B**, In the payroll app, Go to > **Reporting** > **Payroll** and click on the MEASURES dropdown button, U can see the newly created salary rule. Try clicking on it. a DB error occurs. ### Investigation - When we create a new salary rule, we `_generate_payroll_report_fields()` https://github.com/odoo/enterprise/blob/b9adb690d7fd38c66a787377967a856b9678ffd1/hr_payroll/models/hr_salary_rule.py#L195 - Which `init()` the payroll report, creating a new DB view. However only the current company rules are fetched removing the other companies rules from the view as the old one is dropped https://github.com/odoo/enterprise/blob/b9adb690d7fd38c66a787377967a856b9678ffd1/hr_payroll/report/hr_payroll_report.py#L145 ### Discuss I think a better approach would be to construct a new view each time you open the payroll report, meaning to `init()` the report each time we go into https://github.com/odoo/enterprise/blob/b9adb690d7fd38c66a787377967a856b9678ffd1/hr_payroll/report/hr_payroll_report.py#L157-L165 but I think it's not a good idea to drop a view and create another each time also! opw-3675598 Forward-Port-Of: odoo/enterprise#55759 Forward-Port-Of: odoo/enterprise#55606
The cards in the ecological report weren't translated due to the strings being defined in t-values. This is switched so that they will now be correctly exported to the .pot file + translated. Additionally cleaned up some of the incorrect English for a better UX. More terms could be improved/fixed as well, but they do not affect the users as much + are already translated so changing them was avoided in stable. - Carbon => "carbon emissions": this or CO_2 are used when referring to re
Original PR description
The cards in the ecological report weren't translated due to the strings being defined in t-values. This is switched so that they will now be correctly exported to the .pot file + translated.…
The cards in the ecological report weren't translated due to the strings being defined in t-values. This is switched so that they will now be correctly exported to the .pot file + translated.
Additionally cleaned up some of the incorrect English for a better UX. More terms could be improved/fixed as well, but they do not affect the users as much + are already translated so changing them was avoided in stable.
- Carbon => "carbon emissions": this or CO_2 are used when referring
to reducing pollution due to burning fuel. "carbon" on its own implies
the element, whereas adding "emissions" to the end of it implies CO_2
(emissions), because English ¯\_(ツ)_/¯
- sparred => saved/reduced: sparred is both spelled wrong (i.e. should be spared) and incorrect to use in this case
- like => that's: "like" doesn't make sense to use in this case and is confusing to read. "That's" indicates how much the user is saving/reducing/etc. "Approximately" or "about" also would have worked, but are less friendly sounding
Forward-Port-Of: odoo/enterprise#55894
Forward-Port-Of: odoo/enterprise#54685Commit [1] moved (almost all of) the code of formatFloat from views/fields/formatters.js to core/utils/numbers, to make it accessible in the frontend. A formatFloat function was kept in formatters.js to handle the false case, which makes no sense in number utils, but is useful for fields. However, a lot of imports have been updated to use the numbers.js instead of formatters.js (i.e. they no longer benefit from the support of false), whereas they are actually formatting field values, so they sho
Original PR description
Commit [1] moved (almost all of) the code of formatFloat from views/fields/formatters.js to core/utils/numbers, to make it accessible in the frontend. A formatFloat function was kept in formatters.js to handle the false case, which makes no sense in number utils, but is useful for fields. However, a lot of imports have been updated to use the numbers.js instead of formatters.js (i.e. they no longer benefit from the support of false), whereas they are actually formatting field values, so they should have kept using the formatFloat from formatters.js This commit adapts the places where the formatFloat to use must come from formatters.js, not numbers.js. [1] https://github.com/odoo/odoo/commit/054ca0a19aaf297f420a1b478b93ae26f1b943b8 task 3722043 Forward-Port-Of: odoo/enterprise#55919
Steps to reproduce: ------------------- - install hr_payroll and hr_holidays; - create an employee; - create a contract for this employee (since 1st January for example); - create and approve a sick time off for this employee (for a day in January); - create a payslip for this employee (the payslip has two "worked days"); - confirm the payslip; - go to Reporting / Payroll and group by employee; - click on the employee's line to display the list view. Issue: ------ There are two rec
Original PR description
Steps to reproduce: ------------------- - install hr_payroll and hr_holidays; - create an employee; - create a contract for this employee (since 1st January for example); - create and approve a sick…
Steps to reproduce:
-------------------
- install hr_payroll and hr_holidays;
- create an employee;
- create a contract for this employee (since 1st January for example);
- create and approve a sick time off for this employee (for a day in January);
- create a payslip for this employee (the payslip has two "worked days");
- confirm the payslip;
- go to Reporting / Payroll and group by employee;
- click on the employee's line to display the list view.
Issue:
------
There are two records.
This can be explained by saying that this is a record by worked days type. However, if we click on it, we see that the detail is the same for both records.
Cause:
------
The query which generates the virtual table `hr_payroll_report` will give as `id`, the value of the `id` which corresponds to the payslip.
```sql
SELECT
p.id as id,
wd.id as wdid,
wd.name
FROM
(SELECT * FROM hr_payslip WHERE state IN ('done', 'paid')) p
left join hr_payslip_worked_days wd on (wd.payslip_id = p.id)
```
The result of this query will be two records:
```
id | wdid | name
----+------+------------
1 | 2 | Unpaid
1 | 3 | Attendance
```
When we want to obtain the details of the record, we will perform a read on the `hr.payroll.report` model for an `id` equal to 1 for both records, i.e. we will retrieve the same values.
Solution:
---------
Forcing the id to be unique.
Add a field indicating the type to avoid confusion.
Note:
In the list view, it is possible to group by "Payslip Name" to avoid confusion.
Note 2:
It is a band-aid fix that helps us understand what is going on in the report, but it needs to be redesigned to redirect us directly to payslip records and not records corresponding to worked days (and avoid aggregation problems).
opw-3686692
Forward-Port-Of: odoo/enterprise#55882
Forward-Port-Of: odoo/enterprise#55629Before this commit: - The `documents_tour` progresses as desired but is stuck during the final few steps. - The `documents_account_tour` has the same issue but additionally has a misplaced prompt to select the first image `mail.png` having the `inbox` tag. - The `o_FileViewer` class is incorrect. Issue: - The classes inside the trigger are missing/incorrect. - After we process the initial set of pages, the prompt to select the last remaining page is missing. After this commit: - Rect
Original PR description
Before this commit: - The `documents_tour` progresses as desired but is stuck during the final few steps. - The `documents_account_tour` has the same issue but additionally has a misplaced prompt to select the first image `mail.png` having the `inbox` tag. - The `o_FileViewer` class is incorrect. Issue: - The classes inside the trigger are missing/incorrect. - After we process the initial set of pages, the prompt to select the last remaining page is missing. After this commit: - Rectified the classes and added an extra step to select the remaining page and then process the tour. - Updated the `o_FileViewer` to `o-FileViewer`. task-3537521 Forward-Port-Of: odoo/enterprise#54935 Forward-Port-Of: odoo/enterprise#49027
On the tax report, a banner can be displayed if there exist some draft moves for the selected period. We don't want the banner to appear if the only draft move is a closing entry. The goal of the banner is indeed to warn the user if he still needs to pay attention to draft invoices/entries that might impact the report. We therefore exclude all closing entries from draft moves search. A bit of refactoring was necessary to only apply the logic to tax reports. A limit=1 has also been added on the s
Original PR description
On the tax report, a banner can be displayed if there exist some draft moves for the selected period. We don't want the banner to appear if the only draft move is a closing entry. The goal of the banner is indeed to warn the user if he still needs to pay attention to draft invoices/entries that might impact the report. We therefore exclude all closing entries from draft moves search. A bit of refactoring was necessary to only apply the logic to tax reports. A limit=1 has also been added on the search_count to improve performances. task-3682431 Forward-Port-Of: odoo/enterprise#55573 Forward-Port-Of: odoo/enterprise#55167
As seen in the nightly build https://runbot.odoo.com/runbot/build/57728091 There is an issue with the demo data where a hr employee record is trying to be set in a res.partner field. Also, one test is setting accounting stuff while this module isn't dependent on any account modules. Forward-Port-Of: odoo/enterprise#55932
Original PR description
As seen in the nightly build https://runbot.odoo.com/runbot/build/57728091 There is an issue with the demo data where a hr employee record is trying to be set in a res.partner field. Also, one test is setting accounting stuff while this module isn't dependent on any account modules. Forward-Port-Of: odoo/enterprise#55932
During the last phase of the refactor in 17.1, the field names were updated but the neutralize script was not, making it inconsistent. Forward-Port-Of: odoo/enterprise#55921
Original PR description
During the last phase of the refactor in 17.1, the field names were updated but the neutralize script was not, making it inconsistent. Forward-Port-Of: odoo/enterprise#55921
Steps to reproduce: - Install Accounting and l10n_mx_edi - Switch to a Mexican company (e.g. ESCUELA KEMPER URGATE) - Create an invoice: * Customer: [any] (e.g. INMOBILIARIA CVA) * Product: [any product with an UNSPSC Category] - Confirm the invoice - Generate CFDI via "Send & Print" button - Register Payment (Payment Way: Effectivo) - Click on "Update Payments" button - Go to the payment - Force CFDI - Send receipt by email Issue: The CFDI document of the payment is not in t
Original PR description
Steps to reproduce: - Install Accounting and l10n_mx_edi - Switch to a Mexican company (e.g. ESCUELA KEMPER URGATE) - Create an invoice: * Customer: [any] (e.g. INMOBILIARIA CVA) * Product: [any product with an UNSPSC Category] - Confirm the invoice - Generate CFDI via "Send & Print" button - Register Payment (Payment Way: Effectivo) - Click on "Update Payments" button - Go to the payment - Force CFDI - Send receipt by email Issue: The CFDI document of the payment is not in the attachments of the email as it was in previous versions. Cause: The feature was lost during the refactoring of "l10n_mx_edi" module to not depend on "account_edi" module opw-3678484 Forward-Port-Of: odoo/enterprise#55016
Steps to reproduce: - Select any transfer in barcode App - Click add product to manually edit quantity - Set quantity to 0.0002 - Click on -1 multiple times then +1 Bug: the quantity is displayed with too many precision digits (defaul float) Fix: The addition and subtraction with the +1 / -1 button should be upto the decimal value entered. opw-3551250 Forward-Port-Of: odoo/enterprise#55786 Forward-Port-Of: odoo/enterprise#53378
Original PR description
Steps to reproduce: - Select any transfer in barcode App - Click add product to manually edit quantity - Set quantity to 0.0002 - Click on -1 multiple times then +1 Bug: the quantity is displayed with too many precision digits (defaul float) Fix: The addition and subtraction with the +1 / -1 button should be upto the decimal value entered. opw-3551250 Forward-Port-Of: odoo/enterprise#55786 Forward-Port-Of: odoo/enterprise#53378
This traceback arises when a user tries to unlink multiple records Steps to produce 1. Install `approvals` 2. Open `approvals/manager/all approvals` 3. Select multiple records then delete them. Error: ``` ValueError: too many values to unpack (expected 1) File "odoo/models.py", line 5837, in ensure_one _id, = self._ids ValueError: Expected singleton: approval.request(9, 8) File "odoo/http.py", line 2150, in __call__ response = request._serve_db() File "odoo/ht
Original PR description
This traceback arises when a user tries to unlink multiple records Steps to produce 1. Install `approvals` 2. Open `approvals/manager/all approvals` 3. Select multiple records then delete them.…
This traceback arises when a user tries to unlink multiple records
Steps to produce
1. Install `approvals`
2. Open `approvals/manager/all approvals`
3. Select multiple records then delete them.
Error:
```
ValueError: too many values to unpack (expected 1)
File "odoo/models.py", line 5837, in ensure_one
_id, = self._ids
ValueError: Expected singleton: approval.request(9, 8)
File "odoo/http.py", line 2150, in __call__
response = request._serve_db()
File "odoo/http.py", line 1722, in _serve_db
return service_model.retrying(self._serve_ir_http, self.env)
File "odoo/service/model.py", line 133, in retrying
result = func()
File "odoo/http.py", line 1749, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "odoo/http.py", line 1953, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
File "odoo/addons/base/models/ir_http.py", line 222, in _dispatch
result = endpoint(**request.params)
File "odoo/http.py", line 722, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "addons/web/controllers/dataset.py", line 24, in call_kw
return self._call_kw(model, method, args, kwargs)
File "addons/web/controllers/dataset.py", line 20, in _call_kw
return call_kw(request.env[model], method, args, kwargs)
File "odoo/api.py", line 468, in call_kw
result = _call_kw_multi(method, model, args, kwargs)
File "odoo/api.py", line 453, in _call_kw_multi
result = method(recs, *args, **kwargs)
File "home/odoo/src/enterprise/17.0/approvals/models/approval_request.py", line 113, in unlink
if self.has_product:
File "odoo/fields.py", line 1148, in __get__
record.ensure_one()
File "odoo/models.py", line 5840, in ensure_one
```
When the user tries to delete multiple records traceback will be generated because it tries to unlink a record instead of calling the entire record set.
which leads to the traceback from here
https://github.com/odoo/enterprise/blob/1551fc9de63706944dffb3d5e57c88482b214a46/approvals/models/approval_request.py#L96-L105
After applying this commit we will resolve the issue by filtering the records and then unlinking the record set.
sentry-4916651369
Forward-Port-Of: odoo/enterprise#55848
Forward-Port-Of: odoo/enterprise#5541238 changes
Security fixes and vulnerability patches
This update improves security and control in project collaboration by restricting what portal users (collaborators) can do with subtasks and tags. Portal users can now only link or unlink existing tags to tasks, but cannot create, modify, or delete tags themselves. They also cannot modify restricted fields on subtasks. This prevents accidental or unauthorized changes while maintaining necessary collaboration features.
Original PR description
Restrict collaborator portals to: - Change unallowed fields on subtasks - Create/Update/Delete tags. They can only link, unlink tags to tasks. task-3698146 Forward-Port-Of: odoo/odoo#152963 Forward-Port-Of: odoo/odoo#152686
New functionality added to Odoo
This change adds an automated testing workflow that runs JavaScript code builds and tests across multiple Node.js versions (14.x, 16.x, and 18.x) on every code change. This ensures the codebase remains compatible with different JavaScript environments and catches issues early in the development process.
Original PR description
El flujo de trabajo define un trabajo llamado build que se ejecuta en una máquina virtual con Ubuntu. El trabajo utiliza una matriz para probar el código con diferentes versiones de Node.js (14.x, 16.x y 18.x). El trabajo tiene los siguientes pasos: - Usa la acción actions/checkout@v3 para obtener el código del repositorio. - Usa la acción actions/setup-node@v3 para configurar el entorno de Node.js con la versión especificada en la matriz. - Usa la acción actions/cache@v3 para almacenar en caché las dependencias de npm y restaurarlas si es posible. - Ejecuta el comando npm install para instalar las dependencias. - Ejecuta el comando grunt para compilar el código. - Ejecuta el comando npm test para ejecutar las pruebas. 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
Enhancements to existing features
This update improves how Mexican vendor invoices are imported into Odoo by making duplicate detection smarter using unique fiscal folio numbers, automatically capturing withholding taxes from imported invoices, and flagging invoices that need manual review when import issues are encountered. These changes help accounting teams process Mexican invoices more efficiently and catch potential problems early.
Original PR description
### [IMP] l10n_mx_edi: duplicate check using fiscal folio As every fiscal folio on a vendor bill in Mexico is unique, we can easily check that to find duplicates. This change extends the default…
### [IMP] l10n_mx_edi: duplicate check using fiscal folio As every fiscal folio on a vendor bill in Mexico is unique, we can easily check that to find duplicates. This change extends the default duplicate vendor bill check to first see if it can find duplicates with the same folio fiscal. If it doesn't find any, it will apply the generic duplicate check. task-3590442 ### [IMP] l10n_mx_edi: import withholding taxes Currently when importing a Mexican vendor bill, we skip the withholding taxes defined on the lines. In this change, we also allow importing the withholding taxes when we find at least one that matches in the database. task-3590442 ### [IMP] l10n_mx_edi: flag "to check" on issues with import When we're importing a Mexican vendor bill and we're unsure about something, like a tax that couldn't be found or multiple possible taxes, a message is logged in the chatter of that invoice in Odoo. However, it is not easy to identify which imported bills have errors later on when we have a bunch of them. In order to make that easier, we flag the vendor bill as "to check" whenever we encounter an uncertainty at import, so the user can easily filter on that to follow up on these invoices. task-3590442
Resolved issues and error corrections
This update removes unnecessary forced email settings from various system views across multiple modules. The change aligns the enterprise version with improvements made to the community version, ensuring consistent and cleaner email handling behavior throughout the system.
Original PR description
This commit is a follow up of its community part. see : https://github.com/odoo/odoo/pull/149806 affected version: 17.0 - master task - 3538000 https://www.odoo.com/web#id=3538000&menu_id=4720&cids=1&action=333&active_id=4105&model=project.task&view_type=form
Users were getting validation errors when trying to make calls from phone or mobile number fields in HR and Field Service applications. The issue has been fixed so that the call button now correctly uses the phone number from whichever field it was clicked on, rather than always looking for a specific field name.
Original PR description
- master - 17.0 Steps to reproduce: - Open Field Service / HR Employee Application - Open any task / employee record - Click on call button in mobile or phone field Issue: - Throws out a validation error to the user saying the mobile number which is a required field is not set Cause: - The Phone Widget Activity Patch which supplies the value of phone number from the field in which the call button has been presses has an issue - It gathers the field name in which phone widget is present and matches it to mobile or phone and returns either of the values Solution: - The simple solution is to supply the mobile number based on the field it is clicked rather than a fixed setup of supplying only mobile or phone values. task-3678808
This update fixes how the Mexican electronic invoicing system handles negative line items (refunds and discounts) in invoices and global invoices. The changes prevent sending incomplete invoices, improve how negative amounts are matched to positive ones, and allow credit notes to be properly included in global invoices. This ensures compliance with Mexican tax requirements and reduces processing errors.
Original PR description
- Better handling of errors in case of undistributed negative lines. - Prevent sending of empty invoice/order/global invoice CFDI - Better mapping of negative lines on positive ones. - Allow adding credit note with invoices inside a global invoice. - Allow auto refund of the global invoice when asking an invoice for a refunded order
This fix resolves a system error that occurred when users tried to delete multiple approval requests at once. The issue was in how the system processed bulk deletions, causing it to fail with an error message. Now users can successfully delete multiple approval requests without encountering this error.
Original PR description
This traceback arises when a user tries to unlink multiple records Steps to produce 1. Install `approvals` 2. Open `approvals/manager/all approvals` 3. Select multiple records then delete them.…
This traceback arises when a user tries to unlink multiple records
Steps to produce
1. Install `approvals`
2. Open `approvals/manager/all approvals`
3. Select multiple records then delete them.
Error:
```
ValueError: too many values to unpack (expected 1)
File "odoo/models.py", line 5837, in ensure_one
_id, = self._ids
ValueError: Expected singleton: approval.request(9, 8)
File "odoo/http.py", line 2150, in __call__
response = request._serve_db()
File "odoo/http.py", line 1722, in _serve_db
return service_model.retrying(self._serve_ir_http, self.env)
File "odoo/service/model.py", line 133, in retrying
result = func()
File "odoo/http.py", line 1749, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "odoo/http.py", line 1953, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
File "odoo/addons/base/models/ir_http.py", line 222, in _dispatch
result = endpoint(**request.params)
File "odoo/http.py", line 722, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "addons/web/controllers/dataset.py", line 24, in call_kw
return self._call_kw(model, method, args, kwargs)
File "addons/web/controllers/dataset.py", line 20, in _call_kw
return call_kw(request.env[model], method, args, kwargs)
File "odoo/api.py", line 468, in call_kw
result = _call_kw_multi(method, model, args, kwargs)
File "odoo/api.py", line 453, in _call_kw_multi
result = method(recs, *args, **kwargs)
File "home/odoo/src/enterprise/17.0/approvals/models/approval_request.py", line 113, in unlink
if self.has_product:
File "odoo/fields.py", line 1148, in __get__
record.ensure_one()
File "odoo/models.py", line 5840, in ensure_one
```
When the user tries to delete multiple records traceback will be generated because it tries to unlink a record instead of calling the entire record set.
which leads to the traceback from here
https://github.com/odoo/enterprise/blob/1551fc9de63706944dffb3d5e57c88482b214a46/approvals/models/approval_request.py#L96-L105
After applying this commit we will resolve the issue by filtering the records and then unlinking the record set.
sentry-4916651369
Forward-Port-Of: odoo/enterprise#55719
Forward-Port-Of: odoo/enterprise#55412The Payroll Report was displaying duplicate records with identical details when viewing payslip information. This fix ensures each record has a unique identifier and adds a field to clarify the worked day type, eliminating confusion when reviewing payroll data.
Original PR description
Steps to reproduce: ------------------- - install hr_payroll and hr_holidays; - create an employee; - create a contract for this employee (since 1st January for example); - create and approve a sick…
Steps to reproduce:
-------------------
- install hr_payroll and hr_holidays;
- create an employee;
- create a contract for this employee (since 1st January for example);
- create and approve a sick time off for this employee (for a day in January);
- create a payslip for this employee (the payslip has two "worked days");
- confirm the payslip;
- go to Reporting / Payroll and group by employee;
- click on the employee's line to display the list view.
Issue:
------
There are two records.
This can be explained by saying that this is a record by worked days type. However, if we click on it, we see that the detail is the same for both records.
Cause:
------
The query which generates the virtual table `hr_payroll_report` will give as `id`, the value of the `id` which corresponds to the payslip.
```sql
SELECT
p.id as id,
wd.id as wdid,
wd.name
FROM
(SELECT * FROM hr_payslip WHERE state IN ('done', 'paid')) p
left join hr_payslip_worked_days wd on (wd.payslip_id = p.id)
```
The result of this query will be two records:
```
id | wdid | name
----+------+------------
1 | 2 | Unpaid
1 | 3 | Attendance
```
When we want to obtain the details of the record, we will perform a read on the `hr.payroll.report` model for an `id` equal to 1 for both records, i.e. we will retrieve the same values.
Solution:
---------
Forcing the id to be unique.
Add a field indicating the type to avoid confusion.
Note:
In the list view, it is possible to group by "Payslip Name" to avoid confusion.
Note 2:
It is a band-aid fix that helps us understand what is going on in the report, but it needs to be redesigned to redirect us directly to payslip records and not records corresponding to worked days (and avoid aggregation problems).
opw-3686692
Forward-Port-Of: odoo/enterprise#55882
Forward-Port-Of: odoo/enterprise#55629This update fixes an issue where uninstalling the HR Referral module caused errors when trying to create job applications. The fix removes outdated system settings that reference the referral module during uninstallation, preventing errors from occurring in the job application process.
Original PR description
Issue: ------ When we uninstall the `hr_referral` module, an error occurs when we want to create a job application. This is because a domain which uses a field which only exists if the `hr_referral` module is installed is persistent on window actions. It is therefore necessary to remove these domains during uninstallation, as they are no longer present on the `hr.applicant` model. opw-3708569
This fix resolves an issue where timesheets were not being properly validated in the project timesheet forecasting system. The problem occurred because timesheets created during testing were not being found by the validation process. The fix ensures timesheets are recorded with the correct date so they can be successfully validated when the system processes them.
Original PR description
Before this commit, the timesheet to validate could be not found when the filtered is made inside `action_validate_timesheet` method, it is for that reason the timesheet created inside the test is not validated as expected. This commit ensures the timesheet created is recorded yesterday to be sure the timesheet will be validated inside `action_validate_timesheet` method. runbot-56444
Fixed an issue in the Planning module where schedule increments were not being properly grouped by time. The code was updated to use a more reliable and readable approach for organizing scheduling data, ensuring that planning operations work as intended.
Original PR description
For whatever reason, groupby didn't do its job. Anyway, it is more readable to groupby using a dict i/o itertools.groupby. task-3582248 Forward-Port-Of: odoo/enterprise#50159
This update removes a duplicate and unsupported scheduling option from the appointment system for staff users. The 'time_resource' option was confusing because it duplicated the functionality of the 'resource_time' option. By hiding this option, staff users will have a cleaner, simpler interface with only the supported scheduling choices available.
Original PR description
This PR hides the 'time_resource' option for appointment schedule-based on staff users as it is the same as the 'resource_time' option. Task-3584478 Forward-Port-Of: odoo/enterprise#55314
This fix resolves an issue where creating salary rules in one company would cause salary rules from other companies to disappear from payroll reports, resulting in database errors. The system now properly preserves all company salary rules when generating payroll reports, ensuring multi-company setups work correctly.
Original PR description
### Steps to reproduce - Install **Payroll** app - Create two companies each belonging to different countries, for example: - Company A in US - Company B in AE - In **Company A**, create a salary…
### Steps to reproduce - Install **Payroll** app - Create two companies each belonging to different countries, for example: - Company A in US - Company B in AE - In **Company A**, create a salary structure with a salary rule that belong to Company A -US- - Using **Company A**, In the payroll app, Go to > **Reporting** > **Payroll** and click on the **MEASURES** dropdown button, U can see the newly created salary rule. Try clicking on it. Everything works fine. - Now switch to **Company B**, create a salary structure with a salary rule that belong to **Company B** -AE- - Using **Company B**, In the payroll app, Go to > **Reporting** > **Payroll** and click on the MEASURES dropdown button, U can see the newly created salary rule. Try clicking on it. a DB error occurs. ### Investigation - When we create a new salary rule, we `_generate_payroll_report_fields()` https://github.com/odoo/enterprise/blob/b9adb690d7fd38c66a787377967a856b9678ffd1/hr_payroll/models/hr_salary_rule.py#L195 - Which `init()` the payroll report, creating a new DB view. However only the current company rules are fetched removing the other companies rules from the view as the old one is dropped https://github.com/odoo/enterprise/blob/b9adb690d7fd38c66a787377967a856b9678ffd1/hr_payroll/report/hr_payroll_report.py#L145 ### Discuss I think a better approach would be to construct a new view each time you open the payroll report, meaning to `init()` the report each time we go into https://github.com/odoo/enterprise/blob/b9adb690d7fd38c66a787377967a856b9678ffd1/hr_payroll/report/hr_payroll_report.py#L157-L165 but I think it's not a good idea to drop a view and create another each time also! opw-3675598 Forward-Port-Of: odoo/enterprise#55759 Forward-Port-Of: odoo/enterprise#55606
This fix corrects an error in the Bill of Materials cost report that was showing incorrect costs when products had multiple variants with different operations. The system was incorrectly matching operations to variants, resulting in wrong labor costs being displayed. The fix ensures that only the relevant operations for each variant are used when calculating costs.
Original PR description
Steps to reproduce: - Create a product with two variants A & B - Create a BoM for this product and create the following operations: - ope_A that applies only on variant A with a duration of 10 - ope_B that applies only on variant B with a duration of 30 - ope_common that applies to both with a duration of 60 - Set an employee cost (e.g. 100) on the chosen workcenter - Open the Overview of the created BoM Issue: The column 'BoM Cost' will be completely incorrect, as the `zip()` will try to associate all operations on the BoM (including operations that doesn't apply to the selected variant) with all operation lines generated for this variant (already filtered). This will end up trying to add the wrong duration costs to the wrong operation line on the report. Instead, we can simply compute the value once and override its computation in `mrp_workorder_hr` to include the employee costs. Forward-Port-Of: odoo/enterprise#55880 Forward-Port-Of: odoo/enterprise#55746
This update removes an outdated 'force_email' parameter that was no longer being used in system views. The change replaces it with a more reliable method to open partner forms, ensuring the system works correctly with recent updates to how context parameters are handled. This affects multiple modules across the platform including accounting, calendar, mail, and sales.
Original PR description
ba1a550 The above commit added some constraints on what can be used on the context of views. The key word 'force-email' is no longer relevant and will be removed from the context before reaching the next view/python code. This commit's purpose is to remove the force_email that were forgotten. In order to still open the simplified partner form view, the ref of the view is given in the context instead. While at it, we also fix the create option given on the partner_ids field that was inconsistent. affected version 17.0 - master task - 3538000 https://www.odoo.com/web#id=3538000&menu_id=4720&cids=1&action=333&active_id=4105&model=project.task&view_type=form 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
This fix corrects the misalignment of the "To Consume" column in Manufacturing Order reports. An unnecessary HTML element was causing the column header to not line up with its values. Users will now see properly aligned columns when printing production orders.
Original PR description
Steps to reproduce and current behavior: --- Go to Manufacturing > Operations > Manufacturing Orders Create a Manufacturing order with at least one line Actions (gear icon) > print > Production Order The column : "To Consume" is not aligned with the values. Cause of the issue: --- There is an html anchor with a t-else close that should not be there. Fix: --- This anchor is removed. opw-3692098 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
When confirming a sale order with multiple units of a serial-tracked product, the system now creates a separate repair order for each individual product instead of one repair order for all units. This prevents errors and provides a more logical workflow for managing repairs of serialized items.
Original PR description
**Current behavior:** Confirming a sale order containing an order line associated with >1 products which are tracked via serial number creates a single repair order. **Expected behavior:** A repair…
**Current behavior:**
Confirming a sale order containing an order line associated with >1 products which are tracked via serial number creates a single repair order.
**Expected behavior:**
A repair order for each individual product in the line is created.
**Steps to reproduce:**
0. Create a storable product which is tracked via serial number
and has create_repair set to True. Update on hand stock so
there are at least two available and assign them each a
serial number.
1. Make a new sale order with one order line for that product with the product_uom_quantity equal to the quantity created in step 0
2. Confirm the order and open the newly created repair order
3. Select a serial number for the repair order, start the repair, then end the repair to raise the exception
**Cause of the issue:**
Multiple products will be associated with one serial number. In stock_quant.py, the check_quantity() method checks the quantity of product_ids associated with a particular lot_id and location_id. In this instance, quantity will now be >1 which results in the ValidationError exception.
**Fix:**
Make a discrete repair order for each product in the order line when the product has serial tracking. This is more logical than asking a user to select one serial number for many products.
opw-3688072Users with analytic group permissions can now create analytic plans without requiring additional access rights. This fix removes an unnecessary permission barrier that was preventing authorized users from creating plans, making the permission system work as intended.
Original PR description
You should be able to create analytic plans with analytic group. But currently, you need Access Right's group. We should put a sudo there. 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
This fix allows attendees to scan their badges and check in before an event officially starts. Previously, the system would reject early arrivals with an error message. Now, attendees can scan badges anytime before the event ends, improving the check-in experience for events that start at a specific time.
Original PR description
Steps to Reproduce =================== 1. Create an event (e.g. starting at 9:00 AM) 2. People arrive early and attempt to scan a badge at 7:30 AM --> An error occurs: "Not part of an ongoing event" Technical Reason ================= -> Before this commit we were considering both date and time due to this is_ongoing was set as false. -> So to support early entrance we removed the old condition and added a new condition. After this PR ================= It will let you scan badges and verify attendees as long as the event is not finished. Task-3596660 X-original-commit: https://github.com/odoo-dev/enterprise/commit/3a2e4f123f1b3ff2eb1c444d14891eddd7e7ebac
The Stripe Express Checkout button was appearing truncated on the payment page because it was being constrained by the width of other buttons above it. This fix adds a minimum width to the button container to ensure the Stripe button displays properly across different screen sizes and languages. This improves the checkout experience for customers using Stripe's express payment option.
Original PR description
The express checkout button is handled by Stripe, so we have no control over it. Upon inspecting Stripe's code, it looks like the button simply fills the available width. The button just above Stripe's button ("Sign In"/"Process Checkout") sets the available width, so if it's narrower, Stripe's button gets truncated.
This PR sets a minimum width on the container around Stripe's button. This seems to work for different screen sizes and locales. The problem with this fix is that it could break if Stripe's button content gets wider. Unfortunately, since the button is displayed in an iframe, there's no better fix AFAIK.
opw-3430099
Forward-Port-Of: odoo/odoo#152244When sending emails through the messaging system, the system now captures and uses additional contact details (phone number, company name, contact name) when automatically creating new partner records, instead of only using the email address. This ensures that newly created contacts have complete information from the start, preventing the loss of important details that were entered in the original record.
Original PR description
Steps to reproduce:
- Install `crm` module (for test purpose)
- Create a new lead
- Set an email address, phone number, company name and contact name
- Save the lead
- In the chatter, send a mail (with the default recipient checked)
Issue:
- The partner has only the email address set (also set as name).
- The `contact name` on the lead is updated with the partner name
(who is the email address).
Cause:
When sending a mail with the default recipient checked, the partner
is created based only on the email address (therefore, name is same as
email), and when assigning the new partner on the lead, the
`contact name` is updated with the partner name (who is the email
address).
Solution:
Alter the route `/mail/partner/from_email` and `/mail/message/post`
so it can take or manage additional values for the creation of the
partner.
opw-3512045
Forward-Port-Of: odoo/odoo#152707
Forward-Port-Of: odoo/odoo#136967This fix corrects how digital signatures are generated for Spanish FacturaE invoices to comply with the FACe platform requirements. The signature digest algorithm has been changed from SHA256 to SHA1 for the Signature Policy Identifier field, which resolves validation failures when submitting invoices to the Spanish government's FACe platform.
Original PR description
The generated facturae files do not pass the FACe platform checks. The platform itself didn't give us any useful information. A feedback from the Spanish government said though: > We detected inconsistencies with the field `<ds:DigestValue>` from the tag `<xades: SignaturePolicyIdentifier>` Although not explicitly mentioned, we should apparently use SHA1 for the digest value of the Signature Policy instead of SHA256. opw-3673349 opw-3716276 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#152309
Google no longer supports sitemap submissions through their interface, as they now automatically crawl the /sitemap.xml file. This update removes the outdated submit sitemap button from website settings and displays an informational message to users, keeping the system aligned with current Google practices.
Original PR description
Google has removed the feature that allowed sitemap submissions. Now, it's standard practice for Google to crawl the /sitemap.xml. This commit permits to show an alert message when the user clicks on the button to submit a sitemap. task-3323849 Forward-Port-Of: odoo/odoo#152547 Forward-Port-Of: odoo/odoo#151972
This fix resolves an issue where nested checklists in the web editor weren't properly updating their direction when the parent checklist direction was changed. Previously, only the parent list content would change direction while nested checkboxes remained unaffected. Now both the parent and nested checklist directions update correctly together, ensuring consistent text direction throughout the entire checklist hierarchy.
Original PR description
**Before this commit:** When creating a nested checklist within another checklist and subsequently changing the direction of the parent list, the direction of the parent element would reverse alongside the pseudo element. However, in the case of nested checklists, only the content's direction would change, while the pseudo element's direction remained unaffected. **Afte this commit:** When altering the direction of the parent checklist's content, both the content itself and the associated pseudo element's direction is changed alongwith the nested checklist. **task-3461806** Forward-Port-Of: odoo/odoo#152486 Forward-Port-Of: odoo/odoo#131853
This update corrects the technical documentation in the Website Sales module to remove outdated references to a method that is no longer available. The change ensures that developers have accurate guidance when working with the sales variant functionality, preventing confusion and potential implementation errors.
Original PR description
As `this._rpc()` can not be used since [1], this commit removes the mention to this method in the documentation of the `_shouldIgnoreRpcResult` method. [1]: https://github.com/odoo/odoo/commit/7422eb643c5922bde8c70edfbe7b6f8dad53c1d9 Related to runbot-28700
This fix ensures that India-specific invoice template customizations are properly isolated and don't inadvertently affect invoice reports in other countries. The change makes the Indian invoice template primary within its localization module, preventing unintended side effects on global invoice processing.
Original PR description
Avoid specific changes of l10n_in invoice report to affect other countries. OPW-2504287 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#151408 Forward-Port-Of: odoo/odoo#151289
This fix resolves an issue where changing the operation type on a stock picking wasn't properly saving the name field. The update ensures that when users modify the picking type, all related data is correctly written to the system, preventing data loss or inconsistencies in warehouse operations.
Original PR description
pass name to write method when changing operation type on stock.picking 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
This update fixes how Spanish invoices handle retention taxes in the electronic invoicing system. Previously, retention taxes were incorrectly included in invoice totals, causing validation errors from tax authorities. Now these taxes are properly separated and declared in the correct XML section, ensuring invoices are accepted without errors.
Original PR description
Description of the issue/feature this PR addresses: Support out invoices with taxes of type "retención": - Do not take into account "retención" type taxes in the sum of the total price of the invoice lines, these taxes are of retention types and are declared in RetencionSoportada XML node. - Add amount_retention in invoice values and change template_invoice_factura to activate RetencionSoportada xml node. Current behavior before PR: Invoices with "retención" type taxes are not declared correctly, validation errors in the response of the tax agency. Desired behavior after PR is merged: Invoices with "retención" type taxes are declared correctly and accepted with no validation errors in the response of the tax agency. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#152302
This fix prevents the accounting reports from crashing when users accidentally enter an invalid domain formula. Previously, users would encounter a technical error when trying to view a report with an incorrectly formatted domain. Now the system handles these errors gracefully, providing a better user experience.
Original PR description
When user gives wrong domain in any account report of report line and tries to access the same report similar error is generated. Steps to Produce: - Install 'Accounting' - Go to Accounting >…
When user gives wrong domain in any account report of report line and tries to access the same report similar error is generated.
Steps to Produce:
- Install 'Accounting'
- Go to Accounting > Configuration > Accounting Reports
- Open any account report and click on add a line
- Now add a line in the report line
- Create an expression select 'Computation Engine' as Odoo Domain.
- In Formula add this domain [('code', '!=like', '620.%')]
- And add Sub-Formula as 'sum'
- Save the expression and also the report
- Go to Reporting and select the above report
Traceback will be generated
See similar traceback:-
```
ValueError: Invalid leaf ('code', '!=like', '620.%')
File "odoo/http.py", line 2123, in __call__
response = request._serve_db()
File "odoo/http.py", line 1699, in _serve_db
return service_model.retrying(self._serve_ir_http, self.env)
File "odoo/service/model.py", line 133, in retrying
result = func()
File "odoo/http.py", line 1726, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "odoo/http.py", line 1927, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
File "odoo/addons/base/models/ir_http.py", line 190, in _dispatch
result = endpoint(**request.params)
File "odoo/http.py", line 716, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "addons/web/controllers/dataset.py", line 30, in call_kw
return self._call_kw(model, method, args, kwargs)
File "addons/web/controllers/dataset.py", line 26, in _call_kw
return call_kw(request.env[model], method, args, kwargs)
File "odoo/api.py", line 461, in call_kw
result = _call_kw_multi(method, model, args, kwargs)
File "odoo/api.py", line 448, in _call_kw_multi
result = method(recs, *args, **kwargs)
File "home/odoo/src/enterprise/saas-16.3/account_reports/models/account_report.py", line 3713, in get_report_information
all_column_groups_expression_totals = self._compute_expression_totals_for_each_column_group(self.line_ids.expression_ids, options)
File "home/odoo/src/enterprise/saas-16.3/account_reports/models/account_report.py", line 2138, in _compute_expression_totals_for_each_column_group
current_group_expression_totals = self._compute_expression_totals_for_single_column_group(
File "home/odoo/src/enterprise/saas-16.3/account_reports/models/account_report.py", line 2266, in _compute_expression_totals_for_single_column_group
formula_results = self._compute_formula_batch(column_group_options, engine, date_scope, formulas_dict, current_groupby, next_groupby, offset=offset, limit=limit)
File "home/odoo/src/enterprise/saas-16.3/account_reports/models/account_report.py", line 2546, in _compute_formula_batch
return getattr(self, engine_function_name)(
File "home/odoo/src/enterprise/saas-16.3/account_reports/models/account_report.py", line 2662, in _compute_formula_batch_with_engine_domain
tables, where_clause, where_params = self._query_get(options, date_scope, domain=line_domain)
File "home/odoo/src/enterprise/saas-16.3/account_reports/models/account_analytic_report.py", line 173, in _query_get
tables, where_clause, where_params = super(AccountReport, context_self)._query_get(options, date_scope, domain)
File "home/odoo/src/enterprise/saas-16.3/account_reports/models/account_report.py", line 1469, in _query_get
query = self.env['account.move.line']._where_calc(domain)
File "home/odoo/src/enterprise/saas-16.3/account_reports/models/account_analytic_report.py", line 259, in _where_calc
query = super()._where_calc(domain, active_test)
File "odoo/models.py", line 4695, in _where_calc
return expression.expression(domain, self).query
File "odoo/osv/expression.py", line 777, in __init__
self.parse()
File "odoo/osv/expression.py", line 1083, in parse
push(leaf, comodel, coalias)
File "odoo/osv/expression.py", line 931, in push
check_leaf(leaf, internal)
File "odoo/osv/expression.py", line 726, in check_leaf
raise ValueError("Invalid leaf %s" % str(element))
```
ValueError: Invalid leaf ('code', '!=like', '620.%')
When user applies invalid values in domain or invalid domain format it leads to the traceback because of this line:
https://github.com/odoo/enterprise/blob/16.0/account_reports/models/account_report.py#L1510
sentry-4358342635,4909338331
Forward-Port-Of: odoo/odoo#151744
Forward-Port-Of: odoo/odoo#130981This fix corrects an error in the Bill of Materials (BoM) cost overview report that was showing incorrect costs when products have multiple variants with different operations. The issue occurred because the system was incorrectly matching operations to variants. The fix simplifies the cost calculation and allows for proper customization of operation costs including employee labor expenses.
Original PR description
Steps to reproduce: - Create a product with two variants A & B - Create a BoM for this product and create the following operations: - ope_A that applies only on variant A with a duration of 10 -…
Steps to reproduce: - Create a product with two variants A & B - Create a BoM for this product and create the following operations: - ope_A that applies only on variant A with a duration of 10 - ope_B that applies only on variant B with a duration of 30 - ope_common that applies to both with a duration of 60 - Set an employee cost (e.g. 100) on the chosen workcenter - Open the Overview of the created BoM Issue: The column 'BoM Cost' will be completely incorrect, as the `zip()` will try to associate all operations on the BoM (including operations that doesn't apply to the selected variant) with all operation lines generated for this variant (already filtered). This will end up trying to add the wrong duration costs to the wrong operation line on the report. Instead, we can simply compute the value once and override its computation in `mrp_workorder_hr` to include the employee costs. Community part to allow the override for odoo/enterprise#55746 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#152758 Forward-Port-Of: odoo/odoo#152468
This update fixes the XML comparison testing tool used in the accounting module to properly validate XML namespaces in addition to the tree structure. This ensures that XML documents are tested more thoroughly and accurately, reducing the risk of undetected issues in accounting-related data processing.
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
This fix resolves an issue where product names and other data containing certain special characters would cause XML-RPC requests to fail. The system now automatically removes invalid control characters from data before sending it through XML-RPC, ensuring clients can successfully retrieve product information and other data without parsing errors.
Original PR description
According to https://docs.python.org/3.7/library/xmlrpc.client.html > When passing strings, characters special to XML such as <, >, and & will be automatically escaped. However, it’s the caller’s…
According to https://docs.python.org/3.7/library/xmlrpc.client.html > When passing strings, characters special to XML such as <, >, and & will be automatically escaped. However, it’s the caller’s responsibility to ensure that the string is free of characters that aren’t allowed in XML, such as the control characters with ASCII values between 0 and 31 (except, of course, tab, newline and carriage return); failing to do this will result in an XML-RPC request that isn’t well-formed XML. **steps to reproduce:** - create a product with an ASCII control character in its name (ex: \x03) - read the product name using XMLRPC **before this commit:** - client can't parse the response, an error is raised `xml.parsers.expat.ExpatError: not well-formed (invalid token) ` **after this commit:** - we make sure the string is free of those characters opw-3617458 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#152942 Forward-Port-Of: odoo/odoo#145577
This update fixes two issues in the SelectMenu component that affect how dropdown menus display and function. The first fix corrects styling problems where menu items were showing incorrect cursor behavior and colors. The second fix ensures that when users clear their search, the menu properly refreshes to show the correct items instead of displaying outdated results from a previous search.
Original PR description
[FIX] web: SelectMenu issues The 1st commit fixes the style applied to the o_select_menu_sticky elements. Since the fix from commit (1), the text cursor is shown when hovering those elements. This…
[FIX] web: SelectMenu issues The 1st commit fixes the style applied to the o_select_menu_sticky elements. Since the fix from commit (1), the text cursor is shown when hovering those elements. This was without considering the fact that this class is mainly used to display elements on top of other elements of the component. This includes usages with the bottomArea slot, that can be used with a DropdownItem. Because of the changes from the commit previously named, the focused color was no longer applied, and it was showing the wrong cursor when hovering. The 2nd commit fixes an issue caused by the way we use onInput props in Knowledge to fetch articles depending the current search value. Since we start from an empty string in the input again, it make no sense to display the choices previously fetched with a search value no longer displayed in the UI. The only way to display the correct items is to update the input value, then put an empty search to fetch accordingly. This is clearly an issue, when the onInput props is used to fetch the content of the SelectMenu, depending of the search value. The UI obviously display an empty search, and filter accordingly, but without having called the fetching of the items corresponding to the empty search value. A test was added as well to assert SelectMenu can be used for this purpose without forgetting to call onInput again when clearing the search value. Forward-Port-Of: odoo/odoo#152820
This fix resolves an issue that prevented employees from creating new time off requests in the management view when no default leave type was configured. The update ensures the system properly handles situations where a default leave type is not defined, allowing the time off creation process to work smoothly for all users.
Original PR description
After the commit added by odoo/odoo#152513, it was not possible anymore to create a new time off from the management view in situation where the default leave type wouldn't be defined. This commit adds a falsy value so that the variable exists even if no default leave type is set.
This fix resolves a bug where product quantities were incorrectly increased by 1 when users clicked the edit option in a product dropdown menu. The issue occurred because the system was updating quantities on any click within the product box. Now the system properly detects when clicks happen in the dropdown menu and prevents the unwanted quantity update, ensuring product data remains accurate.
Original PR description
**Steps to reproduce:** 1- Install Field Service module 2- Create new task and click on products smart button 3- Hover over a product and click on the dropdown menu 4- Click on edit in the dropdown menu 5- Get back to the products page and check the quantity for the product you edited **Current behavior before PR:** When the user clicks on edit in the dropdown menu of any product the quantity gets increased by 1. This is happening because of the global click event so when the user clicks anywhere inside the kanban box the quantity gets updated. **Desired behavior after PR is merged:** This behavior has been adjusted by checking the target where the user click if it is inside the dropdown menu it will not update the product's quantity. opw-3689864 Check https://github.com/odoo/enterprise/pull/54645
This fix prevents the system from unnecessarily starting websocket connections when temporary chat threads are added to the mail system. Previously, the system would incorrectly attempt to start a websocket worker for these temporary threads, which are not yet fully created and don't have complete member information. This resolves an inefficiency that was introduced in a recent update.
Original PR description
Since [1], the websocket worker is started when a transient thread is added to the mail store. This occurs because this PR introduced a call to the `addChannel` method of the bus service when the current user was not member of the thread. Since transient threads are not yet created, they have a partial state that does not necessarily include channel members hence the impression that the current user is not member of the channel. This PR prevent starting the bus service for transient threads. [1]: https://github.com/odoo/odoo/pull/146800
This fix resolves an issue where GST (Goods and Services Tax) treatment was incorrectly being set to False on posted invoices when a partner's GST treatment was changed. The fix ensures that GST treatment information is properly maintained on invoices that have already been posted, preventing data loss during partner updates.
Original PR description
Before this commit: After commit f7147b36da0b3963e5bafb09cb585f130dcbfcf0 on changing partner gst treatment, it makes GST treatment on posted invoice False After this commit: It resolves the issue due to commit f7147b36da0b3963e5bafb09cb585f130dcbfcf0 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
This fix resolves an issue where customer satisfaction survey emails for tasks were missing the company name in the subject line when a project had no company assigned. The email template now uses the current user's company as a fallback, ensuring the subject line displays properly in all cases.
Original PR description
Steps: - Install project module - Activate customer rating from settings - Create new project without company - Add stages, then in final stage set in rating email template to 'Project: Task Rating Request' - Create a task and add the customer, move the task to that final stage then - Check the emails in settings, the subject line is look like ': Satisfaction Survey'. Issue: - When there is no company set on the project, on that time company name is missing in subject line. Cause: - In task satisfaction survey email template only set the company name based on the project only. Fix: - By adding the current user's company name to the template subject line, the problem will be solved. task-3626702 Forward-Port-Of: odoo/odoo#146260