Daily updates from Odoo
Tuesday, July 2, 2024
15 changes
6 changes
Resolved issues and error corrections
Fixes an issue where spreadsheet links to list or pivot views could fail because required context was not passed along. Users can now open these linked views from spreadsheets without encountering errors.
Original PR description
## Description: navigateTo helper function in helpers.js was not passing the context to the action. This commit resolves the problem by ensuring the context is properly passed to the action. task-3880304 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Merging customer or vendor records no longer fails when both partners have the same bank account linked to posted payments. The system now consolidates duplicate bank accounts first, helping users clean up partner records without payment history blocking the process.
Original PR description
Currently, you cannot merge partners if they have bank accounts linked to payments. ### Steps to reproduce 1. Install the `account` module. 2. Create two partners, each having the same bank account…
Currently, you cannot merge partners if they have bank accounts linked to payments. ### Steps to reproduce 1. Install the `account` module. 2. Create two partners, each having the same bank account number. 3. Create and post payments for each of those partners. 4. Attempt to merge those partners. You should be met with the following message: ``` The operation cannot be completed: another model requires the record being deleted. If possible, archive it instead. Model: Journal Entry (account.move) Constraint: account_move_partner_bank_id_fkey ``` ### Cause When merging partners, the system attempts to update all foreign keys referencing the partners being merged. In certain circumstances, this update violates unicity constraints. In such cases, the system simply deletes the records that can't be updated. In our case, the `res_partner_bank` table has the following unicity constraint: `unique(sanitized_acc_number, partner_id)`. When we merge the two partners and the system attempts to update the `partner_id` field on `res_partner_bank`, the constraint is violated because both partners originally had the same account number. The system then tries to delete those bank accounts, but it fails because they are linked to payments (with an `ondelete restrict` clause). ### Fix Identify the bank accounts that are duplicated between the source and destination partners, and merge them before merging the partners. ### Note `_update_foreign_keys_generic` is basically just `_update_foreign_keys` from `data_merge`. `_merge_additional_models` exactly the one from `data_merge` opw-3925952
Online course managers now see a clear prompt if they try to publish certification content without selecting a certificate, preventing an error page. The front-end option to create a new certification during upload was removed so certifications are properly set up through the back office before use.
Original PR description
**Crash Prevention:** Added validation to ensure a certificate is selected before saving and publishing, preventing errors. **Creation Restriction:** Removed the option to create certifications from the front-end to avoid incomplete setups, requiring back-end customization. **Code cleanup**: Remove an unused template. Task-3940344
Indian e-invoicing can now process invoice lines with negative amounts. This fixes an unnecessary restriction, helping businesses handle discounts, corrections, or adjustments more smoothly.
Original PR description
This PR removes the restriction on invoice lines having negative amounts in the `l10n_in_edi` module, which was introduced in PR https://github.com/odoo/odoo/pull/170736. This fix allows invoice lines with negative amounts to be processed, aligning with the intended functionality and ensuring a smoother invoicing experience.
This update brings the spreadsheet component to a newer version with several small fixes. Users should see smoother spreadsheet editing, including better sheet name editing, corrected translation loading, and improved find-and-replace navigation.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/fac2351f9 [REL] 17.2.13 Task: 0 https://github.com/odoo/o-spreadsheet/commit/ef733da35 [FIX] BottomBarSheet: Prevent drag of sheet while editing its name Task: 4010842 https://github.com/odoo/o-spreadsheet/commit/235ff4cc8 [FIX] model: mark default translations as loaded Task: 3999116 https://github.com/odoo/o-spreadsheet/commit/af15d3af3 [FIX] find_and_replace: fix previous command Task: 3839575 Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com> Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com> Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com> Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com> Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com> Co-authored-by: Mehdi Rachico (mera) <mera@odoo.com> Co-authored-by: Rémi Rahir (rar) <rar@odoo.com> Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com> Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
This fix prevents a confusing failure when confirming a sales order if a delivery operation has no default destination location set. Users are now guided more clearly to correct the stock configuration, helping avoid blocked deliveries after upgrades or manual setup changes.
Original PR description
Steps to reproduce: - Enable locations in Stock settings - Edit delivry order picking type in Inventory overview - Edit the form view and remove required from default_location_dest_id - Set Default Destination Location to blank - Create and confirm a new SO Bug: default_location_dest_id is only required on the frontend if not set an error is thrown when confirming an SO (impossible to create the move) Fix: -Stable: upgrade script has already been fixed https://github.com/odoo/upgrade/pull/5873 but it's better to still add a more userfreindly redirect for customers that upgraded before the PR was merged (particularly since it's still possible to mess it up as the field is not required on the backend) -Matser: set the field as required on the backend aswell opw-3970295
9 changes
Resolved issues and error corrections
A recent update accidentally removed the scroll bar from the left side of the bank reconciliation widget, making it difficult to navigate transaction lists. This fix restores the scroll functionality so users can properly scroll through transactions on both sides of the reconciliation interface.
Original PR description
With https://github.com/odoo/enterprise/pull/45256/files we broke the left scroll bar of the transactions. Both sides of the bank rec widget should have their own. Before the fix:  After the fix:  opw-4029287
This update fixes a crash that occurred when editing timesheet entries in the list view. The system was incorrectly trying to access timer information that didn't exist, causing an error. The fix ensures the system properly checks whether a timer is active before attempting to access timer-related data, allowing users to edit timesheets without encountering errors.
Original PR description
Versions -------- - 17.0 - saas-17.1 - saas-17.2 - saas-17.3 Steps ----- 1. Go to timesheets; 2. go to list view; 3. edit a timesheet line. Issue ----- `UncaughtPromiseError` Cause ----- Commit bae2e8146d48 added the `onRecordChanged` method, which fixed the issue of the timer not recording time spent on a project. The issue is that this method is also called when changing a row from the list view, and there's no `timesheet` value set by the timer, causing an error when trying to access `this.timesheet.resId`. Solution -------- Check `this.timerState.timesheetId` instead of `this.timesheet.resId`. `this.timerState` is guaranteed to exist, and its `timesheetId` value will be `undefined` if the timer isn't running, skipping the timer-specific logic. Also handle default projects when set. opw-4027099
This fix resolves a crash that occurred when setting certain pay period frequencies (semi-annually, bi-monthly, or semi-monthly) in the Australian payroll module. The system was missing configuration data for these payment periods, causing errors when creating new contacts. The fix adds the missing period definitions so all supported pay frequencies work correctly.
Original PR description
To reproduce the bug: - Have payroll and its l10n-au additional modules installed - Go to payroll -> config -> structure types - Change the first element 'Default Scheduled Pay' to semi-annually - Go to contacts and create click on New A python traceback will show. That's due to giving the PERIODS_PER_YEAR dictionary a non-existent key. As we can see, it lacks 'semi-monthly', 'bi-monthly', and 'semi-annually' periods. opw-4015682
This update resolves a testing problem in the Peru electronic invoicing module where automated tests were failing due to a recent change in how the system handles external service calls. The fix ensures that tests can properly validate the cancellation status checking functionality without being blocked by testing restrictions.
Original PR description
PR #62452 (15.0+) added extra IAP calls that retry requesting the cancellation status in case the cancellation was not processed yet. In odoo/odoo#122663 (17.0+), IAP calls were disabled in tests. When fw-porting the first PR above, this change of behaviour in 17.0 was not taken into account meaning that the tests kept failing in 17.0+. We fix this by applying the same strategy as #62452 - patch the thread to remove the testing attribute during IAP calls. runbot-64793
This fix corrects how monthly recurring revenue (MRR) is calculated for subscription orders placed in currencies different from the company's main currency. Previously, the system locked in the exchange rate from the order date, which was incorrect since customers continue paying in their original currency while exchange rates fluctuate. The fix now properly accounts for currency rate changes over time, ensuring accurate revenue reporting.
Original PR description
Steps to reproduce: Create a Subscription order in a different currency (THS) than the main currency (USD). Bug: We consider that the MRR is a "living amount". The customer will continue to pay the amount is TSh. This amount is converted into the currency of the company at the order date rate (from TSH to USD) which means, the TSh value is fixed at order date which is not correct as customer will continue to pay in TSh and the rate evolve. opw-3813197
Fixed an issue where EU sales invoices containing lines without products were not appearing in the EC sales report. This fix ensures all eligible invoices are properly included in the report, improving the accuracy of EU sales tracking for Dutch companies. The underlying data retrieval method was updated to support this change.
Original PR description
Before, when creating an invoice for eu operations, lines without product were not accounted inside the ec sales report. Now when an invoice with lines without product happens, it will be displayed inside the ec sales report. This fix had to change the way the sbr icp export retrieved those values. Task: 3978307 Forward-Port-Of: odoo/enterprise#64265
When copying a rental product with custom pricing for different variants, the pricing information now correctly links to the new product variants instead of pointing back to the original product. This ensures that copied rental products maintain their pricing structure accurately.
Original PR description
Versions -------- - 16.0+ Steps ----- 1. Create a rental product template; 2. add an attribute w/ 2 or more values; 3. go to "Rental prices" and add new pricings for specific variants; 4. copy the product template; 5. go to the "Rental prices" of the copied product. Issue ----- The pricings refer to the products variants of the original template instead of the newly created ones. Cause ----- Default copy logic doesn't link the new pricings to the new products. Solution -------- Add a `copy` override which creates new pricings for the proper variants. opw-3878124 Forward-Port-Of: odoo/enterprise#63284
Fixed an issue where the backorder confirmation dialog was not appearing when warehouse staff manually edited barcode quantities using the edit form instead of scanning. The dialog will now always display when the system is configured to ask about creating backorders, ensuring consistent behavior regardless of how quantities are updated.
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-3972478This fix corrects how the system records who uploaded files when using document sharing features. Previously, the system incorrectly credited the person who created the share link instead of the actual person who uploaded the file. Now the correct uploader is properly identified and recorded.
Original PR description
Prior to this commit, when uploading a file through a share, the file upload note used the share creator's id instead of the id of the actual user who uploaded the file. After this commit, the id of the actual file uploader is used.