Tuesday, May 13, 2025
46 changes · saas-18.3
Enhancements to existing features
Users will no longer be repeatedly interrupted by the same IoT Box subscription warning, as it now appears at most once every five minutes. The Point of Sale setup popup title was also clarified to make connecting a new IoT Box easier to understand.
Original PR description
This commit contains 2 small changes: - The 'No subscription linked to your IoT Box' notification warning has been limited to trigger at most once every 5 minutes, as before it was spamming the user with repeat notifications. - The title of the PoS autoconfigure popup upon connecting a new IoT box has been changed to 'Connect to a Point of Sale'. task-4787508
Resolved issues and error corrections
Creating a new manufacturing operation could fail when no capacity value was available. The fix uses a safe default so users can open and create operations without encountering an error.
Original PR description
Go to the menu Manufacturin / Configuration / Operations (need to enable Work order option), click on new, got a traceback:
...
File "/home/odoo/Documents/dev/odoo/addons/mail/models/mail_thread.py", line 464, in _compute_field_value
return super()._compute_field_value(field)
File "/home/odoo/Documents/dev/odoo/odoo/orm/models.py", line 4623, in _compute_field_value
determine(field.compute, self)
File "/home/odoo/Documents/dev/odoo/odoo/orm/fields.py", line 73, in determine
return needle(*args)
File "/home/odoo/Documents/dev/odoo/addons/mrp/models/mrp_routing.py", line 110, in _compute_time_cycle
operation.cycle_number = float_round(quantity / capacity, precision_digits=0, rounding_method="UP")
ZeroDivisionError: float division by zero
Fix it by adding a fallback with 1 as capacity.
Bug found by adding a test on all form view in https://github.com/odoo/odoo/pull/209587 PR. But need to backport this part.Miscellaneous changes
Steps to reproduce the issue: - Start a new database without installing any module - Log in - Go to Settings - Invite a new user => A traceback occurs due to the `email_normalized` field being accessed on `res.users`. This field is defined in the `mail` module, but `base_setup` does not depend on it. This commit adds a check to ensure that the `email_normalized` field exists before attempting to access it, preventing the traceback. opw-4784587 Forward-Port-Of: odoo/odoo#209310
Original PR description
Steps to reproduce the issue: - Start a new database without installing any module - Log in - Go to Settings - Invite a new user => A traceback occurs due to the `email_normalized` field being accessed on `res.users`. This field is defined in the `mail` module, but `base_setup` does not depend on it. This commit adds a check to ensure that the `email_normalized` field exists before attempting to access it, preventing the traceback. opw-4784587 Forward-Port-Of: odoo/odoo#209310
Live chat session screens no longer show the agent's company information. This keeps session views focused on the conversation and avoids displaying unnecessary company details to users.
Original PR description
The agent company should be hidden in every live chat session view. This commit fixes the issue. task-4775840 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
Creating a new manufacturing operation could fail before users entered any details because the system tried to calculate timing with a zero capacity value. The fix uses a safe default capacity so the form opens normally and teams can configure operations without interruption.
Original PR description
Go to the menu Manufacturin / Configuration / Operations (need to enable Work order option), click on new, got a traceback:
...
File "/home/odoo/Documents/dev/odoo/addons/mail/models/mail_thread.py", line 464, in _compute_field_value
return super()._compute_field_value(field)
File "/home/odoo/Documents/dev/odoo/odoo/orm/models.py", line 4623, in _compute_field_value
determine(field.compute, self)
File "/home/odoo/Documents/dev/odoo/odoo/orm/fields.py", line 73, in determine
return needle(*args)
File "/home/odoo/Documents/dev/odoo/addons/mrp/models/mrp_routing.py", line 110, in _compute_time_cycle
operation.cycle_number = float_round(quantity / capacity, precision_digits=0, rounding_method="UP")
ZeroDivisionError: float division by zero
Fix it by adding a fallback with 1 as capacity.
Bug found by adding a test on all form view in https://github.com/odoo/odoo/pull/209587 PR. But need to backport this part.Users can now navigate the custom color picker with the keyboard without triggering an error. If navigation reaches an unavailable color option, the current selection stays focused, keeping text editing uninterrupted.
Original PR description
**Current behaviour before PR:** Steps to reproduce: - Select some text. - Open colorpicker from toolbar, switch to custom colorpicker. - Press tab 3 times to focus a color button. - Pressing ArrowDown twice leads to traceback. The issue happens because in `colorPickerNavigation` method, targetBtn assigns `false` value when row doesn't match the selector. As a result, accessing `targetBtn?.classList.contains` because `false` is not a valid value for optional chaining. **Desired behaviour after PR is merged:** Now, If no valid target button is found, focus remains on the current button and no error occurs. task-4743633 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This change removes an unnecessary database index on user settings because an existing uniqueness rule already provides the same database support. It reduces redundant database structures with no expected change for users, helping keep the system cleaner and slightly easier to maintain.
Original PR description
There is already a unique constraint `_unique_user_id` which is implicitly creating an index in the database, no need to index the field. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Fixed an issue that could crash the rental product page when opening products in a new database. This ensures business users can access rental products reliably while default pricing information is prepared.
Original PR description
… for On a virgin DB Go to renting => product Enter studio The kanban of product.template triggers an onchange to get default values Before this commit there was a crash due to a bug in the ORM: the compute of the display_price field did not compute the currency_id id correctly. task to solve the ORM bug: 4264573 solving PR: https://github.com/odoo/odoo/pull/165930 runbot-error-161799
Bank synchronization now uses the correct journal reference when calculating the global summary. This prevents incorrect amounts from appearing after selecting an account, giving users more reliable reconciliation information.
Original PR description
Before this commit, when doing a bank synchronization the active id was the id of the wizard for selecting an account. So the amount on the global summary were wrong no task id
## Description I am experiencing slow processing times for incoming stock from vendors when the historical data contains a large number of records. Currently, my company has around 20 million `stock.valuation.layer` records. As a result, any transaction involving incoming stock takes approximately 5–21 seconds to complete, even for a small number of products (around 1–5 products). Through profiling, I have identified that the root cause is the compute function `_compute_value_svl`. This c
Original PR description
## Description I am experiencing slow processing times for incoming stock from vendors when the historical data contains a large number of records. Currently, my company has around 20 million…
## Description
I am experiencing slow processing times for incoming stock from vendors when the historical data contains a large number of records.
Currently, my company has around 20 million `stock.valuation.layer` records. As a result, any transaction involving incoming stock takes approximately 5–21 seconds to complete, even for a small number of products (around 1–5 products).
Through profiling, I have identified that the root cause is the compute function `_compute_value_svl`. This computed field is always triggered during incoming stock transactions when calculating the average cost or fixing rounding errors.
## Proposal
To improve performance, I propose implementing a Parallel Index-Only Scan. This method is effective for grouping large datasets while retrieving only fixed columns, optimizing query execution.
## Benchmark
| Before | After | Speedup |
|--------|--------|--------|
| 1.1 s| 97.8 ms | 11x|
### Before
```
Finalize GroupAggregate (cost=1000.56..397852.39 rows=538 width=80) (actual time=1040.355..1114.694 rows=1 loops=1)
Group Key: product_id
Buffers: shared hit=227534 read=330906 dirtied=83 written=683
-> Gather (cost=1000.56..397825.49 rows=1076 width=80) (actual time=1039.900..1114.679 rows=3 loops=1)
Workers Planned: 2
Workers Launched: 2
Buffers: shared hit=227534 read=330906 dirtied=83 written=683
-> Partial GroupAggregate (cost=0.56..396717.89 rows=538 width=80) (actual time=1036.758..1036.759 rows=1 loops=3)
Group Key: product_id
Buffers: shared hit=227534 read=330906 dirtied=83 written=683
-> Parallel Index Scan using stock_valuation_layer_index on stock_valuation_layer
(cost=0.56..392927.16 rows=302613 width=20) (actual time=0.608..975.431 rows=247487 loops=3)
Index Cond: ((product_id = 140) AND (company_id = 1))
Buffers: shared hit=227534 read=330906 dirtied=83 written=683
Planning:
Buffers: shared hit=9 dirtied=1
Planning Time: 0.139 ms
Execution Time: 1114.732 ms
```
### After
```
Finalize GroupAggregate (cost=1000.56..21876.83 rows=538 width=80) (actual time=91.888..97.719 rows=1 loops=1)
Group Key: product_id
Buffers: shared hit=12889 read=7121
-> Gather (cost=1000.56..21849.93 rows=1076 width=80) (actual time=91.636..97.704 rows=3 loops=1)
Workers Planned: 2
Workers Launched: 2
Buffers: shared hit=12889 read=7121
-> Partial GroupAggregate (cost=0.56..20742.33 rows=538 width=80) (actual time=87.579..87.580 rows=1 loops=3)
Group Key: product_id
Buffers: shared hit=12889 read=7121
-> Parallel Index Only Scan using idx_svl_company_product on stock_valuation_layer
(cost=0.56..16951.60 rows=302613 width=20) (actual time=0.044..46.642 rows=247487 loops=3)
Index Cond: ((company_id = 1) AND (product_id = 140))
Heap Fetches: 9188
Buffers: shared hit=12889 read=7121
Planning Time: 0.107 ms
Execution Time: 97.751 ms
```
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#207311
Forward-Port-Of: odoo/odoo#203038Compute the delta for base amounts in '_round_base_lines_tax_details' from the total instead of from the base amounts only. See test in this commit. task-4457168 Forward-Port-Of: odoo/odoo#209279 Forward-Port-Of: odoo/odoo#196383
Original PR description
Compute the delta for base amounts in '_round_base_lines_tax_details' from the total instead of from the base amounts only. See test in this commit. task-4457168 Forward-Port-Of: odoo/odoo#209279 Forward-Port-Of: odoo/odoo#196383
Allow to limit number of recipients before hiding them in email To headers. By default we consider that more than 50 recipients denotates a public record on which headers should not be modified. Instead standard Odoo behavior (reply to record) will be used. Replaces odoo/odoo@c95ae3d4ee4dd4d6fc92d9f69b75194e9524ecb5 with a more generic approach. Notably it is customizable by class, which is quite handy. Task-4787149 Forward-Port-Of: odoo/odoo#209521
Original PR description
Allow to limit number of recipients before hiding them in email To headers. By default we consider that more than 50 recipients denotates a public record on which headers should not be modified. Instead standard Odoo behavior (reply to record) will be used. Replaces odoo/odoo@c95ae3d4ee4dd4d6fc92d9f69b75194e9524ecb5 with a more generic approach. Notably it is customizable by class, which is quite handy. Task-4787149 Forward-Port-Of: odoo/odoo#209521
Before this commit, whatsapp conversations could not send voice message. This is a regression made from this PR: https://github.com/odoo/odoo/pull/186084 This commit re-adds the feature to voice a message in whatsapp. Note that whatsapp conversations allow only 1 attachments per message. Since a voice message is an attachment, this commit makes sure allow voice message only when no attachment, and similarly allow uploading a file only when there's no ongoing voice recording. opw-4750
Original PR description
Before this commit, whatsapp conversations could not send voice message. This is a regression made from this PR: https://github.com/odoo/odoo/pull/186084 This commit re-adds the feature to voice a message in whatsapp. Note that whatsapp conversations allow only 1 attachments per message. Since a voice message is an attachment, this commit makes sure allow voice message only when no attachment, and similarly allow uploading a file only when there's no ongoing voice recording. opw-4750594 Forward-Port-Of: odoo/odoo#209497
Issue : Given a pivot grouped by date with anything else than year as aggregate (I tried with week, quarter and month), Given the pivot is exploded When I autofill the date cells and the date passes from one year to another, it crashes hard New behaviour: For bounded date fields, the autofill loop around when reaching the upper bound. Task: 4700703 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: ---
Original PR description
Issue : Given a pivot grouped by date with anything else than year as aggregate (I tried with week, quarter and month), Given the pivot is exploded When I autofill the date cells and the date passes from one year to another, it crashes hard New behaviour: For bounded date fields, the autofill loop around when reaching the upper bound. Task: 4700703 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#207336 Forward-Port-Of: odoo/odoo#205048
**Current behavior before PR:** Steps to reproduce: - Create a link in button primary format. - Select the label of the link either double clicking on the text. - Try to remove link from toolbar. - Notice that the link is not removed properly. This issue happens because if there is an adjacent `feff` character before or after selected text node of link and it is not traversed in selection then `splitAroundUntil` ends up creating an adjacent empty link. If link is in button format the
Original PR description
**Current behavior before PR:** Steps to reproduce: - Create a link in button primary format. - Select the label of the link either double clicking on the text. - Try to remove link from toolbar. - Notice that the link is not removed properly. This issue happens because if there is an adjacent `feff` character before or after selected text node of link and it is not traversed in selection then `splitAroundUntil` ends up creating an adjacent empty link. If link is in button format then empty links are visible. **Desired behavior after PR is merged:** Link should be removed entirely. task-4622487 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#209477 Forward-Port-Of: odoo/odoo#200530
- Before this fix, when a user which have only access to a company branch (not access to the parent company), he was not able to open a POS session. This issue was only appearing when using a belgian company (with `l10n_be_pos_sale` installed). This error was raised becaues we try to load Intra-Community chart template which is defined on the parent company. - Now we use `sudo()` to correctly load the Intra-Community chart template of the parent company, because if the user has permission to op
Original PR description
- Before this fix, when a user which have only access to a company branch (not access to the parent company), he was not able to open a POS session. This issue was only appearing when using a belgian…
- Before this fix, when a user which have only access to a company branch (not access to the parent company), he was not able to open a POS session. This issue was only appearing when using a belgian company (with `l10n_be_pos_sale` installed). This error was raised becaues we try to load Intra-Community chart template which is defined on the parent company. - Now we use `sudo()` to correctly load the Intra-Community chart template of the parent company, because if the user has permission to open a POS session on a company branch, he should be able to load its Intra-Community chart template (even if it's defined on the parent company). - Update the test `test_pos_branch_company_access` so the `pos_user` have only access to the company branch (not the parent company anymore). Steps to reproduce: - Install ``l10_be_pos_sale` module - Create a new belgian company with a branch - Create a new user with access to this company branch (not the parent company) - Create a new POS config for this company branch (with admin user) - Try to open a POS session with the newly created user - => Access error opw: 4736949 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#208573
The aim of this commit is to give an user friendly message when there is a lack of configuration. Context: Odoo IN didn't set up their expense account and end user faced a very unfriendly (some even says mean!) traceback. They then selected Odoo SA as main company and ended with another meanier traceback as an account from Odoo SA was selected for an expense of Odoo IN. Before this commit: End users could face an unfriendly traceback in case of lack of configuration. After this com
Original PR description
The aim of this commit is to give an user friendly message when there is a lack of configuration. Context: Odoo IN didn't set up their expense account and end user faced a very unfriendly (some even says mean!) traceback. They then selected Odoo SA as main company and ended with another meanier traceback as an account from Odoo SA was selected for an expense of Odoo IN. Before this commit: End users could face an unfriendly traceback in case of lack of configuration. After this commit: End users will face a friendly userError in case of a lack of configuration. opw-4699717 Forward-Port-Of: odoo/odoo#209507
Forward-Port-Of: odoo/odoo#206969
Original PR description
Forward-Port-Of: odoo/odoo#206969
Introduced in odoo/odoo#164793. Steps to reproduce: - Configure a POS to use self order - Add an Adyen payment method to this POS - Attempt to pay for a self order using the Adyen payment method - The payment fails immediately with an error message, however the payment does go through to the payment terminal. This bug was introduced by the refactor to use related models. The `start_payment` method in the payment page wasn't updated accordingly, leading to an error due to calling a non-
Original PR description
Introduced in odoo/odoo#164793. Steps to reproduce: - Configure a POS to use self order - Add an Adyen payment method to this POS - Attempt to pay for a self order using the Adyen payment method - The payment fails immediately with an error message, however the payment does go through to the payment terminal. This bug was introduced by the refactor to use related models. The `start_payment` method in the payment page wasn't updated accordingly, leading to an error due to calling a non-existent function. All other payment terminals are unaffected as they override this method, but Adyen does not, so the bug was only affecting Adyen payments. task-4749171 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#207205
Issue ----- Batch applying quantity adjustments creates duplicated journal entries. Steps to reproduce ----- - Create two products with automated valuation and 10 on hand quantity - Go to Inventory > Operations > Physical inventory and create an inventory adjustment for the two products (one positive, one negative) - Select both lines and click on "Adjust All" - Go to accounting > Accounting > Journal items -> Duplicated entries with one using the inventory valuation account and sto
Original PR description
Issue ----- Batch applying quantity adjustments creates duplicated journal entries. Steps to reproduce ----- - Create two products with automated valuation and 10 on hand quantity - Go to Inventory > Operations > Physical inventory and create an inventory adjustment for the two products (one positive, one negative) - Select both lines and click on "Adjust All" - Go to accounting > Accounting > Journal items -> Duplicated entries with one using the inventory valuation account and stock input and the other using the valuation account with stock output account Fix ----- This issue has been fixed by commit ce5d303 so just adding a small test to round things up. ----- Tickets: opw-4672011 opw-4677147 opw-4670069 Forward-Port-Of: odoo/odoo#205667
Previously, all available data was sent to the E-Invoice system, even if some fields contained incorrect values. However, certain fields (e.g., email) have validation but are not required. **After this commit:** - Before generating the final JSON, only correctly validated fields are included. - Ensured that incorrect or improperly formatted data does not get sent. - Invalid optional fields are now logged in the chatter with error message.  have validation but are not required. **After this commit:** - Before generating the final JSON, only correctly validated fields are included. - Ensured that incorrect or improperly formatted data does not get sent. - Invalid optional fields are now logged in the chatter with error message.  task-4594234 Forward-Port-Of: odoo/odoo#203659
Use `time.process_time_ns` which is not influenced by other processes running on the machine. This allows to have consistent timing and less non-deterministic results. We also switch to the ns version, so that division per record does not loose too much precision for small values. We may need to fallback to `perf_counter_ns` on some systems where the precision is too low. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#2
Original PR description
Use `time.process_time_ns` which is not influenced by other processes running on the machine. This allows to have consistent timing and less non-deterministic results. We also switch to the ns version, so that division per record does not loose too much precision for small values. We may need to fallback to `perf_counter_ns` on some systems where the precision is too low. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#207958
When an orderline is deleted, it wasn't being removed from the indexedDB. This commit ensures that deleted orderlines are also removed from the local storage, maintaining data integrity in the POS. opw-4626344 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#203820 Forward-Port-Of: odoo/odoo#202110
Original PR description
When an orderline is deleted, it wasn't being removed from the indexedDB. This commit ensures that deleted orderlines are also removed from the local storage, maintaining data integrity in the POS. opw-4626344 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#203820 Forward-Port-Of: odoo/odoo#202110
Issue: = - Updating presets on multiple POS setups at once caused a singleton error. Fix: = - Now processes each POS configuration individually to prevent the error. Related PR: https://github.com/odoo/odoo/pull/196800 Task: 4523232 Forward-Port-Of: odoo/odoo#208223
Original PR description
Issue: = - Updating presets on multiple POS setups at once caused a singleton error. Fix: = - Now processes each POS configuration individually to prevent the error. Related PR: https://github.com/odoo/odoo/pull/196800 Task: 4523232 Forward-Port-Of: odoo/odoo#208223
The bg color of the right panel in discuss app, e.g. channel member list, lack same bg color as header and left sidebar. As a result, the bg was the same as the message list, which made it hard to read due to being separated by only slight border in-between. This commit puts the same bg color on this panel in discuss app as header and left sidebar. Forward-Port-Of: odoo/odoo#209504
Original PR description
The bg color of the right panel in discuss app, e.g. channel member list, lack same bg color as header and left sidebar. As a result, the bg was the same as the message list, which made it hard to read due to being separated by only slight border in-between. This commit puts the same bg color on this panel in discuss app as header and left sidebar. Forward-Port-Of: odoo/odoo#209504
Before this commit, message bubble border was too dark. This gave the impression that squashed messages had too much spacing. Forward-Port-Of: odoo/odoo#209503
Original PR description
Before this commit, message bubble border was too dark. This gave the impression that squashed messages had too much spacing. Forward-Port-Of: odoo/odoo#209503
# Context Building on a recent PR (https://github.com/odoo/odoo/pull/188697), we introduce multiple small tweaks to enhance the life of support agents and system admins that work a lot with the log files in the the context of email related issues. # Changes * A given `mail.mail` record being processed by the `_send` method can end up sending multiple emails under the hood ( if `recipient_ids` points to muliple ids). This means that the ratio between one `mail.mail` record and the number
Original PR description
# Context Building on a recent PR (https://github.com/odoo/odoo/pull/188697), we introduce multiple small tweaks to enhance the life of support agents and system admins that work a lot with the log…
# Context Building on a recent PR (https://github.com/odoo/odoo/pull/188697), we introduce multiple small tweaks to enhance the life of support agents and system admins that work a lot with the log files in the the context of email related issues. # Changes * A given `mail.mail` record being processed by the `_send` method can end up sending multiple emails under the hood ( if `recipient_ids` points to muliple ids). This means that the ratio between one `mail.mail` record and the number of email sent through SMTP is not always 1:1. We added a new log line that counts the total emails processed in the loop which should give a more precise estimation of the real number of emails attempted through SMTP * Given the above, we the usual log line was not reporting all the (redacted) list of email addresses but only the `email_to` of the last `msg` value created during the inner loops. We now correctly show a comma seperated list of all recipients in a given batch. * The historical log line `Sent batch %s emails via mail server ID #%s` could be missleading as it was not counting the number of emails but the number of `mail.mail` records processed. It was reformulated to account for this. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#209314 Forward-Port-Of: odoo/odoo#206657
When an image is added in a website page by using the `/image` command of the Powerbox, it is not optimized like when the media dialog is used to replace an image. Also, when an image is replaced, the auto-optimization is not always included in the last history step - which makes operations like inserting a new paragraph remove the optimization. This commit makes sure that the `image_changed` event is: - triggered after the new image is inside the DOM - completed before considering we
Original PR description
When an image is added in a website page by using the `/image` command of the Powerbox, it is not optimized like when the media dialog is used to replace an image. Also, when an image is replaced,…
When an image is added in a website page by using the `/image` command of the Powerbox, it is not optimized like when the media dialog is used to replace an image. Also, when an image is replaced, the auto-optimization is not always included in the last history step - which makes operations like inserting a new paragraph remove the optimization. This commit makes sure that the `image_changed` event is: - triggered after the new image is inside the DOM - completed before considering we are done - included in the same history step that applied the media dialog's change. It also avoids recomputing the auto-optimization several times for a single trigger of the event. Steps to reproduce: Scenario 1: - Drop a three columns snippet - Put your cursor after "Feature 1" - Press ENTER - Use the "/image" Powerbox command to add an image that should be resized by the auto-optimization => Image was the original uploaded image. Scenario 2: - Drop a three columns snippet - Double click on an image - Upload/select an image that will be resized by the auto-optimization - Put your cursor after "Feature 1" - Press ENTER => Image's optimization was lost because it happened after the history step was completed. task-4129429 Forward-Port-Of: odoo/odoo#205294 Forward-Port-Of: odoo/odoo#177433
Issue ----- For subcontracted services, branch companies don't have taxes on PO lines when it is created by a SO. Steps to reproduce ----- - Install MRP, Sale, Purchase apps - Create a branch company and switch to the branch - In the settings, enable subcontracting - Create a product - Type: service - Add a vendor for the product, with some tax applied - Tick the "Subcontract Service" box - Create & confirm a sale for the product - Open the linked PO -> The PO doesn
Original PR description
Issue
-----
For subcontracted services, branch companies don't have taxes on PO lines when it is created by a SO.
Steps to reproduce
-----
- Install MRP, Sale, Purchase apps
- Create a branch company and switch to the branch
- In the settings, enable subcontracting
- Create a product
- Type: service
- Add a vendor for the product, with some tax applied
- Tick the "Subcontract Service" box
- Create & confirm a sale for the product
- Open the linked PO
-> The PO doesn't have the tax specified on the product page
Cause
-----
The tax is defined in the parent, but when applied to the POL it is matched to the PO's company.
Forward-Port-Of: odoo/odoo#209080
Forward-Port-Of: odoo/odoo#208616Before this commit, the write_date field was not loaded for restaurant.order.course, which caused issues during the loading. opw-4779831 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#208981
Original PR description
Before this commit, the write_date field was not loaded for restaurant.order.course, which caused issues during the loading. opw-4779831 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#208981
### Steps to reproduce: - install "l10n_de" and switch to a German company - Go to a contact, in the page Accounting > Electronic Invoicing change the format to "Factur-X (CII)" - Create an invoice for this contact - Add a start and end date on the line of this invoice - Confirm and send to Factur-X - In the generated XML there is no trace of the start or end dates ### Solution: Set the variables to add the `BillingSpecifiedPeriod` in the XML. Put `invoice_date` as start date and `invo
Original PR description
### Steps to reproduce: - install "l10n_de" and switch to a German company - Go to a contact, in the page Accounting > Electronic Invoicing change the format to "Factur-X (CII)" - Create an invoice for this contact - Add a start and end date on the line of this invoice - Confirm and send to Factur-X - In the generated XML there is no trace of the start or end dates ### Solution: Set the variables to add the `BillingSpecifiedPeriod` in the XML. Put `invoice_date` as start date and `invoice_date_due` as end date. opw-4680890 Forward-Port-Of: odoo/odoo#209102 Forward-Port-Of: odoo/odoo#208088
Before this commit a traceback was occurring on going back from a view with search bar. After this commit the traceback will not occur anymore on going back from a view with search bar. task-4735022 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#207931
Original PR description
Before this commit a traceback was occurring on going back from a view with search bar. After this commit the traceback will not occur anymore on going back from a view with search bar. task-4735022 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#207931
During `retrying` method we still don't have any uid on the current env (the authentification is inside the `func` -> `_serve_ir_http`). If there is an Integrity Error coming from the method/controller called, the error is catch by `retrying` and call `_sql_error_to_message` leading to a traceback: ``` ... File "/home/odoo/src/odoo/saas-18.2/odoo/http.py", line 2016, in _transactioning return service_model.retrying(func, env=self.env) File "/home/odoo/src/odoo/saas-18.2/odoo/service
Original PR description
During `retrying` method we still don't have any uid on the current env (the authentification is inside the `func` -> `_serve_ir_http`). If there is an Integrity Error coming from the…
During `retrying` method we still don't have any uid on the
current env (the authentification is inside the `func` ->
`_serve_ir_http`). If there is an Integrity Error coming from the
method/controller called, the error is catch by `retrying` and call
`_sql_error_to_message` leading to a traceback:
```
...
File "/home/odoo/src/odoo/saas-18.2/odoo/http.py", line 2016, in _transactioning
return service_model.retrying(func, env=self.env)
File "/home/odoo/src/odoo/saas-18.2/odoo/service/model.py", line 186, in retrying
message = env._("The operation cannot be completed: %s", model._sql_error_to_message(exc))
File "/home/odoo/src/odoo/saas-18.2/odoo/orm/models.py", line 2916, in _sql_error_to_message
cons_rec = self.env['ir.model.constraint'].search_fetch([
File "/home/odoo/src/odoo/saas-18.2/odoo/orm/models.py", line 1390, in search_fetch
query = self._search(domain, offset=offset, limit=limit, order=order or self._order)
File "/home/odoo/src/odoo/saas-18.2/odoo/orm/models.py", line 4993, in _search
self.browse().check_access('read')
File "/home/odoo/src/odoo/saas-18.2/odoo/orm/models.py", line 3719, in check_access
if not self.env.su and (result := self._check_access(operation)):
File "/home/odoo/src/odoo/saas-18.2/odoo/orm/models.py", line 3752, in _check_access
if not Access.check(self._name, operation, raise_exception=False):
File "/home/odoo/src/odoo/saas-18.2/odoo/addons/base/models/ir_model.py", line 2051, in check
has_access = model in self._get_allowed_models(mode)
File "decorator.py", line 232, in fun
return caller(func, *(extras + args), **kw)
File "/home/odoo/src/odoo/saas-18.2/odoo/tools/cache.py", line 125, in lookup
value = d[key] = self.method(*args, **kwargs)
File "/home/odoo/src/odoo/saas-18.2/odoo/addons/base/models/ir_model.py", line 2023, in _get_allowed_models
group_ids = self.env.user._get_group_ids()
File "decorator.py", line 232, in fun
return caller(func, *(extras + args), **kw)
File "/home/odoo/src/odoo/saas-18.2/odoo/tools/cache.py", line 125, in lookup
value = d[key] = self.method(*args, **kwargs)
File "/home/odoo/src/odoo/saas-18.2/odoo/addons/base/models/res_users.py", line 1026, in _get_group_ids
self.ensure_one()
File "/home/odoo/src/odoo/saas-18.2/odoo/orm/models.py", line 5497, in ensure_one
raise ValueError("Expected singleton: %s" % self)
```
It actually hides the legit constraint message error.
Fix it by adding a sudo() to the constraint search, since whatever the
user (public or not), the error message should be accessible and
returned.
Forward-Port-Of: odoo/odoo#207244…queryCount Extra query made by the tax engine to retrieve the country from the company. Forward-Port-Of: odoo/enterprise#85133 Forward-Port-Of: odoo/enterprise#85092
Original PR description
…queryCount Extra query made by the tax engine to retrieve the country from the company. Forward-Port-Of: odoo/enterprise#85133 Forward-Port-Of: odoo/enterprise#85092
Steps: - install `web_studio` and `documents_spreadsheet` - open documents - open studio on the spreadsheet kanban view (the default one) - change sort by field to "created on" field - error This commit replaces encodeURIComponent with window.encodeURIComponent, because owl won't try to evaluate this variable via the context. And so the fix ```js get renderingContext() { const context = super.renderingContext; context.encodeURIComponent = encodeURIComponent;
Original PR description
Steps:
- install `web_studio` and `documents_spreadsheet`
- open documents
- open studio on the spreadsheet kanban view (the default one)
- change sort by field to "created on" field
- error
This commit replaces encodeURIComponent with window.encodeURIComponent,
because owl won't try to evaluate this variable via the context.
And so the fix
```js
get renderingContext() {
const context = super.renderingContext;
context.encodeURIComponent = encodeURIComponent;
...
}
```
In `DocumentsKanbanRecord` is no longer necessary.
The error occurred because `encodeURIComponent` was not found in the context object.
The reason this fix doesn't work with studio is the view is defined as
```xml
<kanban js_class="documents_kanban"/>
```
and studio does not load view js classes.
And since the fix is in `documents_kanban`, it's not taken into account. opw-4744886
Forward-Port-Of: odoo/enterprise#84411Before this commit, whatsapp conversations could not send voice message. This is a regression made from this PR: https://github.com/odoo/odoo/pull/186084 This commit re-adds the feature to voice a message in whatsapp. Note that whatsapp conversations allow only 1 attachments per message. Since a voice message is an attachment, this commit makes sure allow voice message only when no attachment, and similarly allow uploading a file only when there's no ongoing voice recording. opw-4750
Original PR description
Before this commit, whatsapp conversations could not send voice message. This is a regression made from this PR: https://github.com/odoo/odoo/pull/186084 This commit re-adds the feature to voice a message in whatsapp. Note that whatsapp conversations allow only 1 attachments per message. Since a voice message is an attachment, this commit makes sure allow voice message only when no attachment, and similarly allow uploading a file only when there's no ongoing voice recording. opw-4750594 Forward-Port-Of: odoo/enterprise#85303
Issue : Given a pivot grouped by date with anything else than year as aggregate (I tried with week, quarter and month), Given the pivot is exploded When I autofill the date cells and the date passes from one year to another, it crashes hard New behaviour: For bounded date fields, the autofill loop around when reaching the upper bound. Task: 4700703 Forward-Port-Of: odoo/enterprise#84071 Forward-Port-Of: odoo/enterprise#82980
Original PR description
Issue : Given a pivot grouped by date with anything else than year as aggregate (I tried with week, quarter and month), Given the pivot is exploded When I autofill the date cells and the date passes from one year to another, it crashes hard New behaviour: For bounded date fields, the autofill loop around when reaching the upper bound. Task: 4700703 Forward-Port-Of: odoo/enterprise#84071 Forward-Port-Of: odoo/enterprise#82980
The Issue: Prior to this commit, retrieving the amount currency from the transaction details caused a traceback. This occurred because the transaction details are stored as a jsonb object, and the code attempted to access a string within a dictionary, resulting in a TypeError mismatch. The Fix: The jsonb object is now converted to a string before processing. Additionally, an IndexError is caught to handle cases where the expected group is not found in the match. opw-4754518 Forward-Port
Original PR description
The Issue: Prior to this commit, retrieving the amount currency from the transaction details caused a traceback. This occurred because the transaction details are stored as a jsonb object, and the code attempted to access a string within a dictionary, resulting in a TypeError mismatch. The Fix: The jsonb object is now converted to a string before processing. Additionally, an IndexError is caught to handle cases where the expected group is not found in the match. opw-4754518 Forward-Port-Of: odoo/enterprise#84769
Steps: - Have a main company C with a branch B - Select B in company selector, but have C checkbox checked too - Create a user U with `company_id == B` - Create and confirm an invoice I for user U, company_id should be B, amount X - Go back to accounting dashboard, and open reconciliation widget - Create a new transaction, amout X - Select it, select line from I and click on Validate -> UserError: "Incompatible companies on records" This reason is, even if we have Branch company sele
Original PR description
Steps: - Have a main company C with a branch B - Select B in company selector, but have C checkbox checked too - Create a user U with `company_id == B` - Create and confirm an invoice I for user U, company_id should be B, amount X - Go back to accounting dashboard, and open reconciliation widget - Create a new transaction, amout X - Select it, select line from I and click on Validate -> UserError: "Incompatible companies on records" This reason is, even if we have Branch company selected as `env.company`, as we have Main company checked too, the statement line is created with `company_id == main company` With this commit, we unset the partner from the statement line's move if it is from an accessible branch but not the main company. We also test different usecases to secure the flow. opw-4626664 Forward-Port-Of: odoo/enterprise#84951 Forward-Port-Of: odoo/enterprise#82896
### Steps to reproduce: - Create an employee with flexible schedule with 8 hours per day - Navigate to Attendance app -> Gantt View - Check the progress bar for the flexible employee - Notice the progress bar will show X/11 ### Cause: This is happening as when calculating the maximum value for the employee's working hours we are adding a day to the date range https://github.com/odoo/enterprise/blob/2da6836520c4e7760e57062e3e97a22b744baacf/hr_attendance_gantt/models/hr_attendance.py#L
Original PR description
### Steps to reproduce: - Create an employee with flexible schedule with 8 hours per day - Navigate to Attendance app -> Gantt View - Check the progress bar for the flexible employee - Notice the progress bar will show X/11 ### Cause: This is happening as when calculating the maximum value for the employee's working hours we are adding a day to the date range https://github.com/odoo/enterprise/blob/2da6836520c4e7760e57062e3e97a22b744baacf/hr_attendance_gantt/models/hr_attendance.py#L47 ### Fix: We don't need to add this extra day as already the difference between the start and stop is relfecting the correct number of days opw-4680513 Forward-Port-Of: odoo/enterprise#84250
Beofre this commit: Products with both positive and negative sales order lines in SO can result it total quantity = 0 when calcuating average cost. Causing division by zero error. After this commit: Added a check to prevent division if total quantity of product is zero. Negative order lines are usually used for return of product, it is not included in shipping request. opw-4655713 Forward-Port-Of: odoo/enterprise#84201 Forward-Port-Of: odoo/enterprise#83500
Original PR description
Beofre this commit: Products with both positive and negative sales order lines in SO can result it total quantity = 0 when calcuating average cost. Causing division by zero error. After this commit: Added a check to prevent division if total quantity of product is zero. Negative order lines are usually used for return of product, it is not included in shipping request. opw-4655713 Forward-Port-Of: odoo/enterprise#84201 Forward-Port-Of: odoo/enterprise#83500
Step to reproduce : - Create a folder with a sub folder and a request or two requests. - Share the parent folder with edit permission to anyone. - Go to the public folder view. - Upload a file for the last request document. - The file will be uploaded to the first editable folder/request found. This was due to a hidden form tag to upload file to sub folders which was using the same class as the one used by the request documents (o_request_upload). Using class instead of id also
Original PR description
Step to reproduce : - Create a folder with a sub folder and a request or two requests. - Share the parent folder with edit permission to anyone. - Go to the public folder view. - Upload a file for the last request document. - The file will be uploaded to the first editable folder/request found. This was due to a hidden form tag to upload file to sub folders which was using the same class as the one used by the request documents (o_request_upload). Using class instead of id also means that it wasn't possible to share more than one request document. Task-4718126 Forward-Port-Of: odoo/enterprise#83222
Steps to reproduce: - Setup an employee with identification_id, and l10n_hk_given_name - Leave l10n_hk_mpf_manulife_account and l10n_hk_surname empty - Generate Manulife MPF report with any payslips Current behavior: - Error raised Expected behavior: - Should be able to generate the report Forward-Port-Of: odoo/enterprise#85113
Original PR description
Steps to reproduce: - Setup an employee with identification_id, and l10n_hk_given_name - Leave l10n_hk_mpf_manulife_account and l10n_hk_surname empty - Generate Manulife MPF report with any payslips Current behavior: - Error raised Expected behavior: - Should be able to generate the report Forward-Port-Of: odoo/enterprise#85113
Problem: In a multi-company environment with multiple companies from India, users are getting access right errors about being unable to read employees from Company B when viewing the Salary Register from Company A and vice versa. Steps to Reproduce on Runbot: 1. Install accounting,employee, payroll, India payroll 2. Create 2 Indian companies with India fiscal package 3. Create an employee per company and create payslips per employee and pay them 4. View the salary register in Payroll > Re
Original PR description
Problem: In a multi-company environment with multiple companies from India, users are getting access right errors about being unable to read employees from Company B when viewing the Salary Register from Company A and vice versa. Steps to Reproduce on Runbot: 1. Install accounting,employee, payroll, India payroll 2. Create 2 Indian companies with India fiscal package 3. Create an employee per company and create payslips per employee and pay them 4. View the salary register in Payroll > Reporting --> access right error thrown opw-4677551 Forward-Port-Of: odoo/enterprise#85241 Forward-Port-Of: odoo/enterprise#83199
It is possible that a employee won't have a contract (maybe a freelancer) nor a user related. In such case when asked to sign a document, the document cannot be signed. It is possible to reproduce this behaviour on runbot https://www.awesomescreenshot.com/video/39482670?key=9eed08257cc76b5749c1c8c0dda62377 This commit aims to set a user, since the user cannot be false. I believe that since one of the options would be set it to the manager of the contract the employee is under, it would be a
Original PR description
It is possible that a employee won't have a contract (maybe a freelancer) nor a user related. In such case when asked to sign a document, the document cannot be signed. It is possible to reproduce this behaviour on runbot https://www.awesomescreenshot.com/video/39482670?key=9eed08257cc76b5749c1c8c0dda62377 This commit aims to set a user, since the user cannot be false. I believe that since one of the options would be set it to the manager of the contract the employee is under, it would be a valid option considering that the employee has no contract, to set it to whoever sent the request, in this case, the request create_uid opw-4750010 Forward-Port-Of: odoo/enterprise#84711
Steps to reproduce: - Activate foreign currency EUR (main company in USD) - Have a Bank journal in EUR - Create one Vendor "Send" payment of 100 EUR - Create a new Vendor batch payment and add the payment. - Open EUR Bank and register an outgoing transaction of 100 EUR - Match the transaction with the Batch payment Issue: Looking at the debit/credit columns it can be seen that the transaction amount is properly converted in company currency, but the batch amount is not converted (rate
Original PR description
Steps to reproduce: - Activate foreign currency EUR (main company in USD) - Have a Bank journal in EUR - Create one Vendor "Send" payment of 100 EUR - Create a new Vendor batch payment and add the payment. - Open EUR Bank and register an outgoing transaction of 100 EUR - Match the transaction with the Batch payment Issue: Looking at the debit/credit columns it can be seen that the transaction amount is properly converted in company currency, but the batch amount is not converted (rate 1.00) This occurs because when the payments in a batch don't have an associated move, the amount residual is converted from payment currency (EUR) to batch currency (still EUR) and not company currency (USD) opw-4656807 Forward-Port-Of: odoo/enterprise#83632