Thursday, December 19, 2024
93 changes
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
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
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