Daily updates from Odoo
Friday, March 29, 2024
124 changes
New functionality added to Odoo
This update adds automated testing capabilities for exporting source language terms from modules. This enables scripts to automatically retrieve the latest translation terms, improving the efficiency of the translation management process and ensuring consistency across the system.
Original PR description
Add a test for exporting the source terms of modules. This will allow automated scripts to fetch latest terms Backport save_test_file with a parameter on date_format to have predictable filenames Forward-Port-Of: odoo/odoo#159291 Forward-Port-Of: odoo/odoo#154624
This update modifies the tax configuration for Ecuador to reflect new VAT rates effective March 2024. The changes include adding new tax groups for 5%, 13%, and 15% VAT rates, archiving outdated tax rates, and configuring the appropriate tax accounts. This ensures Ecuadorian businesses using Odoo can accurately calculate and report taxes according to current local regulations.
Original PR description
- Add new tax groups for VAT at 5%, 13%, and 15% - Add taxes of 5% and 15% - Archive VAT taxes of 5% in sales and 12% - Configure tax group accounts for the new tax groups - Add new foreign account tax position tax template at 15% VAT 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
Resolved issues and error corrections
This fix ensures that when an email is received, the system correctly identifies which company's contact should be used, especially when the same email address exists for contacts in multiple companies. Previously, the system would always use the first contact found, regardless of which company was actually receiving the email. This fix prioritizes contacts that match the company context, preventing tickets from being incorrectly assigned to the wrong company's contact.
Original PR description
Versions -------- - 16.0+ Steps ----- 1. Have two companies with helpdesk teams; 2. create a contact associated with company 1; 3. create a contact associated with company 2 w/ the same email address; 4. from this address, send an email to team 2 to create a ticket. Issue ----- Ticket is created using company 1's contact. Cause ----- When searching for partners associated with an email address, it only looks at the first one. Solution -------- Expanding on e1d50a404516d5b32bf01508423c5a1c880cb304 which prioritized the current user, further prioritize based on companies matching the records passed to `_mail_find_partner_from_email`, avoiding potential access rights errors in multi-company environments. opw-3705199 Forward-Port-Of: odoo/odoo#156158
Internal transfer picking reports were not showing the destination location information when printed. This fix corrects the report template logic to properly display destination details for all internal transfers, ensuring users have complete information when processing warehouse transfers.
Original PR description
### Steps to reproduce: - Activate "Storage Locations" in the settings and create a warehouse - Inventory > Operations > Transfers > Internal - Create a new internal transfer with a non-zero product move line - Print the "Picking Operations" ### Expected behavior: The destination of the move should be on the document. ### Current behavior: The report (and hence the printed version) of an internal transfer does not display the destination of the transfer. ### Cause of the issue / fix: This part of the report is displayed under a `t-elif` condition. However for internal trasnfers the condition of the `t-if` and of the `t-elif` are both `true` so that two `t-if` should be used for an appropriate display of the report. ### Note: Prior to commit 567b8d6, two `t-if` were used. opw-3797998 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#158852
This fix allows users to change a location to or from a scrap location even when there are completed inventory moves in that location. Previously, the system was incorrectly blocking these changes. The fix ensures that only active (non-completed) reservations prevent location changes, restoring the correct behavior from before Odoo 17.
Original PR description
## Before this commit: Modifying a location from/to a scrap location should be restricted when there are move lines with reservation. However, starting from Odoo 17, the quantity field indicates the reserved quantity only when the move line's state is different from done. ## After this commit: Only check if there are reservation lines (move lines not in done) in the location when changing from/to a scrap location to match the behaviour before Odoo 17. opw-3815275
This update fixes an issue where users encountered errors when uploading images to mass mailing campaigns. The system now properly handles invalid image files instead of generating error logs, providing a smoother user experience when managing email marketing content.
Original PR description
Currently, a logger exception is generated when the user tries to upload any document in the mass mail.
Stack trace on sentry:
```
UnidentifiedImageError: cannot identify image file <_io.BytesIO object at 0x7f1ad928db70>
File "addons/mass_mailing/models/mailing.py", line 1437, in _get_image_by_url
image = Image.open(io.BytesIO(content))
File "PIL/Image.py", line 3008, in open
raise UnidentifiedImageError(
```
This is because an UnidentifiedImageError occurs when the user uploads
an image file as a document and code [1] tries to open it with Image.
This commit adds code that handles an UnidentifiedImageError, and it adds
the message in the log for an invalid image file.
[1]-https://github.com/odoo/odoo/blob/029b84f3c061f819bacb9a4818504cced4adeb1c/addons/mass_mailing/models/mailing.py#L1405
sentry-4311184876
Forward-Port-Of: odoo/odoo#157513This fix prevents subscription orders from being locked when the "Lock Confirmed Sales" setting is enabled. Previously, enabling this security setting would incorrectly lock subscription orders, preventing further modifications. The fix ensures that subscription orders remain editable regardless of this setting, as intended by the product team.
Original PR description
Steps to reproduce: - Install 'Subscriptions' - Enable 'Lock Confirmed Sales' in the settings - Make a new subscription - Invoice the subscription Issues: The subscription is now locked, this behaviour is not intended. As confirmed with the PO this settings should never affect the subscriptions. Linked PR: https://github.com/odoo/enterprise/pull/58332 opw-3754106 Forward-Port-Of: odoo/odoo#158553 Forward-Port-Of: odoo/odoo#157026
This update fixes the table picker tool to work intuitively in right-to-left languages like Arabic. The table now expands in the correct direction based on the language setting, and arrow key controls are adjusted accordingly. Additionally, spacing issues between table columns in right-to-left mode have been corrected.
Original PR description
Issue: ====== Table picker isn't intuitive in rlt language and doesn't expand in the correct direction. Steps to reproduce the issue: ============================= - Install arabic language - Go to notes and create a new one - Write `/` and choose table - Use left/right arrow keys to see how the table expand. Solution: ========= For rtl direction it's better to make left for increase and right for decrease since that's the direction of the langauge. Also the table should be fixed on the right and expand on the left. (exactly the opposite of ltr direction). Before: ======  After: =====  task-3721794 Forward-Port-Of: odoo/odoo#159468 Forward-Port-Of: odoo/odoo#157400
This update adds a missing Spanish translation for a term used in Chilean invoices. The translation was previously unavailable, which could have caused display issues for Spanish-speaking users in the Latin American region. This fix ensures all invoice text displays correctly in the appropriate language.
Original PR description
Issue ----- A term doesn't have a translation available. Note: no Transifex project associated. **opw-3816657** Forward-Port-Of: odoo/odoo#159147
This fix improves the user experience when someone accidentally tries to upload a folder instead of a file using the /file command in Knowledge. Previously, the upload would fail silently with no error message. Now users will see a clear error notification explaining that only files can be uploaded, not folders.
Original PR description
**Steps to reproduce:** **OS:** Ubuntu 20.04.4 LTS with nautilus **Browser:** Google Chrome Version 123.0.6312.58 - type /file command in knowledge - select a folder and click on open - traceback occurs **Current behavior before PR:** When a user attempts to upload a folder using /file command, the processing begins, but the folder is not uploaded because the `getDataURLFromFile` return promise is not fulfilled. Additionally, there is no indication of any warnings or errors during the folder upload process. **Desired behavior after PR is merged:** If a user attempts to upload a folder instead of a file using the /file command, it results in an error message in the toaster notification. task-3690847 Forward-Port-Of: odoo/odoo#151755
This update improves the SMS sending functionality by adding a database identifier to the SMS API communication. This ensures proper tracking and routing of SMS messages through the system, making the SMS service more reliable and secure.
Original PR description
This commit updates the parameters passed to the IAP SMS API route ("/api/sms/3/send") to include the DB UUID.
Task: 3829793This fix corrects a bug where splitting a manufacturing order into multiple orders resulted in incorrect component quantities. When a manufacturing order to produce 10 units was split into 10 separate orders, each order incorrectly showed component quantities of 0.1 instead of 1. The fix ensures that component quantities are calculated correctly when manufacturing orders are split.
Original PR description
**Steps to Reproduce the Bug:** - Create a BoM: - Product: P1, Quantity: 1 unit - Component: - C1, Quantity: 1 unit - Create a MO to produce 10 units of P1: - This requires 10 units of C1 - In draft…
**Steps to Reproduce the Bug:**
- Create a BoM:
- Product: P1, Quantity: 1 unit
- Component:
- C1, Quantity: 1 unit
- Create a MO to produce 10 units of P1:
- This requires 10 units of C1
- In draft state, split the quantity into 10
**Problem:**
The created MOs have component quantities of 0.1 instead of 1.
When the MO is split, we update the product quantity of the original MO to 1, which triggers the `_compute_move_raw_ids` because it depends on the product_qty of the MO. Therefore, the move will be updated to 1.
https://github.com/odoo/odoo/blob/17.0/addons/mrp/models/mrp_production.py#L1793
Subsequently, the factor is calculated based on the `move_qty` and the `qty_initial` of the MO.
https://github.com/odoo/odoo/blob/17.0/addons/mrp/models/mrp_production.py#L1828
Factor = 1 / 10 = 0.1
Afterwards, this quantity is set on the original move and the backorder moves:
https://github.com/odoo/odoo/blob/17.0/addons/mrp/models/mrp_production.py#L1830
https://github.com/odoo/odoo/blob/17.0/addons/mrp/models/mrp_production.py#L1835
opw-3825708
Forward-Port-Of: odoo/odoo#159492This fix resolves two issues with Saudi invoice printing in foreign currencies: it prevents errors when printing unconfirmed invoices and ensures the correct exchange rate is displayed based on the invoice date rather than the confirmation date. This ensures invoices accurately reflect the currency rates that apply to the actual transaction.
Original PR description
Currently, attempting to print an unconfirmed Saudi invoice in foreign currency results in an error. Furthermore, even if the invoice is confirmed, the exchange rate displayed is not correct, the…
Currently, attempting to print an unconfirmed Saudi invoice in foreign currency results in an error. Furthermore, even if the invoice is confirmed, the exchange rate displayed is not correct, the rate of the confirmation date is used, instead of the accounting date. ### Steps to reproduce * install `l10n_sa_edi` * switch to a Saudi company * create an invoice in a foreign currency. * without confirming the invoice, attempt to print it You should be met with a traceback: `Undefined Function: operator does not exist: date <= boolean` * confirm the invoice, ensuring the confirmation and invoice dates have different currency rates. * print the confirmed invoice.* print the invoice You should see that the printed rate does not align with the actual transaction amounts. ### Cause The system incorrectly uses the `l10n_sa_confirmation_datetime` to calculate and display the currency rate on the PDF. This field is only populated upon invoice confirmation, leading to errors when printing unconfirmed invoices. Moreover, using this date for confirmed invoices results in displaying an incorrect rate, as it may differ from the `invoice_date`, which should be used for accurate rate calculations. opw-3731624 Forward-Port-Of: odoo/odoo#156054
This fix prevents Odoo from sending duplicate SMS messages when users send an SMS from a sales order and don't change the pre-filled phone number. Previously, if the specified number matched the customer's phone number, the system would attempt to send the message twice, causing errors. Now the system correctly recognizes when the additional number is the same as the customer's number and skips the duplicate.
Original PR description
[FIX] sms: prevent sms duplication when using additional numbers When sending an SMS via the action from the sale order view (specifically with sale_subscription), it is possible to specify a number…
[FIX] sms: prevent sms duplication when using additional numbers When sending an SMS via the action from the sale order view (specifically with sale_subscription), it is possible to specify a number to send the SMS to. However, if the specified number is identical to the partner's number (the number of the sale order's customer), Odoo attempts to send the message twice, resulting in duplication. [This commit change] This commit addresses this issue by ensuring that additional numbers are skipped if they are the same as the partner's number. [Reproduce] - Install mass_mailing_sms, sale_management, and sale_subscription modules. - Add an SMS token to the IAP account. - Create a contact (C) with a valid phone number. - Create a new quotation with contact (C) as the partner. - Go to Actions > "Send an SMS Text Message" (requires the sale_subscription module). - Do not change the contact number on the pop-up (ensure it matches C's phone number exactly). - Bug: Odoo attempts to send two SMS messages, with the first being successful and the second resulting in an error. opw-3596207 Forward-Port-Of: odoo/odoo#153429
This fix resolves a system crash that occurred when users tried to add working hours to a newly created work schedule after removing all existing hours. The issue happened because the system attempted a mathematical calculation with zero, which is not allowed. The fix adds a safety check to prevent this error and allows users to successfully add new working hours without the application crashing.
Original PR description
This error occurs when the user adds a new ``Working Schedule`` to the resource, switches to the two-week calendar view, removes all the existing ``Working Hours`` lines, and then attempts to add a…
This error occurs when the user adds a new ``Working Schedule`` to the resource, switches to the two-week calendar view, removes all the existing ``Working Hours`` lines, and then attempts to add a new line under ``Working Hours.``
Steps to reproduce:
- Install ``resource`` module
- Settings -> Technical -> Resource -> Working Schedules
- New -> Switch to 2 week calendar -> Remove all ``Working Hours`` lines
- Click on Add a line
Traceback:
```ZeroDivisionError: float division by zero
File "odoo/http.py", line 2252, in __call__
response = request._serve_db()
File "odoo/http.py", line 1828, in _serve_db
return self._transactioning(_serve_ir_http, readonly=ro)
File "odoo/http.py", line 1848, in _transactioning
return service_model.retrying(func, env=self.env)
File "odoo/service/model.py", line 134, in retrying
result = func()
File "odoo/http.py", line 1826, in _serve_ir_http
return self._serve_ir_http(rule, args)
File "odoo/http.py", line 1833, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "odoo/http.py", line 2058, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
File "odoo/addons/base/models/ir_http.py", line 222, in _dispatch
result = endpoint(**request.params)
File "odoo/http.py", line 740, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "addons/web/controllers/dataset.py", line 38, in call_kw
return self._call_kw(model, method, args, kwargs)
File "addons/web/controllers/dataset.py", line 34, in _call_kw
return call_kw(request.env[model], method, args, kwargs)
File "odoo/api.py", line 458, in call_kw
result = getattr(recs, name)(*args, **kwargs)
File "addons/web/models/models.py", line 1081, in onchange
snapshot1 = RecordSnapshot(record, fields_spec)
File "addons/web/models/models.py", line 1168, in __init__
self.fetch(name)
File "addons/web/models/models.py", line 1183, in fetch
self[field_name] = self.record[field_name]
File "odoo/models.py", line 6671, in __getitem__
return self._fields[key].__get__(self, self.env.registry[self._name])
File "odoo/fields.py", line 1138, in __get__
self.recompute(record)
File "odoo/fields.py", line 1353, in recompute
apply_except_missing(self.compute_value, recs)
File "odoo/fields.py", line 1326, in apply_except_missing
func(records)
File "odoo/fields.py", line 1375, in compute_value
records._compute_field_value(self)
File "odoo/models.py", line 4984, in _compute_field_value
fields.determine(field.compute, self)
File "odoo/fields.py", line 102, in determine
return needle(*args)
File "addons/resource/models/resource_calendar_attendance.py", line 83, in _compute_duration_days
attendance.duration_days = 0.5 if attendance.duration_hours <= attendance.calendar_id.hours_per_day * 3 / 4 else 1
File "odoo/fields.py", line 1138, in __get__
self.recompute(record)
File "odoo/fields.py", line 1353, in recompute
apply_except_missing(self.compute_value, recs)
File "odoo/fields.py", line 1326, in apply_except_missing
func(records)
File "odoo/fields.py", line 1375, in compute_value
records._compute_field_value(self)
File "odoo/models.py", line 4984, in _compute_field_value
fields.determine(field.compute, self)
File "odoo/fields.py", line 102, in determine
return needle(*args)
File "addons/resource/models/resource_calendar.py", line 109, in _compute_hours_per_day
calendar.hours_per_day = calendar._get_hours_per_day(attendances)
File "addons/resource/models/resource_calendar.py", line 185, in _get_hours_per_day
return float_round(hour_count / float(number_of_days), precision_digits=2)
```
This commit implements a check for the variable ``number_of_days``. If the value of ``number_of_days`` is zero or not found, the function will return zero. This ensures that the function behaves appropriately in cases where the number of days is zero.
https://github.com/odoo/odoo/blob/5177e21aea68959eedc73e0034ed984992392dd7/addons/resource/models/resource_calendar.py#L185
sentry - 5108250957
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis update fixes an issue in the recruitment survey process where retaking a survey would lose the connection to the original applicant. Previously, only the first survey attempt would be properly linked to the applicant, but now all survey retakes maintain the correct applicant ID association. This ensures complete and accurate tracking of all candidate survey responses.
Original PR description
Description of the issue/feature this PR addresses: - module: hr_recruitment_survey Current behavior before PR: - when retaking the survey, the survey input not map with the applicant id, so if you retake 5 time, only the 1st survey has value of applicant_id Desired behavior after PR is merged: - all survey retakes have the same applicant id --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update corrects inaccurate information in the Stripe payment module's documentation. The README contained an incorrect description of the payment flow process, which has been fixed to accurately reflect how Stripe payments are processed in Odoo. This ensures users and administrators have reliable documentation when setting up and managing Stripe payments.
Original PR description
Forward-Port-Of: odoo/odoo#159621
This fix resolves an issue where the sales report tree view was not accessible, preventing users from exporting sales data to Excel or viewing individual report lines. The fix restores the ability to interact with and export sales reports, improving data accessibility for business users.
Original PR description
Description of the issue/feature this PR addresses: Before this commit, it is not possible to export sale.report by excel or show the lines. @Feyensv --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#157870
This update fixes a test failure in the inventory system's test suite that was causing errors when running the unpacking and quantity history test. The fix ensures the test runs reliably without encountering index errors, improving the stability of the inventory testing process.
Original PR description
Test 'test_unpack_and_quants_history' may fail with error
```
ERROR: StockQuant.test_unpack_and_quants_history
Traceback (most recent call last):
File "/data/build/odoo/addons/stock/tests/test_quant.py", line 926, in test_unpack_and_quants_history
dst_location = stock_location.child_ids[0]
File "/data/build/odoo/odoo/models.py", line 6189, in __getitem__
return self.browse((self._ids[key],))
IndexError: tuple index out of range
```
Forward-Port-Of: odoo/odoo#159611This fix resolves a bug where border and rounded corner styling options were being reset to zero after being applied to text elements in the web editor. The issue occurred because styling properties were being incorrectly cleared each time the styling function was called. This update restores the proper handling of styling options so they persist correctly when users apply borders or rounded corners to content blocks.
Original PR description
Since [1], the `extraClass` is handled globally across all properties of a composite option such as "Border" or "Round Corners". But [2] did reset the `extraClass` each time `applyCSS` is called. Because of this, the `extraClass` is now missing after setting a "Border" or a "Round Corner". This commit reverts [2] partially to remove the `extraClass` handling from within the `applyCSS` function. Steps to reproduce: - Drop a "Text - Image" block. - Select the text. - Set a "Border". => The "Border" option is reset to 0. [1]: https://github.com/odoo/odoo/commit/2a6355c36ebfc4397451289589ebbeaa2afc1396 [2]: https://github.com/odoo/odoo/commit/d3c3dab8950abc25b29937605091d8ce32305fa4 task-3800288 Forward-Port-Of: odoo/odoo#159657 Forward-Port-Of: odoo/odoo#159452
The live chat chatbot was stopping unexpectedly when redirecting users to different sections of the same page (like anchor links). This fix ensures the chatbot continues working properly in these scenarios by removing the dependency on page reloads that don't occur during same-page redirects.
Original PR description
Before this PR, the chat bot would stop after redirecting a user on the same page that the current one (e.g. anchors) because it was counting on the page reload that do not occur in this case. This PR fixes the issue. opw-3801598 Forward-Port-Of: odoo/odoo#159644 Forward-Port-Of: odoo/odoo#159320
This update improves the Italian EDI invoice import feature to correctly handle both incoming and outgoing invoices. Previously, the system assumed all imported invoices were bills (incoming). Now it intelligently determines whether an imported invoice is outgoing or incoming and processes it accordingly, enabling businesses to import invoices from other software systems during onboarding or data migration.
Original PR description
Currently we assume that all imported invoices are incoming (i.e. bills). This was i.e. done since the tax agency only sends users bills. But some clients import invoices from other software (i.e. onboarding/starting). After this PR we decide whether the invoice is outgoing or ingoing and import the invoice correctly in either case. Link: https://www.odoo.com/web#model=project.task&id=3650355 task-3650355 Forward-Port-Of: odoo/odoo#159737 Forward-Port-Of: odoo/odoo#151139
This fix resolves an issue where journals without system identifiers were not being properly matched during chart reloads, which could result in duplicate journals and database errors. The fix improves the matching logic to compare journal names and codes against translated values in addition to the default language, ensuring accurate identification of existing journals during the reload process.
Original PR description
Currently there is the following problem when reloading the chart. Journals without xmlid may not be matched to chart data correctly (via code or name). This then leads to duplicate journals being…
Currently there is the following problem when reloading the chart. Journals without xmlid may not be matched to chart data correctly (via code or name).
This then leads to duplicate journals being created / uniqueness constraint issues on journal codes.
The matching happens in `_pre_reload_data`.
This should only be a problem for upgrade or user created journals since journals created from the chart data have an xmlid.
The problem was introduced in commit d6695f2892ded178371f6c69cf594037c19ce438 :
- (1) We load the chart data in en_US to be able to use the code translations
- (2) We switched the language of the loading process to en_US
(to switch the chart data to en_US for the previous point and to
avoid inconsistencies)
When matching journals in the DB by code or name to the chart data:
- We fetch the en_US name of the journals in the DB due to (2); Code is not translatable.
- We compare those values (journal code / name) against the en_US term due to (1).
Thus the matching fails.
This commit improves the matching:
We also compare the name and code (still en_US version) against the translated values.
Forward-Port-Of: odoo/odoo#159738
Forward-Port-Of: odoo/odoo#159635Documentation and clarification updates
This update adds new members to the Adhoc Contributor License Agreement (CLA) document. The change ensures that all contributors who have signed the CLA are properly recorded in the corporate CLA registry, maintaining accurate records of legal agreements with contributing organizations.
Original PR description
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#156175