Daily updates from Odoo
Tuesday, July 2, 2024
13 changes · 17.0
Security fixes and vulnerability patches
This update fixes a security vulnerability where digital certificates were being returned with elevated permissions (sudo access) to users with company access. The fix ensures that digital certificates are no longer returned with these elevated permissions, protecting sensitive authentication credentials from unauthorized access.
Original PR description
Problem --------- `_get_digital_signature` currently returns a sudo certificate. This is not safe. Objective --------- Don't return a sudo certificate to anyone having access to this company. Forward-Port-Of: odoo/enterprise#65836 Forward-Port-Of: odoo/enterprise#65607
New functionality added to Odoo
This update adds support for automatically retrieving currency exchange rates from Uruguay's Central Bank (BCU). Businesses operating in Uruguay can now use the official BCU webservices to keep their currency rates current and accurate, eliminating the need for manual updates.
Original PR description
Add a currency rates update method using the BCU (Banco Central Uruguayo) webservices for Uruguay (UY). Webservices used: - Get last currency rate update date https://cotizaciones.bcu.gub.uy/wscotizaciones/servlet/awsultimocierre - Get rates https://cotizaciones.bcu.gub.uy/wscotizaciones/servlet/awsbcucotizaciones Latest PDF specification [here](https://drive.google.com/file/d/122UtHhpdYEmbOti0nr0d-brZs65kiLDT/view) Rates can be manually verified [here](https://www.bcu.gub.uy/Estadisticas-e-Indicadores/Paginas/Cotizaciones.aspx) For questions or updated specifcations, please send an email to mesadeayuda@bcu.gub.uy *Note: the `CodigoISO` tag isn't a reliable ISO code, that's why we use their specific `Moneda` currency code instead.* Credits to **Adhoc** for the development. Original PR: odoo/enterprise#49519
Enhancements to existing features
This update adds automated testing to verify that Balance Sheet reports are properly balanced across all localizations. The system now validates that debits equal credits in Balance Sheets by generating test transactions and checking the results, helping catch accounting errors early. This improvement ensures financial reports maintain their fundamental accounting principle of balanced entries.
Original PR description
This PR introduces a `l10n` test over the Balance Sheet reports. Each Balance Sheet report in the `LOC_DATA` global at the head of the file will be tested. The test generates a journal entry with a…
This PR introduces a `l10n` test over the Balance Sheet reports.
Each Balance Sheet report in the `LOC_DATA` global at the head of the file will be tested.
The test generates a journal entry with a line in every account that is not `off_balance`.
It then checks whether the Balance Sheet is balanced.
The test does this both for debits and for credits.
The test will give a warning for any installed Balance Sheet report which is not specified in the LOC_DATA global. The aim is to change this to an error once all existing Balance Sheets are tested, to make this test mandatory for any new localizations.
For each localization with a Balance Sheet, the test needs to know the XMLIDs of:
- the CoA
- the Balance Sheet report
- the Total Assets line of the Balance Sheet
- the Total Liabilities line of the Balance Sheet
- the Total Equity line of the Balance Sheet (if applicable)
Setting the global `IDENTIFY_INCORRECT_ACCOUNTS` to `True` switches the behaviour of the test: it identifies the accounts that cause the imbalance using a binary search. This is off by default for runbot.
**Performance impact**
- For each Balance Sheet, the test does the following:
- load the chart template
- create an account.move with 4 AMLs for each account (one debit and credit in the account; and one debit and credit in the counterpart account)
- generate the report once.
- The Binary Search (which can be toggled when testing locally) is quite efficient:
- If there is just one incorrect account, then the report needs to be generated `log2(<number of accounts>)` times.
- If there are `X` incorrect accounts, then in the worst-case the report may need to be generated `X * log2(<number of accounts>)` times.
On the Belgian CoA, with no incorrect accounts, the test takes 14s on my PC. With 4 incorrect accounts, the test takes 33s.
Task: 3060790
Forward-Port-Of: odoo/enterprise#36838This update improves how Odoo handles global discounts and negative line items by moving the core logic to the main accounting module. This allows other countries' localization modules to reuse the same discount handling approach, while the Mexico localization module continues to provide country-specific tax and document processing. This change makes the system more efficient and easier to maintain across different regions.
Original PR description
To allow other localizations to use the same logic for negative lines, we moved the methods in account. We still extend it in the module to add specific logic about taxes and documents. task-3943357
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.