Daily updates from Odoo
Navigate
Branch
Wednesday, July 17, 2024
68 changes
26 changes
Resolved issues and error corrections
Inventory receipt line destinations now stay aligned when the destination location is changed on a purchase reception. This prevents mismatches between stock moves and their detailed move lines, helping warehouse teams route received products to the correct storage location.
Original PR description
Steps to reproduce: 1. Enable storage locations in Inventory settings. 2. Create a purchase order for a storable product and confirm it. 3. Change the destination location of the product reception. 4. Stock move destination is updated but not the SML destination. Bug: once location is set on the SML it is not updated any more by the compute opw-3971603
Changing the destination location on a stock transfer now correctly updates the related stock moves and move lines. This prevents warehouse records from becoming inconsistent and helps ensure goods are routed to the intended location.
Original PR description
When changing the destination location on a picking, it will also be updated on the included stock moves and stock move lines. However, due the introduction of the compute on the location_dest_id field on a stock move in [1], this propagation no longer works. This commit restores the updating of the stock moves when changing it on the parent picking. [1] https://github.com/odoo/odoo/pull/156437 task-3390325 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an inventory reception issue where changing a product's destination location updated the stock move but not its related move line. Businesses can rely on receptions reflecting the correct storage location, reducing picking and warehouse placement errors.
Original PR description
Steps to reproduce: 1. Enable storage locations in Inventory settings. 2. Create a purchase order for a storable product and confirm it. 3. Change the destination location of the product reception. 4. Stock move destination is updated but not the SML destination. Bug: once location is set on the SML it is not updated any more by the compute opw-3971603
This fixes an issue that blocked users from creating repair orders for product lots that are not tied to a specific company. Businesses using shared or cross-company lots can now process repairs without encountering a company validation error.
Original PR description
**Steps to reproduce the bug:** - Create a lot without company set with any product - open the repairs list from this lot - Try to save the repair **Problem:** An error is raised: “Invalide fields: Company” Since this commit: https://github.com/odoo/odoo/commit/99b39b72c7e65e85af6f06dcb6b02867623f3f69 A lot can be created without a company set, but the repair order still requires a company: https://github.com/odoo/odoo/blob/17.0/addons/repair/models/repair.py#L36-L39 This key is passed in the context as 'default_company_id', but since the lot does not have a company, the value is set to False, which triggers an error. opw-4046897
Miscellaneous changes
Before this commit, opening a record from the list view triggered field validity checks, resulting in unnecessary notifications. This commit optimizes the process by bypassing the _checkValidity function when no changes to the record have been made. opw-3987849 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#173282
Original PR description
Before this commit, opening a record from the list view triggered field validity checks, resulting in unnecessary notifications. This commit optimizes the process by bypassing the _checkValidity function when no changes to the record have been made. opw-3987849 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#173282
The index definition that supports the implementation of `_search_phone_mobile_search` defined in the `PhoneMixin` is created in an `_auto_init` in `crm_lead` of the `crm` module. This means that other models that use the mixin (for ex: `res_partner`) will not get the indexes for it's table, leading to Seq.Scans when searching for a phone number on those models. By hoisting the index definition to an `init` in the mixin, all models that inherit from the mixin will have the supporting index.
Original PR description
The index definition that supports the implementation of `_search_phone_mobile_search` defined in the `PhoneMixin` is created in an `_auto_init` in `crm_lead` of the `crm` module. This means that other models that use the mixin (for ex: `res_partner`) will not get the indexes for it's table, leading to Seq.Scans when searching for a phone number on those models. By hoisting the index definition to an `init` in the mixin, all models that inherit from the mixin will have the supporting index. Also add the same custom `trigram` index to support `like/ilike` operators in domains. task-3942852 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#166698
Before this commit, the self order was created with the user of the current session. This is not the expected behavior, as the self order is always accessed by a public user. This commit fixes this by always using the self user for the self order. Forward-Port-Of: odoo/odoo#173292
Original PR description
Before this commit, the self order was created with the user of the current session. This is not the expected behavior, as the self order is always accessed by a public user. This commit fixes this by always using the self user for the self order. Forward-Port-Of: odoo/odoo#173292
before this commit, a traceback was showing on creating product variant steps to reproduce: * click create button in product, traceback will be showing after this commit, without any traceback product is created traceback is introduced in: https://github.com/odoo/odoo/commit/758ced91f8cb220a003a49b01e047b507f8509d7 traceback details:  super()._compute_display_name() File "/da
Original PR description
before this commit, a traceback was showing on creating product variant steps to reproduce: * click create button in product, traceback will be showing after this commit, without any traceback…
before this commit, a traceback was showing on creating product variant steps to reproduce: * click create button in product, traceback will be showing after this commit, without any traceback product is created traceback is introduced in: https://github.com/odoo/odoo/commit/758ced91f8cb220a003a49b01e047b507f8509d7 traceback details:  super()._compute_display_name() File "/data/build/enterprise/sale_renting/models/product_product.py", line 14, in _compute_display_name super()._compute_display_name() File "/data/build/odoo/addons/l10n_gcc_invoice/models/product.py", line 23, in _compute_display_name product.display_name = re.sub(r'(\d)(\s)([\u0600-\u06FF])', repl, product.display_name) File "/usr/lib/python3.10/re.py", line 209, in sub return _compile(pattern, flags).sub(repl, string, count) TypeError: expected string or bytes-like object --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#172240
Accounts 471000 to 475000 can be used as suspense accounts. 471000, 472000 & 473000 have been chosen since they're the 1st ones Expected deferred accounts: - Expense: 486000 - Revenue: 487000 task-383985 Forward-Port-Of: odoo/odoo#171416
Original PR description
Accounts 471000 to 475000 can be used as suspense accounts. 471000, 472000 & 473000 have been chosen since they're the 1st ones Expected deferred accounts: - Expense: 486000 - Revenue: 487000 task-383985 Forward-Port-Of: odoo/odoo#171416
### Steps to reproduce: - Install Calendar module - Create a new event - Change the organzier to Marc Demo and then add him as attendee - Save the event ### Current behavior before PR: When changing the organizer of an event that you are creating and then add a new attendee and save the event the organizer will not be saved and will be back to the default user. This is happening because when getting the changed values to use it in the create operation it will check if the organizer
Original PR description
### Steps to reproduce: - Install Calendar module - Create a new event - Change the organzier to Marc Demo and then add him as attendee - Save the event ### Current behavior before PR: When changing…
### Steps to reproduce: - Install Calendar module - Create a new event - Change the organzier to Marc Demo and then add him as attendee - Save the event ### Current behavior before PR: When changing the organizer of an event that you are creating and then add a new attendee and save the event the organizer will not be saved and will be back to the default user. This is happening because when getting the changed values to use it in the create operation it will check if the organizer field is readonly https://github.com/odoo/odoo/blob/17.0/addons/web/static/src/model/relational_model/record.js#L592:L597 It will be true and it is readonly because of the computed field in the calendar.event 'user_can_edit' where when it checks who can edit the event before creating it the 'partner_ids' will be found as 'NewId' not yet 'res.partner' https://github.com/odoo/odoo/blob/17.0/addons/calendar/models/calendar_event.py#L296 ### Desired behavior after PR is merged: We can change the organizer of the event before assign the attendees or creating the event. As we are now checking the ids itself not the whole object of the partner_ids opw-3908333 Forward-Port-Of: odoo/odoo#172680
**Current behavior before PR:** In mobile view, whatsapp tab had no search button. **Desired behavior after PR is merged:** In mobile view, added a search button to find whatsapp channel. task-id:3525542 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#166934 Forward-Port-Of: odoo/odoo#159461
Original PR description
**Current behavior before PR:** In mobile view, whatsapp tab had no search button. **Desired behavior after PR is merged:** In mobile view, added a search button to find whatsapp channel. task-id:3525542 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#166934 Forward-Port-Of: odoo/odoo#159461
Fix of the COA: There was a bad assignation in the account rate difference profit/loss. As these are minor changes, we make this together with changes in the F29 report VAT base https://github.com/odoo/enterprise/pull/55365 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#170301 Forward-Port-Of: odoo/odoo#151611
Original PR description
Fix of the COA: There was a bad assignation in the account rate difference profit/loss. As these are minor changes, we make this together with changes in the F29 report VAT base https://github.com/odoo/enterprise/pull/55365 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#170301 Forward-Port-Of: odoo/odoo#151611
…ecordset Steps to reproduce: install hr_expense with demo data try to make a jsonrpc or any search on product.product with no domain ->key error Before PR: When the compute for standard_price_update_warning is triggered, if the recordset contains products that have unpaid expenses and some that do not have any unpaid expense, you get a traceback because some product keys are not in the mapp keys opw-3741337 Forward-Port-Of: odoo/odoo#170300 Forward-Port-Of: odoo/odoo#154760
Original PR description
…ecordset Steps to reproduce: install hr_expense with demo data try to make a jsonrpc or any search on product.product with no domain ->key error Before PR: When the compute for standard_price_update_warning is triggered, if the recordset contains products that have unpaid expenses and some that do not have any unpaid expense, you get a traceback because some product keys are not in the mapp keys opw-3741337 Forward-Port-Of: odoo/odoo#170300 Forward-Port-Of: odoo/odoo#154760
This fixes the syntax error on function _perform_analytic_distribution of the model AccountAnalyticAccount. opw-3907439 Description of the issue/feature this PR addresses and current behavior before PR: - The _perform_analytic_distribution function on model AccountAnalyticAccount has a syntax error causing a UnboundLocalError Desired behavior after PR is merged: - No UnboundLocalError --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr For
Original PR description
This fixes the syntax error on function _perform_analytic_distribution of the model AccountAnalyticAccount. opw-3907439 Description of the issue/feature this PR addresses and current behavior before PR: - The _perform_analytic_distribution function on model AccountAnalyticAccount has a syntax error causing a UnboundLocalError Desired behavior after PR is merged: - No UnboundLocalError --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#168582
This commit https://github.com/odoo/odoo/pull/166560/commits/fc2ee9e003f317e34dcc1d01e8e1a34acdb3b8dd fixed the due date which was wrong in some case, but one case was not dealt with. When using the days end of month payment term with a days_next_month to 0, the calculation was wrong. Ex: With the current implementation, If we do a case with 30 end of month 1 with a start date the 22/04, we will add 30 days and end up the 22/05 then we add 1 month (22/06) and fix the day at 1, so we will
Original PR description
This commit https://github.com/odoo/odoo/pull/166560/commits/fc2ee9e003f317e34dcc1d01e8e1a34acdb3b8dd fixed the due date which was wrong in some case, but one case was not dealt with. When using the days end of month payment term with a days_next_month to 0, the calculation was wrong. Ex: With the current implementation, If we do a case with 30 end of month 1 with a start date the 22/04, we will add 30 days and end up the 22/05 then we add 1 month (22/06) and fix the day at 1, so we will end up the 01/06. With a days_next_month to 0, the problem is that the relative delta will keep the 22/06 which is not what we wanted. task: 4045689 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#172609
### Steps to reproduce #### Use case 1: 1. Create a PO with 2 lines having different "expected arrival". 2. Change the "expected arrival" of one of the lines so that the earliest date of all the lines is modified. 3. This will change the "expected arrival" of the PO (intended) but also the "expected arrival" of all PO lines. #### > the date is changed on all the lines #### Use case 2: 1. Create a PO with 1 line and change its date planned to tomorrow 2. Save the PO 3. Add a new li
Original PR description
### Steps to reproduce #### Use case 1: 1. Create a PO with 2 lines having different "expected arrival". 2. Change the "expected arrival" of one of the lines so that the earliest date of all the…
### Steps to reproduce #### Use case 1: 1. Create a PO with 2 lines having different "expected arrival". 2. Change the "expected arrival" of one of the lines so that the earliest date of all the lines is modified. 3. This will change the "expected arrival" of the PO (intended) but also the "expected arrival" of all PO lines. #### > the date is changed on all the lines #### Use case 2: 1. Create a PO with 1 line and change its date planned to tomorrow 2. Save the PO 3. Add a new line on the SO and set a product #### > the date is changed on all the lines #### Use case 3: 1. Create a PO with 1 line and change its date planned to tomorrow 2. Save the PO 3. Add a new line for a product with at least 2 product variant and complete his grid for quantities #### > the date is changed on all the lines ### Cause of the issue: The `date_planned` fields of the `purchase.order` and `purchase.order.line` are both computed and stored. When the `date_planned` of a line (new or already existing) is changed, it triggers the compute method of the `date_planned` of the purchase order and changes it: https://github.com/odoo/odoo/blob/5d8c8f3d01c3c633bcacbdb9e42419e11eb802d9/addons/purchase/models/purchase_order.py#L184-L190 This will in turn trigger the `onchange_date_planned` of the purchase order since we are in the Form view of that model and will update the "planned_date" of every other existing line accordingly: https://github.com/odoo/odoo/blob/5d8c8f3d01c3c633bcacbdb9e42419e11eb802d9/addons/purchase/models/purchase_order.py#L229-L232 ### Fix We add back the override of the onchange that was present in previous versions and removed in the onchange refactoring made in commit https://github.com/odoo/odoo/commit/109935dbc10256bebb1f5ee0d76a23df7ea91e9f. The purpose of this override being to remove any update of the 'date_planned' of the POL's from the onchange call if this one was triggered by a change of an POL. #### Note: The third use case was fixed by commit 387e9a4 by adding the `_must_delete_date_planned` method but this fix becomes ineffective without the onchange override. opw-4000019 opw-4012390 opw-4028100 --- Forward-Port-Of: odoo/odoo#171769
This commits only just add partnerlist tour methods required for this fix https://github.com/odoo/enterprise/pull/65762 opw-3925397 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#172744 Forward-Port-Of: odoo/odoo#171260
Original PR description
This commits only just add partnerlist tour methods required for this fix https://github.com/odoo/enterprise/pull/65762 opw-3925397 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#172744 Forward-Port-Of: odoo/odoo#171260
Description of the issue/feature this PR addresses: Translations added with https://github.com/odoo/odoo/commit/e76453bf869f0a5bc2edfe861d3628b6695a205b contains unicode \u00a0 which are rendered as \u00a0 on PDF Current behavior before PR: PDF show the unicode characters  Desired behavior after PR is merged: no more unicode characters --- I confirm I have signed the CLA and read the PR
Original PR description
Description of the issue/feature this PR addresses: Translations added with https://github.com/odoo/odoo/commit/e76453bf869f0a5bc2edfe861d3628b6695a205b contains unicode \u00a0 which are rendered as \u00a0 on PDF Current behavior before PR: PDF show the unicode characters  Desired behavior after PR is merged: no more unicode characters --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#172490
NOTE: to speed up the merge process of https://github.com/odoo/odoo/pull/170785, I've cherry-picked the changes that were not yet merged in other PRs. In mrp bom kanban view, it is written "clatt" instead of "class". This commit changes that. (cherry picked from commit 758d3b80d6b1ce035a48fab42b7cab68e4ed7024) 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 t
Original PR description
NOTE: to speed up the merge process of https://github.com/odoo/odoo/pull/170785, I've cherry-picked the changes that were not yet merged in other PRs. In mrp bom kanban view, it is written "clatt" instead of "class". This commit changes that. (cherry picked from commit 758d3b80d6b1ce035a48fab42b7cab68e4ed7024) 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#173224 Forward-Port-Of: odoo/odoo#173151
This commit normalize the breakpoint used to set the justification of the dialog footer's buttons. The issue is that the breakpoint used in the utility classes didn't match the css used for nested footer's children, resulting into discrepancy in in-between viewport sizes. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#173112 Forward-Port-Of: odoo/odoo#172413
Original PR description
This commit normalize the breakpoint used to set the justification of the dialog footer's buttons. The issue is that the breakpoint used in the utility classes didn't match the css used for nested footer's children, resulting into discrepancy in in-between viewport sizes. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#173112 Forward-Port-Of: odoo/odoo#172413
You can't run the `populate` odoo-bin command more than once if `product.product` is part of the models to be populated. This is because it will always generate a kind of fixed barcode pattern in the form of `BARCODE-PP-{counter}`. This commit simply performs a quick raw SQL check to ensure no previous populate run was done, and if it was it simply retrieves the barcode of the last product created through a previous populate command. If that barcode exists, is then used as prefix itself.
Original PR description
You can't run the `populate` odoo-bin command more than once if `product.product` is part of the models to be populated. This is because it will always generate a kind of fixed barcode pattern in the…
You can't run the `populate` odoo-bin command more than once if `product.product` is part of the models to be populated. This is because it will always generate a kind of fixed barcode pattern in the form of `BARCODE-PP-{counter}`.
This commit simply performs a quick raw SQL check to ensure no previous populate run was done, and if it was it simply retrieves the barcode of the last product created through a previous populate command. If that barcode exists, is then used as prefix itself.
Running the populate command 4 times in a row will produce the following results:
```
select id,default_code, barcode from product_product order by id desc;
id | default_code | barcode
-----+--------------+----------------------------
639 | PP-150 | BARCODE-PP-150-150-150-150
638 | PP-149 | BARCODE-PP-150-150-150-149
...
```
Another option would have been to use a fully randomized string, but avoiding randomness is preferable, especially when considering the case of running the populate command only once.
Note that the `product.product` model is the only problematic one when
running back to back `populate` on all models used by accounting:
- account.move
- account.journal
- account.bank.statement
- account.bank.statement.line
- account.payment
- account.reconcile.model
- account.reconcile.model.line
- res.company
- res.partner
- res.partner.industry
- product.product
- product.category
- ...probably more through `_populate_dependencies`...
task-3821088
Forward-Port-Of: odoo/odoo#166365Specification: The automation name and ID are not visible. Additionally, the 'Disable Automation Rule' and 'Edit Automation Rule' buttons are not working in the error dialog. Expected behavior: The automation rule ID and name are visible, and both buttons work as expected. Task-3959044 Forward-Port-Of: odoo/odoo#171486
Original PR description
Specification: The automation name and ID are not visible. Additionally, the 'Disable Automation Rule' and 'Edit Automation Rule' buttons are not working in the error dialog. Expected behavior: The automation rule ID and name are visible, and both buttons work as expected. Task-3959044 Forward-Port-Of: odoo/odoo#171486
To reproduce the bug: 1. On Runbot, set the decimal accuracy of "Product Unit of Measure" to 5. 2. Go to the website and add a product to the cart. 3. Go to the cart and click on the "+" button. Some decimals may appear due to issues related to floating-point numbers. This issue is being addressed and will be fixed in the future (see: https://github.com/odoo/odoo/pull/152709). In the meantime, we can apply a fix on the frontend. opw-3990565 Forward-Port-Of: odoo/odoo#171104
Original PR description
To reproduce the bug: 1. On Runbot, set the decimal accuracy of "Product Unit of Measure" to 5. 2. Go to the website and add a product to the cart. 3. Go to the cart and click on the "+" button. Some decimals may appear due to issues related to floating-point numbers. This issue is being addressed and will be fixed in the future (see: https://github.com/odoo/odoo/pull/152709). In the meantime, we can apply a fix on the frontend. opw-3990565 Forward-Port-Of: odoo/odoo#171104
Before this commit: When you click `Send & Print` for an invoice with removing the attachments => It shows an error with a traceback `psycopg2.errors.SyntaxError: syntax error at or near ")" LINE 1: UPDATE ir_attachment SET res_id = NULL WHERE id IN ()` After this commit: `Send & Print` process works properly with removing attachments. opw-4047545 Forward-Port-Of: odoo/odoo#173371
Original PR description
Before this commit: When you click `Send & Print` for an invoice with removing the attachments => It shows an error with a traceback `psycopg2.errors.SyntaxError: syntax error at or near ")" LINE 1: UPDATE ir_attachment SET res_id = NULL WHERE id IN ()` After this commit: `Send & Print` process works properly with removing attachments. opw-4047545 Forward-Port-Of: odoo/odoo#173371
Fix for 17.1 and 17.2 only Problem: en_US data is loaded while the user uses another language Steps to reproduce: - Install "point_of_sale" app and "pos_loyalty" module - Change the language (e.g. to french) - Go to POS -> Products -> Discount & Loyalty - Create a new Loyalty Card - In Rewards, set a discount of 20 $ on order and save - Go to the shop and select a partner and a product (price must be expensive enough for the loyalty card to be applicable) - Click on "Reward", the e
Original PR description
Fix for 17.1 and 17.2 only Problem: en_US data is loaded while the user uses another language Steps to reproduce: - Install "point_of_sale" app and "pos_loyalty" module - Change the language (e.g. to…
Fix for 17.1 and 17.2 only Problem: en_US data is loaded while the user uses another language Steps to reproduce: - Install "point_of_sale" app and "pos_loyalty" module - Change the language (e.g. to french) - Go to POS -> Products -> Discount & Loyalty - Create a new Loyalty Card - In Rewards, set a discount of 20 $ on order and save - Go to the shop and select a partner and a product (price must be expensive enough for the loyalty card to be applicable) - Click on "Reward", the earlier created reward is there - Go back to the form of the loyalty card and change the value and save - Go back to the shop - Click on "Reward" and the name of the loyalty card is still the same as before while it should be for the new price Note: This error has been already fixed but this commit generalize the solution to all the params. So the previous fix is replaced by this one. See this PR for the previous fix and the test: https://github.com/odoo/odoo/pull/171049 Solution: Set the environment context for each data param so that the language is loaded by creating a wrapper. Only apply a context if some has not already been defined for specific cases where a different context is needed. "_load_data_params_with_context" replaces "_load_data_params" only where the context is used to keep a bit of optimization. opw-4039850 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#172769
A search_count is enough in this use case, especially because a classic search adds a (useless here) order by to the query. Description of the issue/feature this PR addresses: Creating an analytic account is slow on a db with 1.5M account.analytic.line. Current behavior before PR: Slow query (2.0 s) https://explain.dalibo.com/plan/dgf46e2gd03gcf39 Desired behavior after PR is merged: Fast query (0.2 ms) https://explain.dalibo.com/plan/464363de3f09eff9 --- I confirm I have signe
Original PR description
A search_count is enough in this use case, especially because a classic search adds a (useless here) order by to the query. Description of the issue/feature this PR addresses: Creating an analytic account is slow on a db with 1.5M account.analytic.line. Current behavior before PR: Slow query (2.0 s) https://explain.dalibo.com/plan/dgf46e2gd03gcf39 Desired behavior after PR is merged: Fast query (0.2 ms) https://explain.dalibo.com/plan/464363de3f09eff9 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#173437
2 changes
Miscellaneous changes
Before, the default user assigned to the self order was a standard pos user. This commit changes the default user to pos_manager to avoid any access rights issues. RB error: 70391 Forward-Port-Of: odoo/odoo#173102
Original PR description
Before, the default user assigned to the self order was a standard pos user. This commit changes the default user to pos_manager to avoid any access rights issues. RB error: 70391 Forward-Port-Of: odoo/odoo#173102
Before this commit, opening a record from the list view triggered field validity checks, resulting in unnecessary notifications. This commit optimizes the process by bypassing the _checkValidity function when no changes to the record have been made. opw-3987849 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#173282
Original PR description
Before this commit, opening a record from the list view triggered field validity checks, resulting in unnecessary notifications. This commit optimizes the process by bypassing the _checkValidity function when no changes to the record have been made. opw-3987849 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#173282
35 changes
Enhancements to existing features
Payroll salary attachments now use the existing payslip input type setup instead of a separate attachment type configuration. This reduces duplicate setup, keeps payroll rules more consistent, and simplifies maintenance for companies using salary deductions or attachments.
The bank synchronization flow now imports missing transactions made in a currency different from the account currency without losing the original payment currency information. This helps businesses reconcile multi-currency bank activity more accurately and reduces manual corrections.
Original PR description
Some banks allow customers to make payments in multiple currencies on their account. This commit will support importing transactions that are in another currency than the account currency through 'Find Missing Transactions' wizard without losing the information that they're paid in another currency. task-3972620
The addenda selection for Mexican electronic invoicing is now shown in the Accounting area of a contact instead of Sales. This makes the setting easier to find where users expect invoice-related configuration to be.
Original PR description
Users (both technical and non-technical) expect to see the configuration for addendas under Accounting as they are more related to electronic invoicing than sale orders
The appraisal workflow now has clearer empty states, better-organized feedback sections, and more useful appraisal details such as job position and previous or next appraisal dates. These changes make reviews easier to navigate, reduce mistakes when changing appraisal plans, and improve visibility into skills and feedback.
Original PR description
This PR enhances the UX design in the appraisal module with the following improvements: - Improved placeholders for empty screens and new data creation - Enhanced data presentation in the 360 feedback form - Added confirmation prompts for changes in appraisal plans in settings - Aligned state buttons for better readability - Introduced scroll bars for each feedback section (employee and manager) - Added next and previous appraisal dates, and job position fields in the appraisal form and list view - Included skills in server action menu items - Added default filters and group by options - Some other small UX improvements task-3950804
Email addresses are now formatted more consistently across Helpdesk, Appraisals, and Sign workflows. This reduces the chance of malformed recipient details in outgoing messages and helps business communications look cleaner and more reliable.
Original PR description
odoo/odoo#173467
The WhatsApp integration now loads part of its discussion app setup from the correct place. This helps keep the app structure cleaner and reduces the risk of loading issues for users interacting through WhatsApp-related conversations.
Original PR description
Part of task-3972988 community: https://github.com/odoo/odoo/pull/171576
Activity views and related extensions are now loaded only when needed. This can improve initial loading performance across affected apps while keeping the same user-facing functionality.
Original PR description
We make the activity view and its extensions to be lazy loaded. Task ID: `3546321`
The report editor now records user edits as clearer, more focused change instructions instead of saving a large replacement of the whole report structure. This should make future upgrades and maintenance easier for partners and developers while preserving the same editing workflow for users.
The US NACHA payment module was updated to meet current automated code quality checks. This reduces friction for future fixes and maintenance without changing business functionality.
Original PR description
"".format() is no longer allowed. This is enforced by the check_style_ruff step in runbot. Every bugfix touching these lines requires an exception from the runbot team. This converts every string formatting operation in l10n_us_payment_nacha to an f-string. Every bugfix will now conflict, but at least we won't have to bother the runbot team. This was done automatically with flynt [1], which as far as I can tell did a perfect job. Fixing that makes other errors pop up (e.g. FURB113 to replace multiple append() calls with a single extend()). This commit fixes those as well. The remaining ones in the module are easy and were done as well (removing # coding and super() arguments). [1] https://pypi.org/project/flynt/
Resolved issues and error corrections
Fixed an issue in restaurant Point of Sale preparation displays where adding an internal note to a newly added item could incorrectly apply that note to an earlier identical item already sent for preparation. The system now keeps those lines distinct, ensuring kitchen staff see the right note on the right item.
Original PR description
If you already ordered product A and add another product A with an internal note. The internal note would end up on both product A. The correct behavior would be to have the internal note on only one…
If you already ordered product A and add another product A with an internal note. The internal note would end up on both product A. The correct behavior would be to have the internal note on only one of them. Steps to reproduce: ------------------- * Setup a PoS restaurant and a preparation display * Open PoS session * Add 1 product A to the order and send it to preparation * Add 1 product A, and add an internal note on it * Send it to preparation > Observation: On the preparation display both product will have the internal note Why the fix: ------------ To fix the issue, when adding an internal note we only add it on the product that hasn't been sent in preparation and split the order line in 2 if necessary. We also take the order line uuid in account when processing the orders in the preparation display to differentiate the line correctly. The behavior should be the following: - If you add a note on a line that has no quantity sent in preparation the note will be on all the quantity - If you add a note on a line that has all quantity sent in preparation the note will be on all the quantity - If you add a note on a line that has a part of the quantity sent in preparation the note will be on the quantity not sent, and the line will be split in 2. One line with already sent, and one with the rest. opw-4000386
Features or functions removed from Odoo
The accounting follow-up area no longer keeps two obsolete date fields that were no longer needed. This simplifies the underlying data model without changing day-to-day user workflows.
Original PR description
Removing useless fields `last_followup_date` and `next_action_date` not needed since 61d81a378482e790c78f5084c89d8271f3e35858
The Belgian tax report posting wizard no longer shows the “ask payment” checkbox because Intervat no longer supports that option. This prevents users from selecting an outdated option and keeps Belgian VAT reporting aligned with current submission requirements.
Original PR description
Remove 'ask payment' checkbox from the Post a tax report entry wizard because the checkbox is not supported by intervat anymore task: 4045456
Code cleanup and technical improvements
This change removes an obsolete testing setting that is no longer used in guided web tour steps. It simplifies maintenance across several Odoo apps without changing day-to-day user functionality.
Original PR description
Until 6dbdc8c69eab2aaa6e9652a70254458fe466f791, allowDisabled key in step tour structure is no longer used. In this commit, we remove dead code. task~3974087 https://github.com/odoo/odoo/pull/173198
This update simplifies how guided tour steps are defined in several Odoo modules by removing an alternative trigger field and using standard selectors instead. It is an internal cleanup that should make future maintenance easier without changing the user experience.
Original PR description
In this commit, we remove the alt_trigger key from the structure of a tour step. For all cases in codebase, only adding a comma to selector is enough. task~3974087 https://github.com/odoo/odoo/pull/173096
This update prepares automated business workflow tests for a simpler way to identify pop-up windows. It reduces duplicated test configuration across several apps without changing the user-facing behavior of those apps.
Original PR description
In order to simplify the structure of a tour step, it was decided to remove the "in_modal" key. The purpose of this key is to search for the trigger in a modal element. But actually you just need to add ".modal" to the selector. This functionality therefore really has little added value. That's why we're removing it. In this commit, we prepare the ground to be able to remove this functionality by adding .modal to the selectors and forcing the fact of not looking in a modal (in_modal: false) otherwise that would be duplicative. task~3974087 https://github.com/odoo/odoo/pull/172081
Miscellaneous changes
With https://github.com/odoo/odoo/commit/2b46bfdf63b316ffb5fd57b57b3c6aa16c7d0ba6, the prop type of the View component can no longer be a js_class. Here we fix the component CustomAppointmentFormViewDialog by using the new View prop jsClass introduced in https://github.com/odoo/odoo/pull/173491. Forward-Port-Of: odoo/enterprise#66826
Original PR description
With https://github.com/odoo/odoo/commit/2b46bfdf63b316ffb5fd57b57b3c6aa16c7d0ba6, the prop type of the View component can no longer be a js_class. Here we fix the component CustomAppointmentFormViewDialog by using the new View prop jsClass introduced in https://github.com/odoo/odoo/pull/173491. Forward-Port-Of: odoo/enterprise#66826
Base quantity should correspond to line quantity instead of being hardcoded to 1. task-4038532 Forward-Port-Of: odoo/enterprise#66575
Original PR description
Base quantity should correspond to line quantity instead of being hardcoded to 1. task-4038532 Forward-Port-Of: odoo/enterprise#66575
[IMP] account_online_synchronization: disable auto sync on interactive connection 1- Some providers have bank institutions that are "interactive". In a general way, interactive institution means that users have to refresh their connection with the provider to ensure that they can still have an access to the bank. 2- It's a nightmare for users and for support as the connections keep failing in error. - Disable the automatic synchronization flow on bank sync connections with an interact
Original PR description
[IMP] account_online_synchronization: disable auto sync on interactive connection 1- Some providers have bank institutions that are "interactive". In a general way, interactive institution means that users have to refresh their connection with the provider to ensure that they can still have an access to the bank. 2- It's a nightmare for users and for support as the connections keep failing in error. - Disable the automatic synchronization flow on bank sync connections with an interactive providers and a message should be displayed explaining the situation to users. task-id#3887751 odoofin-pr#https://github.com/odoo/odoofin/pull/297 Forward-Port-Of: odoo/enterprise#63926
…dated on template change" This causes issues as composer computed value is now always forced and user value is ignored. A better fix will come soon. This reverts commit 8b7829469907b39d048a328dd3a939f1c3e1d21c. Task-3996935 Forward-Port-Of: odoo/enterprise#66727
Original PR description
…dated on template change" This causes issues as composer computed value is now always forced and user value is ignored. A better fix will come soon. This reverts commit 8b7829469907b39d048a328dd3a939f1c3e1d21c. Task-3996935 Forward-Port-Of: odoo/enterprise#66727
COM Branch : https://github.com/odoo/odoo/pull/172264 As we have some additional queries in event_sale due to a change in a @depend that trigger the compute method of the registrations status, I update the query count from 2230 to 2304 to match new query performances. Forward-Port-Of: odoo/enterprise#66648
Original PR description
COM Branch : https://github.com/odoo/odoo/pull/172264 As we have some additional queries in event_sale due to a change in a @depend that trigger the compute method of the registrations status, I update the query count from 2230 to 2304 to match new query performances. Forward-Port-Of: odoo/enterprise#66648
Steps to reproduce: 1. Open document. 2. Select a doc. > Preview the doc. 3. Replace it with another file. 4. Preview the replaced doc , Now restore the doc from the bottom of the inspector. The preview is not opened and updated with the restore file. After this Commit: The preview must be closed and updated as per the restored file. Forward-Port-Of: odoo/enterprise#66657 Forward-Port-Of: odoo/enterprise#65801
Original PR description
Steps to reproduce: 1. Open document. 2. Select a doc. > Preview the doc. 3. Replace it with another file. 4. Preview the replaced doc , Now restore the doc from the bottom of the inspector. The preview is not opened and updated with the restore file. After this Commit: The preview must be closed and updated as per the restored file. Forward-Port-Of: odoo/enterprise#66657 Forward-Port-Of: odoo/enterprise#65801
Currently, accounts `7632/9` are not taken into account in the Belgian profit and loss report. opw-4037481 Forward-Port-Of: odoo/enterprise#66666 Forward-Port-Of: odoo/enterprise#66343
Original PR description
Currently, accounts `7632/9` are not taken into account in the Belgian profit and loss report. opw-4037481 Forward-Port-Of: odoo/enterprise#66666 Forward-Port-Of: odoo/enterprise#66343
With https://github.com/odoo/odoo/commit/f1749d3299957e2949e0b78653266a5397bb213c, if a js_class is found in the arch but not in the view registry, we no longer fallback to the basic view type and a crash occurs. Here we simply remove a js_class from an arch to avoid such a crash. Build 65543538 Forward-Port-Of: odoo/enterprise#66718
Original PR description
With https://github.com/odoo/odoo/commit/f1749d3299957e2949e0b78653266a5397bb213c, if a js_class is found in the arch but not in the view registry, we no longer fallback to the basic view type and a crash occurs. Here we simply remove a js_class from an arch to avoid such a crash. Build 65543538 Forward-Port-Of: odoo/enterprise#66718
The aim of this commit is fixing the filtering of transactions when transactions have an empty identifier. Even if it's shouldn't be the case, it happens that providers return transactions without an identifier. In this case, it will always importe the first transaction and not the others as they have a similar id (an empty string). Now, we ignore in the filter these transactions. opw-4014171 Forward-Port-Of: odoo/enterprise#66550 Forward-Port-Of: odoo/enterprise#66473
Original PR description
The aim of this commit is fixing the filtering of transactions when transactions have an empty identifier. Even if it's shouldn't be the case, it happens that providers return transactions without an identifier. In this case, it will always importe the first transaction and not the others as they have a similar id (an empty string). Now, we ignore in the filter these transactions. opw-4014171 Forward-Port-Of: odoo/enterprise#66550 Forward-Port-Of: odoo/enterprise#66473
Before this PR: In the sign module, there are inconsistencies with the alignment of texts and icons, in both the portal and backend interfaces. After this PR: This fix addresses alignment issues and ensures consistency between the portal and backend interfaces. Now, texts and icons in the sign appear aligned and consistent across both interfaces. Forward-Port-Of: odoo/enterprise#66699 Forward-Port-Of: odoo/enterprise#63983
Original PR description
Before this PR: In the sign module, there are inconsistencies with the alignment of texts and icons, in both the portal and backend interfaces. After this PR: This fix addresses alignment issues and ensures consistency between the portal and backend interfaces. Now, texts and icons in the sign appear aligned and consistent across both interfaces. Forward-Port-Of: odoo/enterprise#66699 Forward-Port-Of: odoo/enterprise#63983
Steps to reproduce: 1. Install pos_restaurant_appointment. 2. Start a restaurant session. 3. Find and click the "Manage Bookings" button from the top-right burger menu. -> Whole app crashes. This is because the button is trying to open a dialog containing a custom gantt view (`appointment_booking_gantt`) that is not loaded when opening pos. This commit proposes a fix by including the custom gantt view in the pos assets to prevent this crash and to fully utilize the booking management
Original PR description
Steps to reproduce: 1. Install pos_restaurant_appointment. 2. Start a restaurant session. 3. Find and click the "Manage Bookings" button from the top-right burger menu. -> Whole app crashes. This is because the button is trying to open a dialog containing a custom gantt view (`appointment_booking_gantt`) that is not loaded when opening pos. This commit proposes a fix by including the custom gantt view in the pos assets to prevent this crash and to fully utilize the booking management by the custom gantt view. Forward-Port-Of: odoo/enterprise#66677
Steps to reproduce: - Install "Field Service" - Open "Project" - Open the settings of a random project - Then click on the "Settings" tab - Disable "Field Service" and enable "Worksheets" - Create a new task with a worksheet - Click on start then stop and save - Click on "Sign Report" Issues: The sign button is not displayed due to the condition in the template which required previously to have `is_fsm` enabled. https://github.com/odoo/enterprise/blob/4d0a467220fba5253fb4a6f388448
Original PR description
Steps to reproduce: - Install "Field Service" - Open "Project" - Open the settings of a random project - Then click on the "Settings" tab - Disable "Field Service" and enable "Worksheets" - Create a new task with a worksheet - Click on start then stop and save - Click on "Sign Report" Issues: The sign button is not displayed due to the condition in the template which required previously to have `is_fsm` enabled. https://github.com/odoo/enterprise/blob/4d0a467220fba5253fb4a6f38844861d9ed4e442/industry_fsm/views/project_portal_templates.xml?plain=1#L42 opw-4032692 Forward-Port-Of: odoo/enterprise#66599 Forward-Port-Of: odoo/enterprise#66057
Original COM PR: https://github.com/odoo/odoo/pull/144608 Original ENT PR: https://github.com/odoo/enterprise/pull/55711 In the end the feature as implemented in the original PR is not desired/correct and the mixin is also not wanted due to it adding more complexity than removing. Additionally, we want to keep the SO and PO functionality/evolution separate so moving their apparently common fields/methods into a mixin was a mistake. Therefore we revert the mixin and all of the renaming ref
Original PR description
Original COM PR: https://github.com/odoo/odoo/pull/144608 Original ENT PR: https://github.com/odoo/enterprise/pull/55711 In the end the feature as implemented in the original PR is not desired/correct and the mixin is also not wanted due to it adding more complexity than removing. Additionally, we want to keep the SO and PO functionality/evolution separate so moving their apparently common fields/methods into a mixin was a mistake. Therefore we revert the mixin and all of the renaming refactorings that also came out of the PR since they depend on the mixin and we do not want to handle the complexity of fixing the conflicts. COM PR: https://github.com/odoo/odoo/pull/172944 Forward-Port-Of: odoo/enterprise#66583
…d warning Steps to reproduce: - Go to Accounting/Reporting/Tax Report; - Make sure there is a negative amount in the tax report; - Click on PDF/EDI VAT/Test Interchange (available in debug) not to send the tax report to the government for real, and "Send VAT Report"; - Go to Reporting/EDI exports > it should have the "Rejected" status because of the negative amount(s); Issue: On the Accounting Dashboard: the error "Export(s) de taxes rejeté(s)" is appearing on several journals Sol
Original PR description
…d warning Steps to reproduce: - Go to Accounting/Reporting/Tax Report; - Make sure there is a negative amount in the tax report; - Click on PDF/EDI VAT/Test Interchange (available in debug) not to send the tax report to the government for real, and "Send VAT Report"; - Go to Reporting/EDI exports > it should have the "Rejected" status because of the negative amount(s); Issue: On the Accounting Dashboard: the error "Export(s) de taxes rejeté(s)" is appearing on several journals Solution: We get the journal defined for the Tax Return Periodicity. If no journal defined; We keep only the first Misc journal that is found This way, we let the user have custom misc journals (fec import or custom coa) opw-4004375 Forward-Port-Of: odoo/enterprise#66346
**Current behavior:** Having a picking whose operation type has the `create_backorder='ask'` setting, if a barcode line is modified using the edit button rather than actually scanning, the confirmation dialog for the backorder will be skipped. **Expected behavior:** When the 'ask' option is used, the dialog should always be displayed. **Steps to reproduce:** 1. Create a picking with a demand of 2.0 for some product, ensure the picking's op type has the 'ask' options set for
Original PR description
**Current behavior:** Having a picking whose operation type has the `create_backorder='ask'` setting, if a barcode line is modified using the edit button rather than actually scanning, the…
**Current behavior:**
Having a picking whose operation type has the
`create_backorder='ask'` setting, if a barcode line is modified
using the edit button rather than actually scanning, the
confirmation dialog for the backorder will be skipped.
**Expected behavior:**
When the 'ask' option is used, the dialog should always be
displayed.
**Steps to reproduce:**
1. Create a picking with a demand of 2.0 for some product,
ensure the picking's op type has the 'ask' options set for
backorder creation (it's the default option) -> confirm the
picking
2. In Barcode, open the picking and add 1.0 quantity to the
barcode line
3. Save the edit form, then validate the picking -> no dialog
**Cause of the issue:**
Compared the actually scanning product, modifying the line via
the form actually updates the record data. This causes the
corresponding `StockMoveLine` to get marked as `picked=True`
(via `_inverse_qty_done()` in `stock_barcode::StockMoveLine`.
The end result is `!this.lineIsReserved(line)` evaluates to
True in the Barcode client when checking whether to do
the backorder dialog which means we skip it.
**Fix:**
Remove the `lineIsReserved()` check, only look at whether
the line quantity is positive, non-zero.
*Note: the behavior between the two flows (scans vs. form edits)
diverges when the user reloads the page, however, this was also
the case prior to this change.*
opw-3972478
Forward-Port-Of: odoo/enterprise#66639
Forward-Port-Of: odoo/enterprise#64318Steps to reproduce ================== - Install hr_skills,web_studio - Go to Employees - Open any record - Add a new resume entry without description - Save - Click on the actions gear - Print > Print Resume => `Odoo India pvt. Ltd` is displayed in the report in place of the missing description Cause of the issue ================== With the new report editor in 16.4, some demo data have been added directly inside the report templates as default content. The assumption was
Original PR description
Steps to reproduce ================== - Install hr_skills,web_studio - Go to Employees - Open any record - Add a new resume entry without description - Save - Click on the actions gear - Print >…
Steps to reproduce ================== - Install hr_skills,web_studio - Go to Employees - Open any record - Add a new resume entry without description - Save - Click on the actions gear - Print > Print Resume => `Odoo India pvt. Ltd` is displayed in the report in place of the missing description Cause of the issue ================== With the new report editor in 16.4, some demo data have been added directly inside the report templates as default content. The assumption was that it would be displayed inside the report editor, but outside, since the field would have a value, the value would take over. The default content if displayed when the field value is falsy. In this case, the default content is used instead of the empty description. Solution ======== Introduce a new attribute, data-oe-demo, to be used inside the report editor. This doesn't have the drawbacks of the default content as we can choose to only display it inside the report editor --- [commit]: https://github.com/odoo/odoo/commit/a45c6c545ffdcee3bb50b3455884b8296e5d6a7c opw-4033434 Forward-Port-Of: odoo/enterprise#66660
before this commit, if some customization has to be done for changing the workflow of invoice generation, i.e., to keep the auto generated invoice in draft state the entire function has to be rewritten after this commit, a hook is introduced _process_auto_invoice which will post the invoice, later to alter this flow just need to inherit this function Forward-Port-Of: odoo/enterprise#66305 Forward-Port-Of: odoo/enterprise#66200
Original PR description
before this commit, if some customization has to be done for changing the workflow of invoice generation, i.e., to keep the auto generated invoice in draft state the entire function has to be rewritten after this commit, a hook is introduced _process_auto_invoice which will post the invoice, later to alter this flow just need to inherit this function Forward-Port-Of: odoo/enterprise#66305 Forward-Port-Of: odoo/enterprise#66200
Before this commit, when dragging documents including one or more locked documents to another workspace, only the unlocked documents are effectiveley moved and no message were shown to alert the user although the code exists but is never triggered. This commit, fix this by displaying the notification alerting the user that the locked files haven't been moved. Task-3992114 Forward-Port-Of: odoo/enterprise#66662 Forward-Port-Of: odoo/enterprise#64670
Original PR description
Before this commit, when dragging documents including one or more locked documents to another workspace, only the unlocked documents are effectiveley moved and no message were shown to alert the user although the code exists but is never triggered. This commit, fix this by displaying the notification alerting the user that the locked files haven't been moved. Task-3992114 Forward-Port-Of: odoo/enterprise#66662 Forward-Port-Of: odoo/enterprise#64670
Following #61777 , the action helper is removed to use instead a dialog template picker when using the 'new' button. However, it looks like one of the file should have been cleaned but was not. This commit removes it. Task-4035826 Forward-Port-Of: odoo/enterprise#66642
Original PR description
Following #61777 , the action helper is removed to use instead a dialog template picker when using the 'new' button. However, it looks like one of the file should have been cleaned but was not. This commit removes it. Task-4035826 Forward-Port-Of: odoo/enterprise#66642
Before this commit, the tax assignation was not working properly when a product has multiple taxes. This commit fixes the issue by adding all taxes to the product line. Forward-Port-Of: odoo/enterprise#66610 Forward-Port-Of: odoo/enterprise#66568
Original PR description
Before this commit, the tax assignation was not working properly when a product has multiple taxes. This commit fixes the issue by adding all taxes to the product line. Forward-Port-Of: odoo/enterprise#66610 Forward-Port-Of: odoo/enterprise#66568
5 changes
New functionality added to Odoo
This update adds a new wizard dialog in the Point of Sale system that requires users to select a refund reason when processing refunds for invoices or receipts in Peru. This ensures compliance with Peru's electronic invoicing requirements by capturing the specific reason for each refund (such as "Operation Cancellation"). The system now enforces that refunds are processed one invoice at a time, improving accuracy and regulatory compliance.
Original PR description
This PR adds a wizard in the POS to select a `l10n_pe_edi_refund_reason` when refunding an invoice/boleta (e.g. "Anulación de la operación", "Anulación de la operación"...). NB: according to PO feedback, it is not possible to refund several invoices/boletas at once (but it is possible to refund one invoice/boleta with multiple credit notes). task-3801234 https://github.com/odoo/odoo/pull/169597
Enhancements to existing features
Time values in graph views across helpdesk, payroll, planning, and project modules now display in a readable hh:mm format (like 5:30) instead of decimal numbers (like 5.50). This makes it easier for users to understand time-based data in reports and dashboards at a glance.
Original PR description
`* = {'helpdesk', 'hr_payroll', 'planning', 'project_timesheet_forecast', 'project_timesheet_forecast_sale'}` Before this Commit: The Graph view was not adaptable to the use of widgets, leading to…
`* = {'helpdesk', 'hr_payroll', 'planning', 'project_timesheet_forecast',
'project_timesheet_forecast_sale'}`
Before this Commit:
The Graph view was not adaptable to the use of widgets, leading to issues with
the representation of time. Specifically, hours were shown as float values in
the graph view. For example, 5 hours and 30 minutes were displayed as 5.50
instead of the more intuitive hh:mm format. Although widgets like "float_time"
or "timesheet_uom" were available to format these values, they were ineffective
in the Graph view due to the architecture parser's limitations. This caused
confusion for users trying to interpret the time accurately.
After this Commit:
The Graph view is now adaptable to the use of widgets. This means that when a widget is applied to format a field's value, the value will be displayed in the specified format. For example, hours can now be shown in the hh:mm format instead of as a float.
Widget `timesheet_uom` is used at places where the module is related/depended
on `hr_timesheet` otherwise `float_time`.
This improvement also ensures that the formatted values are reflected in the Y-axis (Ticks/Intervals) of the Graph view, enhancing the user's ability to interpret the data accurately.
Community PR: https://github.com/odoo/odoo/pull/164280
Task-3861721Bank connections with interactive providers now have automatic synchronization disabled to prevent repeated connection failures. Users will see a message explaining why their bank sync requires manual refresh instead of automatic updates, reducing support issues and improving user experience.
Original PR description
[IMP] account_online_synchronization: disable auto sync on interactive connection 1- Some providers have bank institutions that are "interactive". In a general way, interactive institution means that users have to refresh their connection with the provider to ensure that they can still have an access to the bank. 2- It's a nightmare for users and for support as the connections keep failing in error. - Disable the automatic synchronization flow on bank sync connections with an interactive providers and a message should be displayed explaining the situation to users. task-id#3887751 odoofin-pr#https://github.com/odoo/odoofin/pull/297
Resolved issues and error corrections
This fix resolves intermittent test failures in the Report Editor that occurred about 8% of the time. The issue was caused by report editing being triggered before the editor was fully loaded. By improving how the system identifies when the editor is ready, these unreliable test failures are now eliminated, ensuring more consistent and reliable testing.
Original PR description
Before this commit, in about 8% of the time for some test tours, some edition of the report was triggered before the OdooEditor had a chance to start, so the concerned step failed. After this commit, there is no such race condition, as we add OdooEditor's specific class to the step selectors. runbot-error-29949 (and all linked error)
This fix corrects inverted period filter settings in the HR Payroll Dashboard. The "current" period column was incorrectly filtering on previous data, while the "previous" period column had no filter applied. This ensures the dashboard displays the correct financial data for each period.
Original PR description
- Go to Dashboards > Configuration > Dashboards - Open the Human Resources section - Open the payroll dashboard - Open the Period filter configuration panel - the field matching period offset of pivot 3 and 4 are inverted. In the Data sheet, the column named "current" (pivot 3) is filtering on previous, and the one called "previous" (pivot 4) is not filtering on anything. Note that this fix is only active on new databases or if the dashboard is deleted then the module "spreadsheet_dashboard_hr_payroll" is updated. Task: 4056412