Thursday, December 19, 2024
43 changes · 18.0
Enhancements to existing features
Website routes that only read information now use read-only database resources instead of the main write database. This helps improve performance and scalability for common website traffic without changing what users see or do.
Original PR description
Since [1], the readonly parameter was added to ensure that these endpoints open a cursor on the read-only replica instead of the primary read/write database, enhancing performance and scalability for read-intensive operations. This commit adds 'readonly=True' to routes handling non-modifying requests. task-4357885 [1] https://github.com/odoo/odoo/commit/584a172274caefb23e5d91b609fc893160535416
This update adds and aligns automated checks for combo product selection in rental, subscription, and website rental flows. It helps ensure customers and sales teams get consistent configurator behavior when choosing bundled or optional products.
Original PR description
This change: - Adds tests for the combo configurator, - Aligns the product configurator tests with the combo configurator ones. Community PR: https://github.com/odoo/odoo/pull/186645 task-4320163
Resolved issues and error corrections
The customer portal no longer shows invoices as overdue when they have already been reversed by a credit note. This prevents customers from seeing misleading payment reminders for invoices that are effectively settled.
Original PR description
Steps to reproduce: - create a portal user associated with a customer - create for this customer an invoice with a due date to yesterday - go on its portal view -> 1 invoice to pay will be displayed - create and confirm a credit note -> go on it portal view Issue: There will still be the invoice set as to be paid (even if in the detailed report it is defined as paid) Cause: The domain does not take into account invoice for which the payment state is `reversed` opw-4360830 Root cause: #162762 added a feature in the 18.0 portal to remind customers of overdue invoices, but did not correctly take into account reversed or blocked invoices.
Documentation and clarification updates
This updates Retama's corporate contributor agreement record by adding new members. It helps keep legal contributor documentation accurate and up to date, with no impact on product functionality.
Miscellaneous changes
Versions -------- - saas-17.4+ Steps ----- 1. Create a deliverable product with sales tax; 2. create another product without sales tax; 3. publish both to eCommerce; 4. create a discount program; 5. add both products to shopping cart; 6. apply discount; 7. go to delivery selection step. Issue ----- Endless browser reload cycle. Cause ----- The reload is supposed to sync the discount lines in the back-end with the discount lines displayed during checkout. If the number of l
Original PR description
Versions -------- - saas-17.4+ Steps ----- 1. Create a deliverable product with sales tax; 2. create another product without sales tax; 3. publish both to eCommerce; 4. create a discount program; 5. add both products to shopping cart; 6. apply discount; 7. go to delivery selection step. Issue ----- Endless browser reload cycle. Cause ----- The reload is supposed to sync the discount lines in the back-end with the discount lines displayed during checkout. If the number of lines don't match, a reload is triggered. The issue is that on the back-end, discounts are counted per line, while in eCommerce, the discounts are displayed per reward. This difference matters when a discount is applied on products with different sales taxes, creating a separate discount line for every sales tax. Solution -------- When iterating over discount lines in the controller, group them per `reward_id`, and sum up their subtotals. opw-4343959 Forward-Port-Of: odoo/odoo#191132
Badges can once again use grayscale color styles correctly after a recent design update caused them to display incorrectly. This keeps badge visuals consistent and prevents broken-looking status labels in the web interface.
Original PR description
Since the new front-end badge design[^1], we introduced a new way of handling their generation, aiming to provide a new sleek and clean design. To do so, we tweak the colors that are available with…
Since the new front-end badge design[^1], we introduced a new way of handling their generation, aiming to provide a new sleek and clean design. To do so, we tweak the colors that are available with badges, aka `.o_color_*` and status one. While this works fine, we also had to use some `!important` statements to enforce this design instead of the default BS one[^2]. Unfortunately, these `!important` introduced a side-effect, it prevents the badges to accept any other utility that we wouldn't loop through in this definition. This is what happened with the grayscale colors, meaning these badges were visually broken. To fix this issue, we simply need to add the CSS variables in use for the badge design within the grays utilities generation mixin. Responsible Commit: b4a5bf03cd81ece2a7fd21a3c5a058ee2d3336fe task-4361645 [^1]: https://github.com/odoo/odoo/pull/162935 [^2]: https://github.com/odoo/odoo/pull/162935/files#diff-f338780f594d6b1f46eda5d3fb9fed86f3c3c8f65522fb93e639534e9d92cdb2R611 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The department form no longer shows the department name field twice. This reduces confusion for HR users and makes the form cleaner without changing any underlying business process.
Original PR description
Before this commit, the "name" field was present 2 times in the department views.
The web interface no longer shows duplicate layout buttons when a control panel appears inside a dialog. This makes dialogs cleaner and avoids user confusion from repeated controls.
Original PR description
This commit fixes a bug where the control panel would display layout buttons in dialog even though they would already be present inside the dialog footer. task-4381250
Projects created directly from a sales order now start as billable by default. This prevents sales teams from accidentally creating non-billable projects and helps ensure related work can be invoiced correctly.
Original PR description
Steps to Reproduce: - Go to the Sales app - Create a new sales order - On the other info tab try to add a project: issue: the project created is non-billable by default sol: -make the project billable by default when it is created through sale order task-4207347
Store pickup delivery orders no longer show the “Send to Shipper” button, preventing users from triggering an error on orders that do not require shipment. This makes the delivery workflow clearer and avoids a crash when processing in-store pickup orders.
Original PR description
This issue occurs when a delivery order is created with the ``Carrier`` set to ``Pick up in Store``. After saving and validating the order, click the ``Send to Shipper`` button. Steps to reproduce: --- - Install ``website_sale_collect`` module - Create a new ``Delivery Order`` and in ``Additional Info`` select ``Carrier`` as ``Pick up in Store`` > Save and Validate - Click on the ``Send to Shipper`` button Traceback: --- ``TypeError: 'NoneType' object is not subscriptable`` This commit resolves the issue by adding an XPath to the view to hide the ``Send to Shipper`` button for orders with the delivery type set to ``in_store``. sentry-6040319897 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The multi-request time-off wizard now only shows time-off types that do not require allocations, matching the expected behavior from previous versions. This prevents users from selecting incompatible leave types when creating several requests at once, reducing errors in HR workflows.
Original PR description
In previous versions, when dealing with multiple time-off requests, only time-off types that do not require allocations were listed for selection. This behavior has been restored by restricting the `holiday_status_id` field to show only non-allocation time-off types in the multi-request wizard. opw-4370090 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The mail composer now ignores repeated clicks on the send or log button after the first click. This prevents users from accidentally creating duplicate messages, improving reliability with a small user-facing fix.
Original PR description
In the full composer, when the user clicks the send/log button multiple times, it sends multiple messages. This PR prevents further clicks after the button has been clicked once. Task-4347392
This fix lets users quickly create new analytic plans from the account node field by automatically using the current plan as the default context. It reduces setup friction and helps keep analytic accounting workflows moving without extra manual selection.
Original PR description
We add by default the plan of the current node in the context, allowing to create new analytic plans on the fly. task-4221324 version-18.0 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update removes an unnecessary hidden field from Vietnamese Viettel e-invoicing screens. It helps keep the module compliant with Odoo quality checks and prevents related automated test failures, with no expected impact on daily users.
Original PR description
* This is to avoid failing test_uncommented_invisible_field 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
The emoji picker now correctly shows matching frequently used emojis instead of displaying a misleading “No emoji matches your search” message. This avoids confusion for users when their search result exists only in recently or frequently used emojis, and also improves the wording of the empty-state message.
Original PR description
Before this commit, when a search in emoji picker matches only frequently used emojis, it was showing "No emoji" screen. Steps to reproduce: - add 🥦 in frequently used emoji picker (click on it in…
Before this commit, when a search in emoji picker matches only frequently used emojis, it was showing "No emoji" screen. Steps to reproduce: - add 🥦 in frequently used emoji picker (click on it in emoji picker at least once) - open any emoji picker - search for "brocoli" => It shows "No emoji match your search" The recent emojis were shown and clickable, but the empty screen being visible is a mistake. This happens because the screen was relying on emptiness on non-frequently used emojis. This means if all matches were frequently used emojis, then the screen was mistakenly displayed. The function `getEmojis()` is filtering non-recent emojis when there's an active search: `recentEmojis()` takes search term into account so it must be used to put a priority on frequent emojis. This commit fixes the issue by showing screen only when there's no emoji match, including frequently used emojis. Also reword the screen "No emoji match your search" to "No emoji matches your search". Task-4415147 Before / After <img width="307" alt="Screenshot 2024-12-18 at 16 05 28" src="https://github.com/user-attachments/assets/a61283c7-3304-46d3-bf1e-e707686470e2" /> <img width="311" alt="Screenshot 2024-12-18 at 16 05 07" src="https://github.com/user-attachments/assets/bab33944-a456-456b-b99f-c6a1aa430f0c" />
The report editor now correctly handles report template sections that use different tag types, preventing a crash when users save changes. This improves reliability for customers customizing reports in Studio.
Original PR description
have a t call node with another tag than "t". Edit the view Before this commit, there was a crash when saving the changes. The helper that recomposes the arch with the different parts inside the t-call did not account for node not to be "t" tags. After this commit, it works fine. opw-4383844
Changing the currency on a confirmed subscription order could cause an error when the system tried to create the related log entry. This fix ensures the currency change is logged correctly, preventing disruption for users managing subscription orders.
Original PR description
Before this commit, the following traceback could be encountered when changing the curency of a confirmed order (after removing the constraint in sale):
```
File "/home/arj/PycharmProjects/worktree/18.0/enterprise/sale_subscription/models/sale_order_log.py", line 95, in _create_log
return self._create_currency_transfer_log(order, initial_values)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/arj/PycharmProjects/worktree/18.0/enterprise/sale_subscription/models/sale_order_log.py", line 183, in _create_currency_transfer_log
old_mrr_new_currency = initial_values['currency_id'].currency_id._convert(old_mrr,
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AttributeError: 'res.currency' object has no attribute 'currency_id'
```Versions -------- - 17.0+ Steps ----- 1. Use COP, HLN or NIO as currency; 2. create a SO or invoice with a non-integer amount total; 3. create a payment link; 4. pay using Mercado Pago. Issue ----- > Error processing payment > Prices in COP currency must be expressed with integer values Cause ----- Our currency defaults follow the ISO 4217 standard for minor units. For three currencies (COP, HLN & NIO), Mercado Pago only accepts integer amounts instead of the standard 2 deci
Original PR description
Versions -------- - 17.0+ Steps ----- 1. Use COP, HLN or NIO as currency; 2. create a SO or invoice with a non-integer amount total; 3. create a payment link; 4. pay using Mercado Pago. Issue ----- > Error processing payment > Prices in COP currency must be expressed with integer values Cause ----- Our currency defaults follow the ISO 4217 standard for minor units. For three currencies (COP, HLN & NIO), Mercado Pago only accepts integer amounts instead of the standard 2 decimals, resulting in a failed payment transaction. Solution -------- In the payload sent to Mercado Pago, round the amount down if it uses one of the affected currencies. opw-4191877 Forward-Port-Of: odoo/odoo#191084 Forward-Port-Of: odoo/odoo#185664
**Current behavior:** On the Mobile view, when modifying the Sales Team field of a Partner (team_id field), an error is raised: "Undefined graph model for Sales Team:". **Expected behavior:** The user should be able to modify the Sales Team field of a Partner without any error. **Steps to reproduce:** 1. Install the `sales_team` & `contacts` modules. 2. Create a new Partner. 3. Go to the Mobile view. 4. Click on the Sales Team field and select a Sales Team. 5. The error is immediate
Original PR description
**Current behavior:** On the Mobile view, when modifying the Sales Team field of a Partner (team_id field), an error is raised: "Undefined graph model for Sales Team:". **Expected behavior:** The…
**Current behavior:**
On the Mobile view, when modifying the Sales Team field of a Partner (team_id field), an error is raised: "Undefined graph model for Sales Team:".
**Expected behavior:**
The user should be able to modify the Sales Team field of a Partner without any error.
**Steps to reproduce:**
1. Install the `sales_team` & `contacts` modules.
2. Create a new Partner.
3. Go to the Mobile view.
4. Click on the Sales Team field and select a Sales Team.
5. The error is immediately raised.
**Cause of the issue:**
The `kanban_view_ref="%(sales_team.crm_team_view_kanban)s"` added to the `team_id` field is not applied, as `kanban_view_ref=` has become deprecated. The kanban view `sales_team.crm_team_view_kanban_dashboard` is loaded instead as it has a lower priority.
**Fix:**
- Use `context="{'kanban_view_ref': 'sales_team.crm_team_view_kanban'}` instead of `kanban_view_ref="%(sales_team.crm_team_view_kanban)s"`.
opw-4413594
Related PRs: #116031, #126044
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#191075
Forward-Port-Of: odoo/odoo#190842*: pos_restaurant, pos_loyalty Previously, synchronization management was faulty when two devices created a command at the same time. One would override the other. To overcome this problem, when sending the command to the server, we check whether the table used by the command already contains a command. If so, they are merged. When different devices use the same PoS, when an order is created on one of them, it is directly synchronized with the others. This makes it possible to calc
Original PR description
*: pos_restaurant, pos_loyalty Previously, synchronization management was faulty when two devices created a command at the same time. One would override the other. To overcome this problem, when sending the command to the server, we check whether the table used by the command already contains a command. If so, they are merged. When different devices use the same PoS, when an order is created on one of them, it is directly synchronized with the others. This makes it possible to calculate the various table states with greater precision. As in Master, orders are now identified by UUID rather than ID. The `replaceDataByKey` function is no longer used; what it used to do is now in loadData. All these fixes are very important in view of the problems encountered by some customers. Forward-Port-Of: odoo/odoo#190088
This test is linked to this commit: https://github.com/odoo/odoo/commit/42eb159b6adb668d26cfb31aec2a59a1fd4d3a00 Related PR: https://github.com/odoo/odoo/pull/188204 opw-4352799 Forward-Port-Of: odoo/odoo#190906 Forward-Port-Of: odoo/odoo#188821
Original PR description
This test is linked to this commit: https://github.com/odoo/odoo/commit/42eb159b6adb668d26cfb31aec2a59a1fd4d3a00 Related PR: https://github.com/odoo/odoo/pull/188204 opw-4352799 Forward-Port-Of: odoo/odoo#190906 Forward-Port-Of: odoo/odoo#188821
This commit will add the basic package of the bahrain localisation. - Accounts - Taxes - Fiscal positions - States - Tax reports task: 3927915 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#190981 Forward-Port-Of: odoo/odoo#186027
Original PR description
This commit will add the basic package of the bahrain localisation. - Accounts - Taxes - Fiscal positions - States - Tax reports task: 3927915 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#190981 Forward-Port-Of: odoo/odoo#186027
When selling a product that use automated valuation in the PoS, and shipping it later, the expense account would be debited 2 times. Steps to reproduce: ------------------- * Create a product category that use AVCO and automated valuation * Create a product that uses this category * Activate the ship later option in the PoS settings * Open PoS and sell this product using the ship later option * Validate the picking created for the order > Observation: Go in the session journal items, t
Original PR description
When selling a product that use automated valuation in the PoS, and shipping it later, the expense account would be debited 2 times. Steps to reproduce: ------------------- * Create a product category that use AVCO and automated valuation * Create a product that uses this category * Activate the ship later option in the PoS settings * Open PoS and sell this product using the ship later option * Validate the picking created for the order > Observation: Go in the session journal items, the expense account is debited two times Why the fix: ------------ Because we create the expense moves when validating the ship later picking, we shouldn't do it when closing the session. opw-4338182 Forward-Port-Of: odoo/odoo#188097
We get an access error when trying to register a vendor payment with a user having access only to a branch company. Steps: - Create a branch B - Create a user U with company_id and company_ids being B - Log as user U - Create and confirm a vendor bill - Open the 'Register payment' wizard and try to create a payment -> Access Error on company id opw-4317289 Forward-Port-Of: odoo/odoo#191081 Forward-Port-Of: odoo/odoo#188512
Original PR description
We get an access error when trying to register a vendor payment with a user having access only to a branch company. Steps: - Create a branch B - Create a user U with company_id and company_ids being B - Log as user U - Create and confirm a vendor bill - Open the 'Register payment' wizard and try to create a payment -> Access Error on company id opw-4317289 Forward-Port-Of: odoo/odoo#191081 Forward-Port-Of: odoo/odoo#188512
In https://github.com/odoo/odoo/pull/113577 this view was added in the wrong module. Not only people using `l10n_it_edi` need to debug this information, but also those using EDI for other countries. I know this PR kinda violates the stability guidelines. However, #113577 also did, and here I'm fixing a bug that landed there. I hope you can still consider the PR for merging. Please tell me if there are any changes needed for making it better suited for merge if needed. Thanks! @moduon MT
Original PR description
In https://github.com/odoo/odoo/pull/113577 this view was added in the wrong module. Not only people using `l10n_it_edi` need to debug this information, but also those using EDI for other countries. I know this PR kinda violates the stability guidelines. However, #113577 also did, and here I'm fixing a bug that landed there. I hope you can still consider the PR for merging. Please tell me if there are any changes needed for making it better suited for merge if needed. Thanks! @moduon MT-8204 OPW-4362382 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#191028 Forward-Port-Of: odoo/odoo#189673
Currently, mailing traces that have error'd due to an exception during sending still count as 'sent' for the purposes of calculating email bounce rates. This makes it so that error'd email traces (those that have encountered an exception during the sending process) no longer count as sent for the purposes of calculating email bounce rates (the rate of emails whose delivery was attempted, but were rejected by the destination email server. task-4380451 Forward-Port-Of: odoo/odoo#190070
Original PR description
Currently, mailing traces that have error'd due to an exception during sending still count as 'sent' for the purposes of calculating email bounce rates. This makes it so that error'd email traces (those that have encountered an exception during the sending process) no longer count as sent for the purposes of calculating email bounce rates (the rate of emails whose delivery was attempted, but were rejected by the destination email server. task-4380451 Forward-Port-Of: odoo/odoo#190070
Steps to reproduce: - Insert a pivot in a spreadsheet (e.g. CRM Lead) - Create a global filter, set a value on it (filter on CRM Stages -> Select new) - Open the pivot side panel, update something (move up a dimension) - Save => The domain does not take the global filter into account Task: 4398645 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 guid
Original PR description
Steps to reproduce: - Insert a pivot in a spreadsheet (e.g. CRM Lead) - Create a global filter, set a value on it (filter on CRM Stages -> Select new) - Open the pivot side panel, update something (move up a dimension) - Save => The domain does not take the global filter into account Task: 4398645 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#191051 Forward-Port-Of: odoo/odoo#190781
Since https://github.com/odoo/odoo/pull/152498, we invalidate the 'templates' orm cache when we load the registry if there is an onchange trigger automation exists. Every time that a worker takes its first request or that the registry is reloaded, it will then invalidate this long-term (we try anyway) cache, reducing its efficiency depending on worker recycling. Forward-Port-Of: odoo/odoo#190393
Original PR description
Since https://github.com/odoo/odoo/pull/152498, we invalidate the 'templates' orm cache when we load the registry if there is an onchange trigger automation exists. Every time that a worker takes its first request or that the registry is reloaded, it will then invalidate this long-term (we try anyway) cache, reducing its efficiency depending on worker recycling. Forward-Port-Of: odoo/odoo#190393
### Initial issue: On a stock move, when using a lot from a sub-location, the created SML will still start from SM's source location instead of lot's location ### This issue was fixed in: - 17.0 by: https://github.com/odoo/odoo/commit/6b158aa333cf111472e4b850543b8379f0e998b7 - saas-17.2+ by: https://github.com/odoo/odoo/commit/8dec391fff243b4d079ceafd6c19b84008d2fe36 However, there is a tiny corner case where the fix of 17.0 is better than the one of saas-17.2: If you were to put hal
Original PR description
### Initial issue: On a stock move, when using a lot from a sub-location, the created SML will still start from SM's source location instead of lot's location ### This issue was fixed in: - 17.0 by:…
### Initial issue: On a stock move, when using a lot from a sub-location, the created SML will still start from SM's source location instead of lot's location ### This issue was fixed in: - 17.0 by: https://github.com/odoo/odoo/commit/6b158aa333cf111472e4b850543b8379f0e998b7 - saas-17.2+ by: https://github.com/odoo/odoo/commit/8dec391fff243b4d079ceafd6c19b84008d2fe36 However, there is a tiny corner case where the fix of 17.0 is better than the one of saas-17.2: If you were to put half of a lot in a pack in a sublocation and the other half eslewhere, the current fix of saas-17.2 would not use the sublocation that is however available as it relies on the 'location_id' field of the `stock.lot` model which will not be set in that valid use case: https://github.com/odoo/odoo/blob/d9cca6201a39c431deaf13891a314dde2db7e82e/addons/stock/models/stock_lot.py#L155-L159 The purpose of the present PR is to reconcile both fix by reverting the current one and by adapting the test to both usecases. Revert "[FIX] stock: start SML from sub location" This reverts commit https://github.com/odoo/odoo/commit/8dec391fff243b4d079ceafd6c19b84008d2fe36. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#189009 Forward-Port-Of: odoo/odoo#188840
Steps to reproduce the bug: - Create “route 1”: - applicable on: product - Rule: - Pull from - Operation type: internal transfer - Source Location: WH/Stock/Shelf 1 - Destination Location: WH/Stock/Shelf 2 - Supply Method: Take from stock - Create a storable product “P1”: - Orderpoint: - Location: WH/Stock/Shelf 2 - Min qty: 0 - route: “route 1” - create a repair order: - product to repair: selec
Original PR description
Steps to reproduce the bug: - Create “route 1”: - applicable on: product - Rule: - Pull from - Operation type: internal transfer - Source Location: WH/Stock/Shelf 1 - Destination Location:…
Steps to reproduce the bug:
- Create “route 1”:
- applicable on: product
- Rule:
- Pull from
- Operation type: internal transfer
- Source Location: WH/Stock/Shelf 1
- Destination Location: WH/Stock/Shelf 2
- Supply Method: Take from stock
- Create a storable product “P1”:
- Orderpoint:
- Location: WH/Stock/Shelf 2
- Min qty: 0
- route: “route 1”
- create a repair order:
- product to repair: select any one
- Part: Add one unit of P1
- Go to miscellaneous:
- source location: WH/Stock/Shelf 2
- Confirm the MO
Problem:
The order point will be triggered, and a stock move will be created
but not linked to a picking. This occurs because the product to be
repaired is storable and out of stock. As a result, the wizard
indicating insufficient quantity for the product is launched, and
default_repair_id is added to the context. Consequently, the move will
be created with the repair order field set and does not need to be
assigned.
https://github.com/odoo/odoo/blob/17.0/addons/repair/models/stock_move.py#L179-L182
opw-4224710
Forward-Port-Of: odoo/odoo#190706
Forward-Port-Of: odoo/odoo#188280Steps to reproduce the bug: - Create a storable product “P1” and “P2” - Create two route: - route 1: - rule 1: Pull from “WH/Stock” to “WH/Stock/Shelf 1” -> Trigger another action - rule 2: Pull from “WH/Stock/Shelf 1” to “customer -> Trigger another action - route 2: - rule 1: Pull from “WH/Stock” to “WH/Stock/Shelf 2” -> Trigger another action - rule 2: Pull from “WH/Stock/Shelf 2” to “customer -> Trigger another action - P1 -> route 1 + buy (add azure interi
Original PR description
Steps to reproduce the bug: - Create a storable product “P1” and “P2” - Create two route: - route 1: - rule 1: Pull from “WH/Stock” to “WH/Stock/Shelf 1” -> Trigger another action - rule 2: Pull from…
Steps to reproduce the bug:
- Create a storable product “P1” and “P2”
- Create two route:
- route 1: - rule 1: Pull from “WH/Stock” to “WH/Stock/Shelf 1” -> Trigger another action - rule 2: Pull from “WH/Stock/Shelf 1” to “customer -> Trigger another action
- route 2:
- rule 1: Pull from “WH/Stock” to “WH/Stock/Shelf 2” -> Trigger another action
- rule 2: Pull from “WH/Stock/Shelf 2” to “customer -> Trigger another action
- P1 -> route 1 + buy (add azure interior as vendor)
- P2 -> route 2 + buy (add azure interior as vendor)
- Create a SO: - vendor: Azure interior
- One unit of P1 and P2
- Confirm the SO
- Go to the created PO
- Confirm the PO and go to the reception
- put in pack the products together
- Try to validate the picking
Probelm:
An User Error is triggered:
ValueError: Expected singleton: stock.location(3694, 3696)
Because we have two moves with different destination locations, and we are trying to set them in all the move lines.
opw-4291067
Forward-Port-Of: odoo/odoo#189176
Forward-Port-Of: odoo/odoo#188074*: mass_mailing Users with website_designer permissions but without access to the email marketing app (mass_mailing.group_mass_mailing_user) encountered an access error when editing pages with "Newsletter" blocks. This commit fixes the issue by granting read-only access to the mailing.list model for the website_designer group. This ensures they can edit pages containing "Newsletter" blocks without exposing full email marketing functionality or compromising security. Steps to reproduce:
Original PR description
*: mass_mailing Users with website_designer permissions but without access to the email marketing app (mass_mailing.group_mass_mailing_user) encountered an access error when editing pages with "Newsletter" blocks. This commit fixes the issue by granting read-only access to the mailing.list model for the website_designer group. This ensures they can edit pages containing "Newsletter" blocks without exposing full email marketing functionality or compromising security. Steps to reproduce: - Install the website and mass_mailing modules. - Remove the "Email Marketing: User" access rights from a user in Settings > Users. - Open the Website Editor. - Add a "Newsletter" block to a page. - Observe: An access error is triggered. opw-4201455 Forward-Port-Of: odoo/odoo#190188
The PR [1] fixes a memory leak in the tooltip service. The `Map` was used with `HTMLElement` as key. These elements were not removed and so never garbage collected. A more important issue is that these elements could retain info from components like views with models. In a forward port, the change `Map` to `WeakMap` dispeared. This PR just re-adds this diff. [1]: https://github.com/odoo/odoo/pull/186579 Forward-Port-Of: odoo/odoo#190954
Original PR description
The PR [1] fixes a memory leak in the tooltip service. The `Map` was used with `HTMLElement` as key. These elements were not removed and so never garbage collected. A more important issue is that these elements could retain info from components like views with models. In a forward port, the change `Map` to `WeakMap` dispeared. This PR just re-adds this diff. [1]: https://github.com/odoo/odoo/pull/186579 Forward-Port-Of: odoo/odoo#190954
Before this commit: When user created Sales Credit Note, and send it for E-waybill. On the portal, it shows as a Supple Type as `Inward` instead of `Outward`. In this commit: We fix the above issue. opw-4402929 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#190878 Forward-Port-Of: odoo/odoo#190805
Original PR description
Before this commit: When user created Sales Credit Note, and send it for E-waybill. On the portal, it shows as a Supple Type as `Inward` instead of `Outward`. In this commit: We fix the above issue. opw-4402929 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#190878 Forward-Port-Of: odoo/odoo#190805
A stock valuation issue occurs when a landed cost is present in a bill lines of a purchase order (without the `stock.landed_cost` created) and the receipt note is validated after confirming the bill. Steps to reproduce: - Create a product with automated inventory valuation and AVCO. - On the purchase tab, set the control policy to “on ordered quantity”. - Create a purchase order with this product: * Quantity: 1 * Unit cost: $10 - Validate the PO. - Create a bill and add a landed co
Original PR description
A stock valuation issue occurs when a landed cost is present in a bill lines of a purchase order (without the `stock.landed_cost` created) and the receipt note is validated after confirming the bill.…
A stock valuation issue occurs when a landed cost is present in a bill lines of a purchase order (without the `stock.landed_cost` created) and the receipt note is validated after confirming the bill. Steps to reproduce: - Create a product with automated inventory valuation and AVCO. - On the purchase tab, set the control policy to “on ordered quantity”. - Create a purchase order with this product: * Quantity: 1 * Unit cost: $10 - Validate the PO. - Create a bill and add a landed cost line: * Quantity: 1 * Cost: $25 - Validate the bill. - Validate the receipt note. - Check the valuation: * The unit value will be incorrect, calculated as $17.5 ((10 + 25) / 2). This issue is caused by commit https://github.com/odoo/odoo/commit/5d067851248aaadf4f447f144a22553f9b188b71. The solution is to include only landed cost lines from bills where the `stock.landed.cost` is created and validated. opw-4384070 opw-4383063 Forward-Port-Of: odoo/odoo#191000 Forward-Port-Of: odoo/odoo#190815
Forward-Port-Of: odoo/enterprise#75568
Original PR description
Forward-Port-Of: odoo/enterprise#75568
Forward-Port-Of: odoo/enterprise#75570
Original PR description
Forward-Port-Of: odoo/enterprise#75570
Versions ----- SaaS 17.4+ Steps ----- 1. Create a new rental product and add at least one pricing in the "Rental prices" tab. 2. Go to the product page on the website and try to pick a date that is not valid (e.g., a range in the past). This should grey out the "Add to Cart" button and display an error message in red. 3. Change the date range to one that is valid. Issue: The "Add to Cart" button stays greyed out. Issue ----- When a customer picks a date range for a rental product t
Original PR description
Versions ----- SaaS 17.4+ Steps ----- 1. Create a new rental product and add at least one pricing in the "Rental prices" tab. 2. Go to the product page on the website and try to pick a date that is…
Versions ----- SaaS 17.4+ Steps ----- 1. Create a new rental product and add at least one pricing in the "Rental prices" tab. 2. Go to the product page on the website and try to pick a date that is not valid (e.g., a range in the past). This should grey out the "Add to Cart" button and display an error message in red. 3. Change the date range to one that is valid. Issue: The "Add to Cart" button stays greyed out. Issue ----- When a customer picks a date range for a rental product that is not valid, the "Add to Cart" button is greyed out and stays greyed out regardless of what the customer does next, even if they change the rental period to one that is available. Cause ----- In `_verifyValidRentingPeriod` and `_verifyValidPeriod`, when a rental period is not valid, the product form is disabled, and the `css_not_available` class is added to the form. However, this form is never re-enabled, meaning the `css_not_available` class is never removed, and the "Add to Cart" button stays greyed out. Solution ----- Call the `_toggleDisable` method every time the rental period is checked to ensure the form is always in the correct state. opw-4197234 Forward-Port-Of: odoo/enterprise#74507
Users only need the computation of the document type field for customer invoices. As a result, this fix restricts the assignment of document types to customer invoices, while preserving the standard functionality for all other document types. task-4299210 This is a fix for #73945 Forward-Port-Of: odoo/enterprise#75335
Original PR description
Users only need the computation of the document type field for customer invoices. As a result, this fix restricts the assignment of document types to customer invoices, while preserving the standard functionality for all other document types. task-4299210 This is a fix for #73945 Forward-Port-Of: odoo/enterprise#75335
## Issue: When we create a batch from a payment by selecting it and clicking on "Create Batch", even if the payment is already in a batch or validated, it is possible to add it to a new batch, which can lead to issues when validating the batch. ## Steps to reproduce: - Create a payment (posted but not sent) SEPA transfer. - Select this payment and create batch payment. - validate the batch - Open payments list again, and select that same payment, then create a batch payment from the se
Original PR description
## Issue: When we create a batch from a payment by selecting it and clicking on "Create Batch", even if the payment is already in a batch or validated, it is possible to add it to a new batch, which…
## Issue: When we create a batch from a payment by selecting it and clicking on "Create Batch", even if the payment is already in a batch or validated, it is possible to add it to a new batch, which can lead to issues when validating the batch. ## Steps to reproduce: - Create a payment (posted but not sent) SEPA transfer. - Select this payment and create batch payment. - validate the batch - Open payments list again, and select that same payment, then create a batch payment from the selection. - a new batch payment will be created. - If you open the batch payments list you'll notice 2 batches: 1. the original batch now has no payments inside it so the "re-generate Export File" button won't show up. 2. the second batch now contains the payment, but we can't re-generate the export file because it shows an error: The batch could not be validated, Some payments have already been sent. Solution: - before creating a batch with payments or adding payments to a batch we check if the payments we are adding are already in a batch. - also in the constrain method `_check_payments_constrains` we added a check to validate wether the payment we're adding is already validated. OPW-3976563 Forward-Port-Of: odoo/enterprise#74110 Forward-Port-Of: odoo/enterprise#67315
Before this commit, the `get_server_time` is called each time a timer reactive is created in a component since the server offset is computed thanks to that method is only stored in the timer reactive object. This commit creates a timer service as before to be able to contain the data fetched by the server to avoid having to fetch it again each time the timer is running. task-4361124 Forward-Port-Of: odoo/enterprise#74612
Original PR description
Before this commit, the `get_server_time` is called each time a timer reactive is created in a component since the server offset is computed thanks to that method is only stored in the timer reactive object. This commit creates a timer service as before to be able to contain the data fetched by the server to avoid having to fetch it again each time the timer is running. task-4361124 Forward-Port-Of: odoo/enterprise#74612
This commit updates the process to pass the company's currency code to the `_get_accounts` route. By doing so, the server can accurately identify the company's currency. This change is particularly important for supporting testing banks. task-4293992 Forward-Port-Of: odoo/enterprise#75735 Forward-Port-Of: odoo/enterprise#75372
Original PR description
This commit updates the process to pass the company's currency code to the `_get_accounts` route. By doing so, the server can accurately identify the company's currency. This change is particularly important for supporting testing banks. task-4293992 Forward-Port-Of: odoo/enterprise#75735 Forward-Port-Of: odoo/enterprise#75372
Currently a traceback is occurring when there is no working time (calendar_id) in resource, while creating a planning slot. To reproduce this issue: 1) Install planning 2) Open any planning slot in Gantt view and redirect to resource from the slot 3) Remove the Working Time of that resource 4) Now try to create a new planning slot for that resource from Gantt view Error:- ``` ValueError: Expected singleton: resource.calendar() ``` Here, `calendar_id` is not required in the r
Original PR description
Currently a traceback is occurring when there is no working time (calendar_id) in resource, while creating a planning slot. To reproduce this issue: 1) Install planning 2) Open any planning slot in…
Currently a traceback is occurring when there is no working time (calendar_id) in resource, while creating a planning slot. To reproduce this issue: 1) Install planning 2) Open any planning slot in Gantt view and redirect to resource from the slot 3) Remove the Working Time of that resource 4) Now try to create a new planning slot for that resource from Gantt view Error:- ``` ValueError: Expected singleton: resource.calendar() ``` Here, `calendar_id` is not required in the resource. So, when the user removes the calendar_id from the resource and tries to create a new planning slot, it leads to the above traceback. In the below line, we try to get calendar_d from the resource if it is available. https://github.com/odoo/enterprise/blob/7847510dc6ad8dec73f01470714aacb0c3510769/planning/models/planning.py#L611-L612 We can resolve this issue by taking calendar_id from the company as it is required. If it fails to get the value from the resource. sentry-6150920391 Forward-Port-Of: odoo/enterprise#75713