Daily updates from Odoo
Tuesday, January 21, 2025
53 changes · 18.0
Enhancements to existing features
This update makes internal device-tracking logic return a clear success signal when a new device record is created. It helps future customizations detect new devices more simply and reliably, with no direct change for everyday users.
Original PR description
In case you want to inherit _update_device, and want to know whether or not a device was made, you need to first get the latest id, then call super(), and then compare the latest id with the previous value. This can simply be fixed by returning True and checking the return value. Meant to simplify https://github.com/odoo/internal/pull/3299
The self-ordering point of sale no longer loads product images as part of the initial POS data because those images are already loaded separately. This reduces unnecessary memory consumption and helps prevent memory errors in larger or image-heavy setups.
Original PR description
Before this commit, product images were unnecessarily loaded along with the POS data. This was redundant since the images are loaded separately. Additionally, loading the images caused excessive memory usage, leading to memory errors in certain scenarios. opw-4494712 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The update improves the wording and visibility of Peppol and BIS3 warnings in invoice Print & Send flows, making it easier for users to understand what needs attention before sending electronic invoices. It also makes the Peppol information prompt more prominent and directs unregistered companies to the registration wizard when they choose to activate Peppol.
Original PR description
- Improvements of message of Peppol/BIS3 related warnings of the Print & Send wizards. - Wording improvements for clarity. - Make the "What is Peppol" modal more present. Change its flow: the "activate" buttons now leads to the Peppol registration wizard if the company is not registered yet. task-4478365
Barcode and RFID scans now load stock quantity information in batches instead of one item at a time. This reduces delays and network calls when processing many serial numbers, improving performance for large warehouse operations or slower mobile connections.
Original PR description
In quant_barcode_model we fetch the quant at the new line creation. It's use in order to define the current theorical inventory quantity. But with rfid, it could be heavy since each serial number can be a new line and doing an rpc by line will be a bottleneck. To improve it, each time we add a product in the cache, we also add the associated quants. During the new line creation, we search for the product in the cache rather than doing an rpc with a specific domain
Resolved issues and error corrections
Some accounting screens showed an empty label for journal entries, which could prevent users from opening the related entry. This fix ensures the entry name placeholder appears consistently so accounting users can navigate to the right record without disruption.
Original PR description
The placeholder was empty in some places, leading to an annoying behavior because it isn't even possible anymore to open the related journal entry. The fix is done directly in the widget `open_move_widget` to avoid modifying the definition of the related field and having to change it into a computed field. Also, it wouldn't make sense to store the placeholder on the journal item but not on the journal entry.
Control panel buttons now display with consistent widths on smaller screens, improving visual alignment and usability. The view switcher also uses less space by hiding its caret on small screens, making the mobile interface cleaner.
Original PR description
On smaller screen, the ControlPanel's buttons for CogMenu, Buttonbox, Knowledge, Search don't have a consistent width. This commit fixes it by giving those buttons' icon a fixed width, independently of the character's size and adjusting the horizontal padding for this use case. task-4492690
This fix prevents email notifications from failing when no sender or author is attached. It helps ensure notification emails are generated reliably instead of crashing in uncommon cases.
Original PR description
There are instances where an email notification may not have an associated author. In the mail notification template, we forgot to check that the author exists before calling the `_is_internal` on it. When the author is `False`, the function generating the mail crashes as the `_is_internal` function is undefined on a boolean variable. To address this issue, we will ensure the existence of the author before invoking any methods defined in the `res.users` model. This solution prevents errors and ensures the email template functions correctly. see: #190390 Task-4128966 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Point of Sale preparation receipts now correctly show product variants that are configured to be created automatically. This helps kitchen or preparation staff see the exact item ordered and reduces fulfillment mistakes.
Original PR description
Product variant with creation type "always" would not be printer on the preparation receipt. Steps to reproduce: ------------------- * Create a product and add a variant with creation type "always" * Add a preparation printer to the point of sale * Create a new order and add the product with the variant * Validate the order and check the preparation receipt > Observation: the product variant is not printed on the receipt Why the fix: ------------ The product variant was not printed on the preparation receipt because the variant is added to the display name of the product and doesn't appear in the attribute list. This fix also add the first test for the preparation receipt. This should be improved in the future to cover more cases. opw-4450217
Manufacturing orders now correctly include and consume components that are added after the order has already been confirmed. This helps ensure production records, material usage, and inventory levels stay accurate throughout the manufacturing process.
Original PR description
With this PR : ------------------------------------------ - Addressed an issue where components added after MO confirmation were not being automatically consumed during production. - Implemented checks and updates in function to ensure all components are marked as picked before production. - This fix ensures that all components, including those added after MO confirmation, are properly accounted for and consumed during the production process. Task-id : 3951176
Partner address fields used for Peppol-related electronic invoicing are now always shown, including for OIOUBL documents that reuse those fields. This makes the information easier to find and update when preparing or maintaining electronic invoice details.
Original PR description
OIOUBL (which is not a Peppol format) uses the fields from peppol. So it should be visible to be edited too. Even more, we will make it always visible, as the Peppol may be proposed more, and so, the fields should be more easily modifiable. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an issue that prevented users from deleting selected attendance records from the list view. The attendance list now handles missing filter information safely, so the delete action completes as expected.
Original PR description
An error is thrown when deleting attendance records from the list view. Steps to reproduce: Attendances -> List View (Select some records) -> Actions -> Delete Current behavior before PR: ```…
An error is thrown when deleting attendance records from the list view.
Steps to reproduce:
Attendances -> List View (Select some records) -> Actions -> Delete
Current behavior before PR:
```
TypeError: Cannot read properties of undefined (reading 'some')
at Proxy.load (https://72301827-18-0-all.runbot171.odoo.com/web/assets/debug/web.assets_web.js:229101:49) (/hr_attendance/static/src/views/attendance_list_view.js:25)
at Proxy._deleteRecords (https://72301827-18-0-all.runbot171.odoo.com/web/assets/debug/web.assets_web.js:55859:26) (/web/static/src/model/relational_model/dynamic_list.js:250)
at async ConfirmationDialog.execButton (https://72301827-18-0-all.runbot171.odoo.com/web/assets/debug/web.assets_web.js:18747:31) (/web/static/src/core/confirmation_dialog/confirmation_dialog.js:79)
```
Desired behavior after PR is merged:
Deleting selected records without errors.
Cause:
The implementation of `DynamicList._deleteRecords` changed in v18.0 by fbb37ab363a6c729193f1ba1ba70775650140636 to call `model.load()` without `params`. Thus `params.domain` could possibly be undefined.
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis fixes OAuth sign-in for new users on environments using newer software dependencies. Users will no longer see a misleading setup error, and authentication with external providers should work as expected.
Original PR description
Description of the issue/feature this PR addresses: The method `werkzeug.http.parse_www_authenticate_header` has been removed in werkzeug 3 and later. This causes an issue in Odoo when using python…
Description of the issue/feature this PR addresses: The method `werkzeug.http.parse_www_authenticate_header` has been removed in werkzeug 3 and later. This causes an issue in Odoo when using python 3.12, as the `requirements.txt` specifies werkzeug 3.0.1. This results in a misleading error stating that `auth_signup` is not installed on the database when authenticating a new user with an OAuth provider. Current behavior before PR: When attempting to authenticate a new user with an OAuth provider in Odoo using Python 3.12, the method werkzeug.http.parse_www_authenticate_header is called. Since this method is removed in Werkzeug 3.0.1, a misleading error message about auth_signup not being installed on the database is displayed. Desired behavior after PR is merged: The code will use WWWAuthenticate.from_header for parsing the WWW-Authenticate header if available, otherwise, it will fall back to using werkzeug.http.parse_www_authenticate_header for compatibility with older versions of Werkzeug (2.0 and 2.2). The misleading error message will no longer appear, and OAuth authentication will work as expected. Fixes #194002 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix prevents an error that occurred after saving an image carousel on eLearning website pages. Carousel images and navigation buttons remain visible, helping editors publish course pages without broken galleries.
Original PR description
The image do not have the thumbails anymore 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 prevents account searches from using an internal-only account structure that supports only limited lookup behavior. Users are redirected to equivalent account fields, reducing errors while preserving the same search intent.
Original PR description
account.root is a technical model only meant to be used in the side panel and therefore only has a limited ORM functionality. Trying to search on anything else than the ID is not allowed, and rather useless since a domain on `root_id` and be replaced with a domain on the account (or it's display_name) directly.
Instead of:
* `[('root_id', 'ilike', prefix)]`, use `[('display_name', 'ilike', prefix)]`
* `[('account_id.root_id', 'ilike', prefix)]`, use `[('account_id', 'ilike', prefix)]`
This commit simply redirects the user to the alternate field.Refunded point-of-sale orders now send only positive amount values to Kenya's eTIMS tax system, as required. This prevents refund transactions from being rejected or reported incorrectly because of negative values.
Original PR description
When sending pos_order to eTims, all numeric values must be positive values, but when computing refunded pos_order, some fields are computed with negative value. This commit manage to transform negative fields from refunded pos_order to positive field. no-task
Control panel buttons now keep a consistent width on smaller screens across Knowledge and account reports. This improves visual alignment and makes the interface feel more polished and easier to use on compact displays.
Original PR description
*: account_reports On smaller screen, the ControlPanel's buttons for CogMenu, Buttonbox, Knowledge, Search don't have a consistent width. This commit fixes it by giving those buttons' icon a fixed width, independently of the character's size and adjusting the horizontal padding for this use case. task-4492690
Subscription project dashboards now show only billable order lines, excluding section and note entries. This prevents non-billable informational lines from being counted or displayed where users expect actual subscription items.
Original PR description
Steps to reproduce: --- 1) Go to a Subscription with a Project 2) Add a section and/or note line 3) Navigate Project smart button -> Dashboards -> Subscription dropdown 4) Notice the order lines Issue: ---- In the subscription the sections and notes are taken into account this is due to the fact that all the line are retrieved and not only the "billable". Fix: --- Adding a condition on the display type of the line. opw-4394767
The Indian payroll salary register now automatically sets its end date to the last day of the current month instead of today's date. This reduces manual correction and helps payroll users create monthly reports with the expected date range.
Original PR description
steps to reproduce: -Go to an indian company -Open the payroll application. -try to create salary register -the end date is current date issue: The end date should be set to the last day of the current month. solution: changed the code for '_get_default_date_to' to set default date to the last day of the current month task-4432414
This update fixes an issue that could prevent scheduled Monster.com job board campaigns from starting correctly. It also adds regression tests to help ensure the Monster recruitment integration and its shared base logic keep working as expected in future updates.
Original PR description
This PR adds non regression tests for the integration of monster in hr_recruitment. These tests also cover at the same time the code of the hr_recruitment_integration_base module. The PR also fixes a bug in the hr_recruitment_integration_base module which was found thanks to the tests. The bugfix is about fixing variable names in the _start_new_campaign to match the fields of the module. task-4199469
The tax report now clearly shows the correct default date option when a tax period matches a monthly, quarterly, or yearly reporting period. This removes a confusing state where the report used the right dates but showed no selected date filter in the dropdown.
Original PR description
This commit makes sure that, in tax report, when tax_period is used to determine the report date, and when the tax_period periodicity matches one of the 3 standard filters (month, quarter, or year), that the correponding standard filter is selected with the right date set on it. Before this commit, the default date filter of the tax report would make use of the tax_period to set its date. The date was set properly, but the tax_period date filter would be hidden in case the periodicity matches monthly, quarterly, or annually. When its hidden, the date filter dropdown menu would show 3 standard filters with none of them selected, which was confusing. task-4373943
This fix restores safer handling of responses from Ecuador's tax authority when users click "Process Now" for electronic invoices. It prevents failed transactions from losing submitted invoice data and tax authority responses, helping affected invoices recover their official status without a manual data fix.
Original PR description
This reverts commit 6d00d4da05af71f17139cdb5a3a25ae9e0c10afb That commit was causing an exception in the code handling the response from the API call to the Ecuadorian Tax Agency (SRI), causing a transaction rollback and the loss of the information sent to the SRI as well as the SRI's response. Users with affected invoices need to take care to not reset the invoices to draft. After this fix is merged, the API handling code will be able to recover the invoice status from the SRI, so no data-fix should in principle be needed. task-none
The map view for contacts now displays the correct group name when records are grouped by related fields such as country. This prevents groups from appearing as "None," making the map sidebar clearer and easier to use.
Original PR description
Before this commit, for map views on res.partner (which have attribute res_partner = id), if the user group by a relational field (X2many, many2one), the name of the group is "None" ### Steps to reproduce: - Contacts > Map view - in the search bar, group by "Country" - On the left side of the map view, the group name is "None" #### Expected - Name of partner country should be visible instead of "None"
Miscellaneous changes
Since chrome 132, the shape of error events for the `ResizeObserver loop completed with undelivered notifications.` error changed: the `error` key is now set in the event (its value is this specific message, i.e. a string, not an Error instance). As a consequence, those errors are no longer swallowed as they're expected to be, and are thus wrongly identified as CORS errors. Those errors are shown to the user in debug mode. This happens for instance in the ir.ui.view form view, which contains
Original PR description
Since chrome 132, the shape of error events for the `ResizeObserver loop completed with undelivered notifications.` error changed: the `error` key is now set in the event (its value is this specific…
Since chrome 132, the shape of error events for the `ResizeObserver loop completed with undelivered notifications.` error changed: the `error` key is now set in the event (its value is this specific message, i.e. a string, not an Error instance). As a consequence, those errors are no longer swallowed as they're expected to be, and are thus wrongly identified as CORS errors. Those errors are shown to the user in debug mode. This happens for instance in the ir.ui.view form view, which contains an AceEditor field. His CodeEditor component listens on the `resize` event to redrawn itself, which causes this error. This also happens with the website builder, which does not involve the CodeEditor. It probably happens at other places as well. We thus need a global solution, like we had before. This commit thus fixes the condition in the error service to keep swallowing that error. opw-4500350 opw-4496862 opw-4496782 opw-4495448 opw-4493209 opw-4495309 opw-4472997 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#194483
# Description The 'See Records' icon was missing when attempting to open `AccountMoveLines` records from the context menu in the spreadsheet. Task: 0 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#194464
Original PR description
# Description The 'See Records' icon was missing when attempting to open `AccountMoveLines` records from the context menu in the spreadsheet. Task: 0 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#194464
add missing translated terms that have been omitted in https://github.com/odoo/odoo/pull/188819
Original PR description
add missing translated terms that have been omitted in https://github.com/odoo/odoo/pull/188819
Before this commit, the base.automation form view displays the filter_domain field when on_change trigger type is selected but the code does not take into account the filter_domain value for this type of trigger. After this commit, this field is simply hidden in that case. Task: opw-4492554 Forward-Port-Of: odoo/odoo#194424 Forward-Port-Of: odoo/odoo#194158
Original PR description
Before this commit, the base.automation form view displays the filter_domain field when on_change trigger type is selected but the code does not take into account the filter_domain value for this type of trigger. After this commit, this field is simply hidden in that case. Task: opw-4492554 Forward-Port-Of: odoo/odoo#194424 Forward-Port-Of: odoo/odoo#194158
Steps to reproduce: --- Go in the Time Off app Click on an allocation or a leave Click on the action gear Issue: --- The gear action shows 2 times the "Multiple Requests", this comes from the fact that the wizard is in the xml and defined in the action_generate_allocations. So it is displayed twice in the form. Fix: --- Since the issue is only appearing in the form view, added the condition on viewType. --- I confirm I have signed the CLA and read the PR guidelines at www.od
Original PR description
Steps to reproduce: --- Go in the Time Off app Click on an allocation or a leave Click on the action gear Issue: --- The gear action shows 2 times the "Multiple Requests", this comes from the fact that the wizard is in the xml and defined in the action_generate_allocations. So it is displayed twice in the form. Fix: --- Since the issue is only appearing in the form view, added the condition on viewType. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#188182
Fixes an issue on the partner view where a compute would try to read the proxy user, while not all users who can read the partner would have read access to the proxy user. Also fix a similar case in the action used to validate the ID, which tries to read the proxy user. error-105104 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#194459
Original PR description
Fixes an issue on the partner view where a compute would try to read the proxy user, while not all users who can read the partner would have read access to the proxy user. Also fix a similar case in the action used to validate the ID, which tries to read the proxy user. error-105104 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#194459
In the onboarding wizard, we create a cash journal for different scenarios. However the names of these journals were not translatable. We make them translatable in this commit. Forward-Port-Of: odoo/odoo#194337
Original PR description
In the onboarding wizard, we create a cash journal for different scenarios. However the names of these journals were not translatable. We make them translatable in this commit. Forward-Port-Of: odoo/odoo#194337
- fix the `hr_leave_allocation_rule_employee_update` rule to include `('manager','both') in validation_type` instead of `hr` as those are the types where the emoployee's manager should be able to update - fix `_check_approval_update` function to match the designed access rules where TOO only approve `hr` and validate `both` and manager approvre `manager, both` Task: 4432503 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo
Original PR description
- fix the `hr_leave_allocation_rule_employee_update` rule to include `('manager','both') in validation_type` instead of `hr` as those are the types where the emoployee's manager should be able to update
- fix `_check_approval_update` function to match the designed access rules where TOO only approve `hr` and validate `both` and manager approvre `manager, both`
Task: 4432503
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#191808It's not *entirely* clear which and when, but some tours apparently trigger downloads, which by default will make a mess of the user's Downloads folder when running tests locally. This has mostly been observed in 18.0 / master with Studio exports but there are a few others as well (e.g. a few reports). Either way, seems like a good idea to just configure chrome to block them. Forward-Port-Of: odoo/odoo#194393
Original PR description
It's not *entirely* clear which and when, but some tours apparently trigger downloads, which by default will make a mess of the user's Downloads folder when running tests locally. This has mostly been observed in 18.0 / master with Studio exports but there are a few others as well (e.g. a few reports). Either way, seems like a good idea to just configure chrome to block them. Forward-Port-Of: odoo/odoo#194393
Before this commit, the module_loader was showing error by empty the DOM and then adding his element with the errors. The issue is, if you have an error because of custom script or after an upgrade, then you were lockout because the DOM with empty and you cannot go fix the script. After this commit, a shorter message will be shown in the bottom-left of the screen. This message will invite the user to check the devtool to have more details about the error. --- I confirm I have signed the
Original PR description
Before this commit, the module_loader was showing error by empty the DOM and then adding his element with the errors. The issue is, if you have an error because of custom script or after an upgrade, then you were lockout because the DOM with empty and you cannot go fix the script. After this commit, a shorter message will be shown in the bottom-left of the screen. This message will invite the user to check the devtool to have more details about the error. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#194342 Forward-Port-Of: odoo/odoo#193912
When creating a new working schedule, the duration (days) was not computed correctly. This was due to a missing field in the depends of the compute method. This commits fixes the issue by adding the hours per day in the depens of the duration days compute method. That way, the duration days will be computed after that the hours per day are computed. task-4457200 Forward-Port-Of: odoo/odoo#193715
Original PR description
When creating a new working schedule, the duration (days) was not computed correctly. This was due to a missing field in the depends of the compute method. This commits fixes the issue by adding the hours per day in the depens of the duration days compute method. That way, the duration days will be computed after that the hours per day are computed. task-4457200 Forward-Port-Of: odoo/odoo#193715
**Before this PR:** Steps to reproduce: - In an empty paragraph write something, press shift + enter - Write something in new line break - Select whole text in second line - Paste any text, notice that an extra <br> is added above pasted text. In other words, `<p>abc<br>[def]</p> + insert('x')` becomes `<p>abc<br><br>x[]</p>` instead of `<p>abc<br>x[]</p> `. **Desired behaviour after PR:** Now, pasting something at line-break doesn't add an extra an extra `<br>` . task-4231
Original PR description
**Before this PR:**
Steps to reproduce:
- In an empty paragraph write something, press shift + enter
- Write something in new line break
- Select whole text in second line
- Paste any text, notice that an extra <br> is added above pasted text.
In other words,
`<p>abc<br>[def]</p> + insert('x')` becomes `<p>abc<br><br>x[]</p>` instead of `<p>abc<br>x[]</p> `.
**Desired behaviour after PR:**
Now, pasting something at line-break doesn't add an extra an extra `<br>` .
task-4231290
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#185854When using an auto fifo product as part of the repair, the COGS won't be based on the used product To reproduce the issue: 1. Setup auto fifo product 2. Receive 1@10 and 1@20 3. Process a RO: - Invoice method: After repair - Parts: - Add 1 x fifo product 4. Create and post the invoice 5. Open its journal items Error: Cogs are $20 instead of $10 When posting the invoice, we generate the COGS: https://github.com/odoo/odoo/blob/4df156164cf1d2764ba23682beee588777457fd6/
Original PR description
When using an auto fifo product as part of the repair, the COGS won't be based on the used product To reproduce the issue: 1. Setup auto fifo product 2. Receive 1@10 and 1@20 3. Process a RO: -…
When using an auto fifo product as part of the repair, the COGS
won't be based on the used product
To reproduce the issue:
1. Setup auto fifo product
2. Receive 1@10 and 1@20
3. Process a RO:
- Invoice method: After repair
- Parts:
- Add 1 x fifo product
4. Create and post the invoice
5. Open its journal items
Error: Cogs are $20 instead of $10
When posting the invoice, we generate the COGS:
https://github.com/odoo/odoo/blob/4df156164cf1d2764ba23682beee588777457fd6/addons/stock_account/models/account_move.py#L47-L48
We therefore compute the "anglo saxon unit price":
https://github.com/odoo/odoo/blob/4df156164cf1d2764ba23682beee588777457fd6/addons/stock_account/models/account_move.py#L133
However, there isn't any override to handle the RO case, so it leads
to the default mechanism, i.e. the standard price of the product:
https://github.com/odoo/odoo/blob/4df156164cf1d2764ba23682beee588777457fd6/addons/stock_account/models/account_move.py#L294-L295
https://github.com/odoo/odoo/blob/4df156164cf1d2764ba23682beee588777457fd6/addons/stock_account/models/account_move.py#L294-L295
https://github.com/odoo/odoo/blob/7cd7563f6708331bb6baf0e06d07a9f9ee329e38/addons/stock_account/models/product.py#L753-L757
And, since the first product is out, its standard price is now based
on the next candidate: $20
About the `sudo`: an accountman has not any access to `repair`, so
posting such an invoice would raise an error. Since this diff is
specific to Odoo 16, the idea is not to impact any security rules
and rather minimize the changes.
Note: Indeed, `repair` does not depend on `stock_account`, so this
commit could lead to a traceback if the bridge is removed. I delegate
this issue to the error of dependencies. Anyway, removing the bridge
would lead to other bugs. Hopefully, this has been fixed on master [1].
[1] https://github.com/odoo/odoo/commit/f7dbdec11b74f8c7d969763d8c5cf09542a47f86
OPW-4166570
Forward-Port-Of: odoo/odoo#193826
Forward-Port-Of: odoo/odoo#193076Description 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#193752
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 Forward-Port-Of: odoo/odoo#193752
`accounting_supplier_party` was never sent right from IAP, it was always 'None'. So, we could never log it. But the information was in fact always useless. This information is already in the UBL file. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#193462 Forward-Port-Of: odoo/odoo#192740
Original PR description
`accounting_supplier_party` was never sent right from IAP, it was always 'None'. So, we could never log it. But the information was in fact always useless. This information is already in the UBL file. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#193462 Forward-Port-Of: odoo/odoo#192740
Before this commit PoS orders synchronisation can sometime happen in parallel. When it is the case, we can end up with situation of duplicated PoS orders stored in the backend. This can also be useful to cases where "there is a receipt for the order XXX-YYY-ZZZ, but it does not appear in the backend!" After this commit: To ease the investigation of such cases, logs are added with various information to better understand customer flows and tracability when a PoS order is synced. The main
Original PR description
Before this commit PoS orders synchronisation can sometime happen in parallel. When it is the case, we can end up with situation of duplicated PoS orders stored in the backend. This can also be…
Before this commit
PoS orders synchronisation can sometime happen in parallel. When it is the case, we can end up with situation of duplicated PoS orders stored in the backend. This can also be useful to cases where "there is a receipt for the order XXX-YYY-ZZZ, but it does not appear in the backend!"
After this commit:
To ease the investigation of such cases, logs are added with various information to better understand customer flows and tracability when a PoS order is synced.
The main idea was added to the "PoS order" capture PR: https://github.com/odoo/odoo/pull/174562
But this one is waiting for other PR to be deployed due to the heavy PoS refactoring in 17.4. In the mean time, the logs part can be easily pushed in 17.4
Logs example:
New PoS order logs:
```
2024-12-16 16:55:32,254 49677 INFO oes_17.4_pos odoo.addons.point_of_sale.models.pos_order: PoS synchronisation #89627943 started for PoS orders references: [{'name': 'Order 00007-003-0001', 'uuid': '838043cb-8324-4b52-a45e-c8707f8975ff'}]
2024-12-16 16:55:32,413 49677 INFO oes_17.4_pos odoo.addons.point_of_sale.models.pos_order: PoS synchronisation #89627943 order {'name': 'Order 00007-003-0001', 'uuid': '838043cb-8324-4b52-a45e-c8707f8975ff'} created pos.order #38
2024-12-16 16:55:32,414 49677 INFO oes_17.4_pos odoo.addons.point_of_sale.models.pos_order: PoS synchronisation #89627943 finished
2024-12-16 16:55:32,434 49677 INFO oes_17.4_pos werkzeug: 127.0.0.1 - - [16/Dec/2024 16:55:32] "POST /web/dataset/call_kw/pos.order/sync_from_ui HTTP/1.1" 200 - 90 0.070 0.114
```
Updated PoS restaurant order:
```
2024-12-16 16:36:27,190 43869 INFO oes_17.4_pos odoo.addons.point_of_sale.models.pos_order: PoS synchronisation #99444056 started for PoS orders references: [{'name': 'Restaurant/00004', 'uuid': '9653201c-1c04-4679-99b8-61d2ae91fc87'}]
2024-12-16 16:36:27,331 43869 INFO oes_17.4_pos odoo.addons.point_of_sale.models.pos_order: PoS synchronisation #99444056 order {'name': 'Restaurant/00004', 'uuid': '9653201c-1c04-4679-99b8-61d2ae91fc87'} updated pos.order #12
2024-12-16 16:36:27,331 43869 INFO oes_17.4_pos odoo.addons.point_of_sale.models.pos_order: PoS synchronisation #99444056 finished
2024-12-16 16:36:27,348 43869 INFO oes_17.4_pos werkzeug: 127.0.0.1 - - [16/Dec/2024 16:36:27] "POST /web/dataset/call_kw/pos.order/sync_from_ui HTTP/1.1" 200 - 101 0.059 0.425
```
opw-3650239
Forward-Port-Of: odoo/odoo#190734Versions -------- - 16.0+ Steps ----- 1. Have a user with only access to "Sales User: Own Documents Only"; 2. open a product variant page; 3. add a comment in the chatter. Issue ----- Access Error Cause ----- Commit 35a07975deb0 added `_mail_post_access = 'read'` to the `product.template` model. This allows users with read-only access to still comment on `product.template` records. This was not done for product variants, leading to an inconsistency where an internal user ca
Original PR description
Versions -------- - 16.0+ Steps ----- 1. Have a user with only access to "Sales User: Own Documents Only"; 2. open a product variant page; 3. add a comment in the chatter. Issue ----- Access Error Cause ----- Commit 35a07975deb0 added `_mail_post_access = 'read'` to the `product.template` model. This allows users with read-only access to still comment on `product.template` records. This was not done for product variants, leading to an inconsistency where an internal user can comment on product templates, but not variants. Solution -------- Add `_mail_post_access = 'read'` to `product.product` as well. opw-4189326 Forward-Port-Of: odoo/odoo#194048 Forward-Port-Of: odoo/odoo#194005
When an error occurs on IAP side for Peppol we display the content of `message` while we have a more friendly-user text stored in `display_message`. Use the latter when logging in Odoo. See: https://github.com/odoo/iap-apps/blob/5dde71627dfd6c6168935346bece0018d4701ce3/iap_services/peppol_proxy/exceptions.py#L14 task-no Forward-Port-Of: odoo/odoo#194352
Original PR description
When an error occurs on IAP side for Peppol we display the content of `message` while we have a more friendly-user text stored in `display_message`. Use the latter when logging in Odoo. See: https://github.com/odoo/iap-apps/blob/5dde71627dfd6c6168935346bece0018d4701ce3/iap_services/peppol_proxy/exceptions.py#L14 task-no Forward-Port-Of: odoo/odoo#194352
Chart.js can be really slow when rendering a large number of datasets. So this commit limits the amount of datasets displayed by default on the graph. However a button is present to display all datasets even if it can take a moment to render them. task-4351783 Forward-Port-Of: odoo/odoo#194170 Forward-Port-Of: odoo/odoo#192892
Original PR description
Chart.js can be really slow when rendering a large number of datasets. So this commit limits the amount of datasets displayed by default on the graph. However a button is present to display all datasets even if it can take a moment to render them. task-4351783 Forward-Port-Of: odoo/odoo#194170 Forward-Port-Of: odoo/odoo#192892
Forward-Port-Of: odoo/odoo#193832 Forward-Port-Of: odoo/odoo#193775
Original PR description
Forward-Port-Of: odoo/odoo#193832 Forward-Port-Of: odoo/odoo#193775
Steps: - Install the hr_holiday module - Configure Time Off Type with validation set to `Approved by Time Off Officer` or `Both` - Create a Time Off request without setting a Time Off Officer. --- Description of the issue/feature this PR addresses: When the validation type is set to `hr` or `both` and no Time Off Officer is configured, an activity is incorrectly generated upon creating a Time Off request. --- Fix: This PR resolves the issue by ensuring the responsible user is s
Original PR description
Steps: - Install the hr_holiday module - Configure Time Off Type with validation set to `Approved by Time Off Officer` or `Both` - Create a Time Off request without setting a Time Off Officer. --- Description of the issue/feature this PR addresses: When the validation type is set to `hr` or `both` and no Time Off Officer is configured, an activity is incorrectly generated upon creating a Time Off request. --- Fix: This PR resolves the issue by ensuring the responsible user is set to empty when validation is `hr` or `Both` and no Time Off Officer is configured. task-4351688 Forward-Port-Of: odoo/odoo#194278 Forward-Port-Of: odoo/odoo#190193
This PR fixes two accessibility issues related to the gantt view connectors. Prior to this commit, the connectors were using the raw value when hovering the pill. This is mostly fine is light mode, but for some specific color, this was sometimes not enough to ensure a good visual separation between the connectors and the pill. To handle this issue, we add a pseudo element underneath the border, to make it stand out and prevent all the potential contrast issues. There was also a `z-index` is
Original PR description
This PR fixes two accessibility issues related to the gantt view connectors. Prior to this commit, the connectors were using the raw value when hovering the pill. This is mostly fine is light mode,…
This PR fixes two accessibility issues related to the gantt view connectors. Prior to this commit, the connectors were using the raw value when hovering the pill. This is mostly fine is light mode, but for some specific color, this was sometimes not enough to ensure a good visual separation between the connectors and the pill. To handle this issue, we add a pseudo element underneath the border, to make it stand out and prevent all the potential contrast issues. There was also a `z-index` issues with the connectors, the one at the bottom being hidden by the pill below. To fix the issue, we handle the `z-index` at the pill wrapper level to ensure it gets the right elevation. | 17.0 | This PR | |--------|--------| | <img width="366" alt="image" src="https://github.com/user-attachments/assets/f14d3c98-c2d5-4215-90ec-3cbe97b3ea56"> |  | task-3865935 Forward-Port-Of: odoo/enterprise#77420 Forward-Port-Of: odoo/enterprise#74859
**Problem**: When splitting a document, the `output` should include the attachments from the `input_pdf`. Currently, the attachments are missing in the output after splitting. **Steps to reproduce**: 1. In the Documents app, upload a PDF that contains attachments (example file provided in the ticket). 2. Split the uploaded PDF. 3. Preview the split file and check the left panel. 4. Notice that the attachments are missing in the left panel. opw-4191327 Forward-Port-Of: odoo/enterprise
Original PR description
**Problem**: When splitting a document, the `output` should include the attachments from the `input_pdf`. Currently, the attachments are missing in the output after splitting. **Steps to reproduce**: 1. In the Documents app, upload a PDF that contains attachments (example file provided in the ticket). 2. Split the uploaded PDF. 3. Preview the split file and check the left panel. 4. Notice that the attachments are missing in the left panel. opw-4191327 Forward-Port-Of: odoo/enterprise#77450 Forward-Port-Of: odoo/enterprise#74989
## Description - when applying sort by for a non-stored field in a list view, it leads to traceback. - when fetching data, when attempting to convert it into an SQL query, now throws error after this [commit](https://github.com/odoo/odoo/commit/fb0569eeba0a8909a067f2ad90b80edbe8d2d915), form this [line](https://github.com/odoo/odoo/blame/de47ec932742ef82b315990cbac8787f82aa91d5/odoo/models.py#L2846) - This pr ensures that only stored fields are available for sorting in the list view editor,
Original PR description
## Description - when applying sort by for a non-stored field in a list view, it leads to traceback. - when fetching data, when attempting to convert it into an SQL query, now throws error after this…
## Description
- when applying sort by for a non-stored field in a list view, it leads to traceback.
- when fetching data, when attempting to convert it into an SQL query, now throws error after this [commit](https://github.com/odoo/odoo/commit/fb0569eeba0a8909a067f2ad90b80edbe8d2d915), form this [line](https://github.com/odoo/odoo/blame/de47ec932742ef82b315990cbac8787f82aa91d5/odoo/models.py#L2846)
- This pr ensures that only stored fields are available for sorting in the list view editor, preventing such issues.
## steps to reproduce
- Start a db ( version 17.2 or greater)
- install studio and contacts app
- open studio editor for contact app's list view.
- Add display_name in list and set `sort by` attribute with `display_name` field.
## Traceback
```py
File "/home/odoo/odoo/codebase/odoo/saas-17.2/addons/web/controllers/dataset.py", line 34, in _call_kw
return call_kw(request.env[model], method, args, kwargs)
File "/home/odoo/odoo/codebase/odoo/saas-17.2/odoo/api.py", line 458, in call_kw
result = getattr(recs, name)(*args, **kwargs)
File "/home/odoo/odoo/codebase/odoo/saas-17.2/addons/web/models/models.py", line 46, in web_search_read
records = self.search_fetch(domain, specification.keys(), offset=offset, limit=limit, order=order)
File "/home/odoo/odoo/codebase/odoo/saas-17.2/odoo/models.py", line 1626, in search_fetch
query = self._search(domain, offset=offset, limit=limit, order=order or self._order)
File "/home/odoo/odoo/codebase/odoo/saas-17.2/odoo/models.py", line 5454, in _search
query.order = self._order_to_sql(order, query)
File "/home/odoo/odoo/codebase/odoo/saas-17.2/odoo/models.py", line 5266, in _order_to_sql
term = self._order_field_to_sql(alias, field_name, sql_direction, sql_nulls, query)
File "/home/odoo/odoo/codebase/odoo/saas-17.2/odoo/models.py", line 5324, in _order_field_to_sql
sql_field = self._field_to_sql(alias, field_name, query)
File "/home/odoo/odoo/codebase/odoo/saas-17.2/odoo/models.py", line 2846, in _field_to_sql
raise ValueError(f"Cannot convert field {field} to SQL")
ValueError: Cannot convert field res.partner.display_name to SQL
```
Forward-Port-Of: odoo/enterprise#77411
Forward-Port-Of: odoo/enterprise#76351Without this change it's impossible to remove the user groups from internal users, because they're being re-added upon the module updates. The reason is because there's a mechanism in place that synchronizes the newly added groups to the default user, so they're automatically added to all internal users ([ref](https://github.com/odoo/odoo/blob/6b5a839428b06e09d90631e9824a9b594ff8f4f5/odoo/addons/base/models/res_users.py#L621-L626)). For this reason and by convention, groups added t
Original PR description
Without this change it's impossible to remove the user groups from internal users, because they're being re-added upon the module updates.
The reason is because there's a mechanism in place that synchronizes the newly added groups to the default user, so they're automatically added to all internal users ([ref](https://github.com/odoo/odoo/blob/6b5a839428b06e09d90631e9824a9b594ff8f4f5/odoo/addons/base/models/res_users.py#L621-L626)).
For this reason and by convention, groups added to the default user should be non-updateable, so system administrators can remove them if they wanted to.
Related to: https://github.com/odoo/enterprise/commit/621824fb3fe1b5b895d1a37a15d45e903bc7dc6f
--
ping @tde-banana-odoo @tivisse
Forward-Port-Of: odoo/enterprise#75177
Forward-Port-Of: odoo/enterprise#55024Issue Before This Commit: -------------------------------- The delivery label generated by the Shiprocket delivery method displayed an incorrect total when a discount or free delivery was applied, which caused confusion for users. Steps to Produce: -------------------------------- 1. Apply a discount or free delivery for a Shiprocket shipment. 2. Validate the delivery. 3. The total on the delivery label will show an incorrect value, not accounting for the discount or free delivery. W
Original PR description
Issue Before This Commit: -------------------------------- The delivery label generated by the Shiprocket delivery method displayed an incorrect total when a discount or free delivery was applied, which caused confusion for users. Steps to Produce: -------------------------------- 1. Apply a discount or free delivery for a Shiprocket shipment. 2. Validate the delivery. 3. The total on the delivery label will show an incorrect value, not accounting for the discount or free delivery. With This Commit: -------------------------------- The issue is fixed by ensuring the correct data is sent to the API, which now reflects the accurate total value on the delivery label, even when a discount or free delivery is applied. Task-id: 4395054 Forward-Port-Of: odoo/enterprise#75660
Before this commit, the button label displayed as 'Comparison: <previous_period>' (where 'previous_period' was the period preceding the compared period), regardless of the comparison type selected. For example, if comparing October 2024 to previous months, the label would appear as 'Comparison: Sep 2024'. This caused confusion for users when comparing a period to multiple previous ones, as only the last period was displayed in the label. After this commit, the button label is now dynamic and
Original PR description
Before this commit, the button label displayed as 'Comparison: <previous_period>' (where 'previous_period' was the period preceding the compared period), regardless of the comparison type selected.…
Before this commit, the button label displayed as 'Comparison: <previous_period>' (where 'previous_period' was the period preceding the compared period), regardless of the comparison type selected. For example, if comparing October 2024 to previous months, the label would appear as 'Comparison: Sep 2024'. This caused confusion for users when comparing a period to multiple previous ones, as only the last period was displayed in the label. After this commit, the button label is now dynamic and reflects the selected comparison: - When comparing to previous periods: 'Comparison: <periods_number> Previous Periods' - When comparing to the previous period: 'Comparison: Previous Period' - When comparing to the same period in previous years: 'Comparison: <periods_number> Previous Years' - When comparing to the same period in the previous year: 'Comparison: Previous Pear' - When we don't compare to another period/year: 'Comparison' Here, 'periods_number' refers to the number of periods or years being compared. task-id: 4267209 Forward-Port-Of: odoo/enterprise#76407 Forward-Port-Of: odoo/enterprise#73944
Before this commit, for map views on res.partner (which have attribute res_partner = id), if the user group by a relational field (X2many, many2one), the name of the group is "None" ### Steps to reproduce: Contacts > Map view in the search bar, group by "Salesperson" On the left side of the map view, the group name is "None" ### Expected Name of partner salesperson should be visible instead of "None" original PR : #74205 Forward-Port-Of: odoo/enterprise#76248
Original PR description
Before this commit, for map views on res.partner (which have attribute res_partner = id), if the user group by a relational field (X2many, many2one), the name of the group is "None" ### Steps to reproduce: Contacts > Map view in the search bar, group by "Salesperson" On the left side of the map view, the group name is "None" ### Expected Name of partner salesperson should be visible instead of "None" original PR : #74205 Forward-Port-Of: odoo/enterprise#76248
The value sent from IAP was never sent. So what was printed was always None. So we remove its uses (and will change the method definition in non-stable Forward-Port-Of: odoo/enterprise#77102
Original PR description
The value sent from IAP was never sent. So what was printed was always None. So we remove its uses (and will change the method definition in non-stable Forward-Port-Of: odoo/enterprise#77102
Steps: - Install the hr_holiday module - Configure Time Off Type with validation set to `Approved by Time Off Officer` or `Both` - Create a Time Off request without setting a Time Off Officer. --- Description of the issue/feature this PR addresses: When the validation type is set to `hr` or `both` and no Time Off Officer is configured, an activity is incorrectly generated upon creating a Time Off request. --- Fix: This PR requires adding responsible_ids in the test cases. The ch
Original PR description
Steps: - Install the hr_holiday module - Configure Time Off Type with validation set to `Approved by Time Off Officer` or `Both` - Create a Time Off request without setting a Time Off Officer. --- Description of the issue/feature this PR addresses: When the validation type is set to `hr` or `both` and no Time Off Officer is configured, an activity is incorrectly generated upon creating a Time Off request. --- Fix: This PR requires adding responsible_ids in the test cases. The changes made in this task remove activities when responsible_ids is not set, causing the test cases to fail. Adding responsible_ids will ensure the tests pass successfully. task-4351688 Forward-Port-Of: odoo/enterprise#77385 Forward-Port-Of: odoo/enterprise#75828
**Issue:** In 17.0 and saas-17.2, The Cost of Scrap section does not appear in the the Cost Analysis Report despite having scrapped some components during manufacturing. **Steps to reproduce:** 1. Create a product with a BoM 2. Manufacture the product 3. Scrap some components during manufacturing 4. print the Cost Analysis Report 5. Notice the cost of scrap section does not appear in the report. **Solution:** - I added `raw_material_production_id` t
Original PR description
**Issue:**
In 17.0 and saas-17.2, The Cost of Scrap section does not appear
in the the Cost Analysis Report despite having scrapped some components
during manufacturing.
**Steps to reproduce:**
1. Create a product with a BoM
2. Manufacture the product
3. Scrap some components during manufacturing
4. print the Cost Analysis Report
5. Notice the cost of scrap section does not appear in the report.
**Solution:**
- I added `raw_material_production_id` to the search criteria to ensure scrap stock moves linked to raw materials are also included.
- I replaced `product_qty` with the `quantity` field for handling scrap quantities.
opw-4183097
Forward-Port-Of: odoo/enterprise#75221