Daily updates from Odoo
Navigate
Branch
Monday, September 15, 2025
193 changes
14 changes
Enhancements to existing features
The Argentina electronic invoicing module now includes renewed demo and testing certificates needed to connect to ARCA's test services. This prevents test invoicing processes from failing due to expired certificates and keeps validation environments available.
Original PR description
Homologation certificates are required to connect Odoo with ARCA's test web services. When they expire, electronic invoicing tests fail, displaying a “Digital certificate expired” warning. In this PR, I'm updating the certificates so we can continue using the testing environment for our tests. Odoo Task 1359 Adhoc Task 57144 Forward-Port-Of: odoo/enterprise#94128
Documents and items in the trash now use their creation date as the default sort order. This keeps lists more stable, since small edits such as adding tags or renaming items no longer move older documents to the top.
Original PR description
As the write_date can be reset by very small changes like adding a tag, updating its name and also during some upgrade, we set the default ordering to create_date. We do similarly for the trash. Task-5025453 Forward-Port-Of: odoo/enterprise#93952 Forward-Port-Of: odoo/enterprise#92840
Resolved issues and error corrections
The website editor now shows the correct size when users choose the Small text option in a banner. This fixes a visual mismatch so content editors can rely on the displayed font size matching the intended design.
Original PR description
Steps to reproduce: 1. Drop a Banner snippet 2. Select the text and change the size to "Small" - The font size is shown as 16px instead of 14px Cause: The "Small" font size was calculated using `em`, while other sizes were calculated using `rem`. Fix: Use `rem` for the small font size as well, ensuring consistent calculation across all font sizes. | Before | After | |-----------------------------|---------------------------------| | <img width="545" height="604" alt="image" src="https://github.com/user-attachments/assets/0f6b754c-e010-490f-aac1-ee0b9ba80d72" />| <img width="545" height="613" alt="image" src="https://github.com/user-attachments/assets/0ee4c756-965e-48c5-8764-3085b49a3c48" /> |
This fixes a small rounding issue in the HTML editor when converting CSS size values between units. Values entered by users are now preserved more accurately after saving, reducing unexpected tiny changes in layout settings.
Original PR description
Before this commit: The generic CSS unit converter was rounding intermediate values to three decimal places, which caused a slight discrepancy when converting values back and forth between units. As a result, the values shown upon saving differed from the originally entered values. For example, converting 19px yielded 1.188rem, which then converted back to 19.008px. After this commit: By increasing the rounding precision from three to five decimal places, round-trip conversions across all supported CSS units now maintain the expected values. For instance, 19px will convert to 1.18750rem and back to 19px. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The website editor now shows font size values as clean whole pixels after conversion, instead of small decimal drift such as 45.008 px. This avoids confusion for users adjusting theme settings and makes displayed design values match what they entered.
Original PR description
Steps to reproduce: - Go to Website > Edit - Open the Theme tab - Set the font size to 45 px - Notice the value changes to 45.008 Fix rounding drift in "Font size" inputs. Values are now displayed as whole px after rem > px conversion (e.g. 45 > 45 px instead of 45.008 px).
Imported sales orders now keep the original price when a product from a purchase request cannot be matched in the sales database. This prevents affected order lines from incorrectly showing a zero price, helping sales teams avoid underbilling and manual corrections.
Original PR description
Steps: - Install Purchase in first db and sale in second db. - Ensure RFQ contain product which does not exist in second db. - Export RFQ and import it in sale order view. Issue: - Price is always 0 on sol if it didn't find related product. Cause: - In [this] PR we always recompute price on all sol instead sol with product Fix: - Recompute price and discount only on sol with product. [this]: https://github.com/odoo/odoo/pull/190310
This fixes an issue in Odoo Studio where choosing a measure for a cohort view could trigger an error because the list showed incompatible fields. It also removes an unnecessary request parameter that caused warning messages when creating new views.
Original PR description
Currently, an error occurs when user tries to select any measure in cohort view. Steps to replicate: - Install `sale_management` and `web_studio`. - Open the Sales app and turn on studio mode. -…
Currently, an error occurs when user tries to select any measure in cohort view. Steps to replicate: - Install `sale_management` and `web_studio`. - Open the Sales app and turn on studio mode. - Under the Views tab, turn on cohort view. - Under the Measures field, select any value and observe the error appearing in the terminal. Error: `ValueError: Invalid aggregate method 'None' for 'create_date:None'` Cause: - The Measure field dropdown in the Cohort Editor was mistakenly assigned the choices of `dateFields` [1] instead of `measureFields`. - This allowed users to select incompatible field types (e.g., date/datetime), which lead to error in aggregation behavior in the cohort view. Solution: - Corrected the choices of Measure field to `measureFields`. - Also added a condition to allow only those fields that have an aggregator (for some fields like `sequence` that dont have an aggregator). - Also removed context field from arguments [2] in the rpc call as function doesnt need it [3] (This shows warning on runbot as well). [1]: https://github.com/odoo/enterprise/blob/d8539dff5f3dcecfeb99fd7fc22a6915aaa02c4b/web_studio/static/src/client_action/view_editor/editors/cohort/cohort_editor_sidebar.xml#L30 [2]: https://github.com/odoo/enterprise/blob/bf9510e152279418200cb0becb6b637c19b02d4e/web_studio/static/src/client_action/editor/new_view_dialogs/new_view_dialog.js#L87 [3]: https://github.com/odoo/enterprise/blob/bf9510e152279418200cb0becb6b637c19b02d4e/web_studio/controllers/main.py#L805 sentry-6781792463 Forward-Port-Of: odoo/enterprise#94450 Forward-Port-Of: odoo/enterprise#91599
Changing an expense product's policy no longer recalculates and overwrites the analytic distribution on existing expenses. This preserves previously entered expense analytics while still applying the correct default analytics to newly created expenses.
Original PR description
When changing the expense policy of an expense product, the compute of analytic distribution of all expenses linked to the product is triggered. Steps: - Have an expense product X with expense policy…
When changing the expense policy of an expense product, the compute of analytic distribution of all expenses linked to the product is triggered. Steps: - Have an expense product X with expense policy 'at_sales' - Create several expenses with an expense product X and any analytic account - Create an analytic distribution model that link the expense account of X with a specific analytic account AA - Create a new expense for product X, the analytic account AA should be set from the distribution model - Go to the form view of product x and change the expense policy to 'cost' - Go back to the expense list view -> All expenses having the product X have the AA account Cause: `sale_order_id` has been added to the `depends` of `hr_expense._compute_analytic_distribution` by 2b3bf5e0fe31d4b4ef6b487da493657f695b14e1 but this wrong since we have the `sale_expense._onchange_sale_order_id` that add the `analytic_dostribution` field to the fields to be computed. The compute is triggered since we change `product_id.expense_policy`, which triggers the `_compute_can_be_reinvoiced` which triggers the `_compute_sale_order_id` Fix: With this commit, we emove the depends on the compute and we also adapt `test_compute_analytic_distribution_expense` in a way that it triggers the onchange as we do in the original flow. opw-4998899 Forward-Port-Of: odoo/odoo#226864 Forward-Port-Of: odoo/odoo#224226
Payroll work entry processing no longer performs a multi-contract validation that is not applicable. This avoids unnecessary blocking or confusion in a scenario the system does not support.
Original PR description
The multi contract is not possible, so removed the check. task-5073952 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The active mobile icon in the website editor now uses a clearer color again. This restores contrast so users can more easily see which mobile view option is selected.
Original PR description
The active state of the mobile icon lost sufficient contrast. This PR restores its previous color to improve visibility.
Barcode operation lines now show the correct product name in their descriptions. This helps warehouse users identify items more reliably during scanning and reduces confusion in stock handling.
Original PR description
Task-4901289
Indonesian e-Faktur downloads no longer fail when an invoice line has multiple non-luxury taxes. This prevents a crash during document export and helps users complete compliant invoicing without manual workarounds.
Original PR description
The system crashes with an error when a user tries to `download the e-Faktur` document. **Steps to produce:-** - Install `Accounting` and switch to `ID Company`(with demo data). - Create a `new…
The system crashes with an error when a user tries to `download the e-Faktur` document.
**Steps to produce:-**
- Install `Accounting` and switch to `ID Company`(with demo data).
- Create a `new invoice` and select customer as `ID Company`.
- Add the product and in `taxes add 11% and 0% (2 non-luxury taxes)` and confirm the invoice.
- Click on gear icon and click on `Download e-Faktur` button.
**Error:-**
`ValueError: ValueError('Expected singleton: account.tax(5, 15)') while
evaluating 'action = records.download_efaktur()'`
**Root cause:-**
- When more than one non-luxury tax is applied and the e-Faktur document is downloading, the code at [1] expects a single tax record, but multiple non-luxury taxes are found.
**Solution:-**
- Since luxury tax is already excluded from the regular tax computation at [2], I think we can directly sum all non-luxury taxes.
[1]: https://github.com/odoo/odoo/blob/52aa6231130ea165fdb44e6370ec3e396b7603cc/addons/l10n_id_efaktur_coretax/models/account_move_line.py#L52
[2]: https://github.com/odoo/odoo/blob/52aa6231130ea165fdb44e6370ec3e396b7603cc/addons/l10n_id_efaktur_coretax/models/account_move_line.py#L24-L25
**sentry-6837559933**
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#224419Appointment booking notification emails are now limited to the staff followers who need to know a new appointment was created. This prevents appointment attendees from receiving an internal “Appointment Booked” email that was not meant for them, reducing confusion and improving communication accuracy.
Original PR description
[1] introduces the new paradigm of always sending emails to "relevant recipients" which fetches emails and partners linked to the relevant record to send a message.
In appointment the "Appointment Booked" template is only meant to be sent to followers of `mt{_calendar,_appointment}_event_booked` to inform users that a new appointment was created even if they are not personally assigned to it.
`test_request_meeting_message_for_manual_confirmation` is also updated to represent the case of some visitor creating booking an appointment instead of using internal users for everything to better represent real use cases. Additionally each mail.mail record is extracted and checked individually to make sure we send the right contents to the right recipients.
[1]: 1dd6070ecaab385446cc2df7cad444f046812061
task-5075513
task-4711415
Forward-Port-Of: odoo/enterprise#94456This fixes an issue where invoice attachments from reconciled accounting entries appeared in the regular chatter of related credit notes. Attachments from reconciled moves are now shown only in the bank reconciliation view, keeping standard accounting records cleaner and less confusing.
Original PR description
Problem --------- In odoo/enterprise#85991, attachments from reconciled moves were displayed in the chatter along side the moves' attachments. This change was meant to affect only the bank reco widget. However, its scope reached the standard accounting behavior. STEPS --------- 1. Have 'account' installed 2. Create a move 3. Confirm and create the PDF attachment from the Send&Print 4. Create a credit note from it 5. Confirm the credit note -> The 2 moves are now reconciled and the PDF of the invoice is shown in the chatter of the credit note Objective --------- Only show reconciled moves' attachments in the bank reco chatter. Solution --------- Add a context key that is added when the Bank Reco widget is created and remove it when it is deleted. opw-####### Forward-Port-Of: odoo/enterprise#94442
19 changes
Enhancements to existing features
Point of Sale users can now reopen configurable and combo products from an order line to adjust choices without starting over. Matching edited lines are merged automatically, prices are handled more reliably, and custom text selections are preserved after refreshes.
Original PR description
Task: [#4890396](https://www.odoo.com/odoo/my-tasks/4890396) Community PR: [#221924](https://github.com/odoo/odoo/pull/221924) --- Improves the POS experience by allowing users to reopen and edit…
Task: [#4890396](https://www.odoo.com/odoo/my-tasks/4890396) Community PR: [#221924](https://github.com/odoo/odoo/pull/221924) --- Improves the POS experience by allowing users to reopen and edit configurable and combo products directly from their orderlines. When a product is edited to match another existing line, the lines are automatically merged to avoid duplicates. - Introduced `useTimedPress` to support both click and long press interactions. - Reopening a configurator now pre-fills default attributes, custom values, and combo selections. - Removed click delay when selecting an orderline, improving responsiveness. - Extracted logic for configurator, combo choice, unit price computation, and orderline merging from `addProductToOrder` into dedicated functions (`tryMergeOrderline`, etc.) for reuse across the codebase. --- The Combo/Product Configurator popups no longer receive default values directly. Instead, they now work with the orderline passed as a prop. ** Combo Configurator Popup ** - Use `props.line.selectedComboIds` as the source for default values. - Save the initial `state.combo` so it can be restored on discard. - Add a **Discard** button in the popup footer. ** Product Configurator Popup ** - Use `props.line.selectedAttributes` for the default values. - If there is no orderline like new combo item, fall back to `props.comboItem?.saveStateAttributes`. - Save the initial `state.selectedAttributes` so it can be restored on discard. - Expose `selectedAttributes` on `pos.orderline` as a function so it can be recomputed at any time. ** Bug Fix: Price ** - Fixed a bug where updating a combo item directly from the Order Summary used the wrong price (ignoring the combo). - We now open the **Combo Configurator** instead of the **Product Configurator** when editing a combo item from the Order Summary. --- When refreshing the page, we also lose the `free text` of the `custom_attribute_value`. By adding the model `product.attribute.custom.value` to the `get databaseTable()` from `DataServiceOptions`, we ensure that the records are saved in IndexedDB Forward-Port-Of: odoo/odoo#221924
The Argentina electronic invoicing module now includes renewed demo and test certificates for ARCA's testing services. This prevents test failures caused by expired certificates and keeps the certification environment available for validation work.
Original PR description
Homologation certificates are required to connect Odoo with ARCA's test web services. When they expire, electronic invoicing tests fail, displaying a “Digital certificate expired” warning. In this PR, I'm updating the certificates so we can continue using the testing environment for our tests. Odoo Task 1359 Adhoc Task 57144 Forward-Port-Of: odoo/enterprise#94128
Point of Sale now cleans up internal record links more efficiently during bulk updates. This helps prevent slowdowns when sales sessions involve many related records, improving reliability for busy retail operations.
Original PR description
When the “set” command is used, we will manually clean up the indexes to avoid performance issues when there are too many associated records. Forward-Port-Of: odoo/odoo#226958 Forward-Port-Of: odoo/odoo#225854
Documents and trash views now use the creation date as the default order instead of the last modified date. This keeps document lists more stable because minor updates, such as tag or name changes, will no longer unexpectedly move items around.
Original PR description
As the write_date can be reset by very small changes like adding a tag, updating its name and also during some upgrade, we set the default ordering to create_date. We do similarly for the trash. Task-5025453 Forward-Port-Of: odoo/enterprise#93952 Forward-Port-Of: odoo/enterprise#92840
This update adds automated test coverage for the self-ordering point-of-sale experience, helping catch issues earlier before they affect customers or staff. It also separates printer-related logic to make testing safer and reduce conflicts with the main point-of-sale system.
Original PR description
- Isolated `printer` service into a standalone file to avoid naming conflicts with `point_of_sale` during tests. - Introduced `setupSelfPosEnv` to mock and bootstrap the self-order testing environment. - Add Hoot test coverage for core components, models, and service logic Task-4945633
Resolved issues and error corrections
This fix prevents appointment-related upgrades or mail template updates from failing when calendar events use custom video call links from Google Calendar. It ensures existing events can be processed safely, reducing upgrade disruption for customers using appointments and calendar integrations.
Original PR description
**Steps to Reproduce:** 1. Create DB in 18.0 with calendar module and google_calendar without demo data. 2. create a calendar event with videocall location other then odoo generated and mark that as…
**Steps to Reproduce:**
1. Create DB in 18.0 with calendar module and google_calendar without demo data.
2. create a calendar event with videocall location other then odoo generated and mark that as guest_readonly.
3. after that install appointment module and ``acces_token``.
4. upgrade to 18.3 below mentioned traceback will raise or can update to mail template.
**Issue**
why from 18.3 [from](https://github.com/odoo/odoo/commit/999df6d4a3b5d21648e5e09757661714e99e1154#diff-bd520efea06a5449c8694b54f5f7aa8587c929a5669ea0439bb9d5e38f8d29c8) this commit now template will render on record for checking. During render checking the ``videocall_redirection`` field value as it [compute](https://github.com/odoo/enterprise/blob/f5d99ea7ae7c2748c4a23a793c46ab1a123b3aad/appointment/models/calendar_event.py#L188) and non store field it going for compute over here the access_token is missing so it will go for compute and during that this [validation](https://github.com/odoo/odoo/blob/1ac89eb71aab48fa8d50fbae01d96bec23d88418/addons/google_calendar/models/calendar.py#L106) is triggering and it breaking because env user is odoobot and user_id is different this issue occur during checking on write on mail template.
**Fix:**
For fixing this no need to assign standard ``videocall_redirection`` as ``video_location`` is custom
```
File "/home/odoo/src/odoo/saas-18.4/odoo/orm/fields.py", line 1751, in __get__
self.compute_value(recs)
File "/home/odoo/src/odoo/saas-18.4/odoo/orm/fields.py", line 1914, in compute_value
records._compute_field_value(self)
File "/home/odoo/src/odoo/saas-18.4/addons/calendar/models/calendar_event.py", line 696, in _compute_field_value
return super()._compute_field_value(field)
File "/home/odoo/src/odoo/saas-18.4/addons/mail/models/mail_thread.py", line 469, in _compute_field_value
return super()._compute_field_value(field)
File "/home/odoo/src/odoo/saas-18.4/odoo/orm/models.py", line 4620, in _compute_field_value
determine(field.compute, self)
File "/home/odoo/src/odoo/saas-18.4/odoo/orm/fields.py", line 81, in determine
return needle(*args)
File "/home/odoo/src/enterprise/saas-18.4/appointment/models/calendar_event.py", line 207, in _compute_videocall_redirection
event.access_token = uuid.uuid4().hex
File "/home/odoo/src/odoo/saas-18.4/odoo/orm/fields.py", line 1847, in __set__
records.write({self.name: write_value})
File "/home/odoo/src/enterprise/saas-18.4/appointment/models/calendar_event.py", line 246, in write
res = super().write(vals)
File "/home/odoo/src/odoo/saas-18.4/addons/google_calendar/models/calendar.py", line 96, in write
self._check_modify_event_permission(values)
File "/home/odoo/src/odoo/saas-18.4/addons/google_calendar/models/calendar.py", line 108, in _check_modify_event_permission
raise ValidationError(_("The following event can only be updated by the organizer "
odoo.exceptions.ValidationError: El organizador es el único que puede actualizar el siguiente evento de acuerdo con los permisos del evento establecidos en Google Calendar.
```
opw-5042454
upg-3113613
TBG - 2082Opening and saving the Optimize SEO dialog no longer accidentally clears image descriptions added in the website editor. This protects accessibility and search-related content from being lost when users revisit SEO settings.
Original PR description
Steps to reproduce: 1. Open Optimize SEO. 2. Mark an image as decorative. 3. Save it. 3. Give a description(ALT) to that image from editor. 4. Open Optimize SEO again and save without doing anything. Issue: The description(ALT) on the image being set is lost. Cause: When reopening the **Optimize SEO** dialog, `seoContext.updatedAlts` still contained entries from previous edits. As a result, saving without making any change triggered an call to `update_alt_images` which reset the `alt` attribute to empty, eventually discarding the description. This PR ensures `seoContext.updatedAlts` is reset when opening the dialog.
This fix updates the sales test to match Odoo’s actual behavior: down-payment lines are based on the invoice accounting date, not the sales order creation date. It helps ensure automated checks correctly reflect how invoice-related dates are handled, reducing false build failures.
Original PR description
Because the test was asserting against the Sale Order creation date, while Odoo actually uses the invoice’s accounting date when updating the down-payment line. build_error-231505
This fixes a crash when Indonesian invoices with more than one non-luxury tax are used to download an e-Faktur document. Users can now complete the e-Faktur download flow without hitting an unexpected system error in this tax setup.
Original PR description
The system crashes with an error when a user tries to `download the e-Faktur` document. **Steps to produce:-** - Install `Accounting` and switch to `ID Company`(with demo data). - Create a `new…
The system crashes with an error when a user tries to `download the e-Faktur` document.
**Steps to produce:-**
- Install `Accounting` and switch to `ID Company`(with demo data).
- Create a `new invoice` and select customer as `ID Company`.
- Add the product and in `taxes add 11% and 0% (2 non-luxury taxes)` and confirm the invoice.
- Click on gear icon and click on `Download e-Faktur` button.
**Error:-**
`ValueError: ValueError('Expected singleton: account.tax(5, 15)') while
evaluating 'action = records.download_efaktur()'`
**Root cause:-**
- When more than one non-luxury tax is applied and the e-Faktur document is downloading, the code at [1] expects a single tax record, but multiple non-luxury taxes are found.
**Solution:-**
- Since luxury tax is already excluded from the regular tax computation at [2], I think we can directly sum all non-luxury taxes.
[1]: https://github.com/odoo/odoo/blob/52aa6231130ea165fdb44e6370ec3e396b7603cc/addons/l10n_id_efaktur_coretax/models/account_move_line.py#L52
[2]: https://github.com/odoo/odoo/blob/52aa6231130ea165fdb44e6370ec3e396b7603cc/addons/l10n_id_efaktur_coretax/models/account_move_line.py#L24-L25
**sentry-6837559933**
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#224419Refreshing a page in Odoo will now keep users in the correct app menu when several apps share the same underlying customer or partner screen. This prevents confusion where, for example, a Sales customer page could reload under the Invoicing menu instead of Sales.
Original PR description
* STEP TO REPRODUCE: install sale management module, go to sale app -> customer menu -> Then reloading the page using F5 -> the menu is change to invoice which is not correct * Also Multiple modules (Sale, Account, Purchase) share same actions (e.g. partner action) * SOLUTION: Modified webclient.js action-to-menu mapping to handle multiple menus sharing same action 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#226391 Forward-Port-Of: odoo/odoo#225984
Reloading shared customer screens now keeps users in the correct app menu instead of switching to another app such as Invoicing. This prevents confusion when Sales, Accounting, and Purchase share the same underlying customer action.
Original PR description
* STEP TO REPRODUCE: install sale management module, go to sale app -> customer menu -> Then reloading the page using F5 -> the menu is change to invoice which is not correct * Also Multiple modules (Sale, Account, Purchase) share same actions (e.g. partner action) * SOLUTION: - Modified webclient.js action-to-menu mapping to handle multiple menus sharing same action Forward-Port-Of: odoo/enterprise#94485
This fix ensures Uruguayan electronic invoices correctly recognize document numbers that start with multiple letters. It helps prevent incorrect processing or validation of affected EDI documents, improving reliability for companies using Uruguay localization.
Original PR description
If UY EDI document has latam document number with more than one letter at the beggining, it is needed to take in consideration all the letters and not only the first one. Task Latam side: 1352 Task Adhoc side: 53173 Forward-Port-Of: odoo/enterprise#90696
Event invitation emails now use embedded images instead of external icon styling that many email clients do not support. This prevents missing or duplicate location icons in the email editor and helps recipients see the intended event location details clearly.
Original PR description
Font awesome classes must no be inserted into email as external servers do not use them so icons are not displayed and also because some issues occur with the email editor. This commit replaces i tags with font awesome classes in mail by images. Task-5082165 Forward-Port-Of: odoo/odoo#226332
Purchase orders created from the product catalog now keep the same unit of measure shown and selected in the catalog. This prevents accidental ordering of vendor packs when the buyer intended individual units, improving order accuracy and reducing correction work.
Original PR description
Steps to reproduce the bug:
- Create a storable product “P1”:
- UoM: unit
- Purchase tab:
- Vendor: Azure interior
- UoM: Pack of 6
- Create a purchase order:
- Vendor: Azure interior
- Click the Catalog button:
- Select 1 unit of P1 (note: UoM cannot be changed in the catalog)
Problem:
The purchase order line is created, but with 1 pack of 6 instead of 1 unit
Fix:
Ensure the selected product quantity and UoM from the catalog are correctly applied to the PO line.
Opw-4794362
Forward-Port-Of: odoo/odoo#224231Event searches now show consistent results whether users select from the search dropdown or press Enter. Events that match the search term in their description are now included on the results page, reducing confusion and helping visitors find relevant events more reliably.
Original PR description
Purpose ======= Making sure that, when typing a search term, all the results displayed in the search bar dropdown are visible on the page when clicking Enter. Specification ============= Previously, the search bar dropdown was displaying all the events where the name or description matched the search term. However, when clicking Enter, only the events where the name matched were displayed on the page (the ones where only the description matched were ignored). Fixing the issue by considering the description in the event search options. Task-5039221 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#224414
The spreadsheet interface is now kept in light mode because dark mode is not supported there. This prevents mixed dark and light styling, making spreadsheets look more consistent and easier to use.
Original PR description
Spreadsheet doesn't support dark theme. This fixes some style where dark and light themes are mixed. Task: 5082593 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#226798
This fixes an issue where tapping Send in Odoo's messaging composer on iOS when used as a Progressive Web App could sometimes miss the button. The send area no longer shifts unexpectedly when the keyboard focus changes, making message sending more dependable in Discuss and chatter.
Original PR description
Before this commit, when using IOS PWA, pressing 'Send' button of in composer in discuss or chatter would sometimes not register the send. This happens because in IOS PWA, the composer has a bottom margin as this is close to iOS persistent swipe bar. However, the margin should not be present when there's the soft-keyboard. Because of this dynamic margin based on input focus, when composing textual message and pressing "Send" button, the textarea looses focus and a fraction of second the margin-bottom is increased and moves the "Send" button. This leads to mis-clicking the "Send" button. This commit removes the margin-bottom rule on non-focusin of textarea with iOS PWA. The composer is close to swipe bar so that's not as elegant as before, but at least this doesn't add the problem of non- working "Send" button. opw-5028809 Forward-Port-Of: odoo/odoo#226881 Forward-Port-Of: odoo/odoo#226546
Users can now open assigned activities from "View all activities" even when they do not have permission to access the related record. This prevents an error and still lets them complete the activity using the appropriate activity form.
Original PR description
**Steps to reproduce** 1. Create an activity on a record and assign it to a user who doesn't have access to this record. (e.g. create an activity on a `hr.employee` record and assign to a user without HR rights). 2. With this user lacking access rights, click on "View all activities" in the systray. 3. Click on the activity: error **Cause** The user may not have access rights to the record related to an activity. **Change** Open the activity's form view, we use `mail_activity_view_form_without_record_access` to display the "Mark as done" button. opw-4925744 Forward-Port-Of: odoo/odoo#222649
This fix prevents certain Google Calendar events from blocking upgrades or mail template updates when appointment video call links are checked in the background. It ensures permission validation only applies to fields that actually need Google Calendar synchronization, reducing unexpected errors for users with read-only guest events.
Original PR description
**Steps to Reproduce:** 1. Create DB in 18.0 with calendar module and google_calendar without demo data. 2. create a calendar event with videocall location other then odoo generated and mark that as…
**Steps to Reproduce:**
1. Create DB in 18.0 with calendar module and google_calendar without demo data.
2. create a calendar event with videocall location other then odoo generated and mark that as guest_readonly.
3. after that install appointment module and ``acces_token``.
4. upgrade to 18.3 below mentioned traceback will raise or can update to mail template.
**Issue**
why from 18.3 [from](https://github.com/odoo/odoo/commit/999df6d4a3b5d21648e5e09757661714e99e1154#diff-bd520efea06a5449c8694b54f5f7aa8587c929a5669ea0439bb9d5e38f8d29c8) this commit now template will render on record for checking. During render checking the ``videocall_redirection`` field value as it [compute](https://github.com/odoo/enterprise/blob/f5d99ea7ae7c2748c4a23a793c46ab1a123b3aad/appointment/models/calendar_event.py#L188) and non store field it going for compute over here the access_token is missing so it will go for compute and during that this [validation](https://github.com/odoo/odoo/blob/1ac89eb71aab48fa8d50fbae01d96bec23d88418/addons/google_calendar/models/calendar.py#L106) is triggering and it breaking because env user is odoobot and user_id is different this issue occur during checking on write on mail template.
**Fix:**
For fixing this checking is the fields syncable with calendar or not
```
File "/home/odoo/src/odoo/saas-18.4/odoo/orm/fields.py", line 1751, in __get__
self.compute_value(recs)
File "/home/odoo/src/odoo/saas-18.4/odoo/orm/fields.py", line 1914, in compute_value
records._compute_field_value(self)
File "/home/odoo/src/odoo/saas-18.4/addons/calendar/models/calendar_event.py", line 696, in _compute_field_value
return super()._compute_field_value(field)
File "/home/odoo/src/odoo/saas-18.4/addons/mail/models/mail_thread.py", line 469, in _compute_field_value
return super()._compute_field_value(field)
File "/home/odoo/src/odoo/saas-18.4/odoo/orm/models.py", line 4620, in _compute_field_value
determine(field.compute, self)
File "/home/odoo/src/odoo/saas-18.4/odoo/orm/fields.py", line 81, in determine
return needle(*args)
File "/home/odoo/src/enterprise/saas-18.4/appointment/models/calendar_event.py", line 207, in _compute_videocall_redirection
event.access_token = uuid.uuid4().hex
File "/home/odoo/src/odoo/saas-18.4/odoo/orm/fields.py", line 1847, in __set__
records.write({self.name: write_value})
File "/home/odoo/src/enterprise/saas-18.4/appointment/models/calendar_event.py", line 246, in write
res = super().write(vals)
File "/home/odoo/src/odoo/saas-18.4/addons/google_calendar/models/calendar.py", line 96, in write
self._check_modify_event_permission(values)
File "/home/odoo/src/odoo/saas-18.4/addons/google_calendar/models/calendar.py", line 108, in _check_modify_event_permission
raise ValidationError(_("The following event can only be updated by the organizer "
odoo.exceptions.ValidationError: El organizador es el único que puede actualizar el siguiente evento de acuerdo con los permisos del evento establecidos en Google Calendar.
```
opw-5042454
upg-3113613
TBG - 2082
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr5 changes
Enhancements to existing features
The Argentina electronic invoicing module now includes renewed demo and testing certificates needed to connect to ARCA's test services. This prevents test environment failures caused by expired certificates, helping teams keep electronic invoicing validation running reliably.
Original PR description
Homologation certificates are required to connect Odoo with ARCA's test web services. When they expire, electronic invoicing tests fail, displaying a “Digital certificate expired” warning. In this PR, I'm updating the certificates so we can continue using the testing environment for our tests. Odoo Task 1359 Adhoc Task 57144 Forward-Port-Of: odoo/enterprise#94128
Resolved issues and error corrections
This fixes how Uruguayan electronic invoice document numbers are read when they start with more than one letter. It helps ensure affected invoices, credit notes, and debit notes are generated and processed with the correct official numbering.
Original PR description
If UY EDI document has latam document number with more than one letter at the beggining, it is needed to take in consideration all the letters and not only the first one. Task Latam side: 1352 Task Adhoc side: 53173 Forward-Port-Of: odoo/enterprise#90696
Fixes an issue that could prevent Italian companies from posting tax return closing entries. The tax return search is now evaluated correctly, avoiding an error during the closing entry posting process.
Original PR description
The `osv.expression.AND` operator was incorrectly used, leading to an invalid search domain and raising an error. Steps to reproduce: - Set the company country to Italy - Go to Accounting > Reporting > Tax return - Create a closing entry - Try to post the closing entry - An error is raised: ```python elif token[1] == 'in' and not (isinstance(token[2], Query) or token[2]): ~~~~~^^^ IndexError: string index out of range ``` The fix wraps the subdomain in a list so the domain is properly evaluated. opw-5075640 Forward-Port-Of: odoo/enterprise#94440 Forward-Port-Of: odoo/enterprise#94277
Fixes an issue where users who had Shop Floor set as their default opening screen could encounter an error when logging in. The change keeps the page from crashing if the app title is not ready yet, improving reliability for manufacturing users.
Original PR description
**PROBLEM** In debug mode, we can change the default home action of a user (the action he sees when logging in). When the action `action_mrp_display` is set as the home action, there is a traceback…
**PROBLEM** In debug mode, we can change the default home action of a user (the action he sees when logging in). When the action `action_mrp_display` is set as the home action, there is a traceback after logging in. **STEP TO REPRODUCE** 1. Go in debug mode 2. Change the home action of a user to the 'Shop Floor' action (in the user form, in the preference tab). 3. log out, and log in with this user. 4. a js traceback should appear. **CAUSE** In mrp_workcenter_dialog.js, the Shop Floor action uses the `menu` service to get the name of the current app. `setCurrentMenu()` which set the current app in the `menu` service is not called before the `appName` getter is called. https://github.com/odoo/odoo/blob/5c1234085b1c1e227846b24bde55a0392779069b/addons/web/static/src/webclient/menus/menu_service.js#L29-L36 This lead to a traceback because this.menu.getCurrentApp() is `undefined`. **FIX** Workaround if the current app is undefined. We already check what is returned by `getCurrentApp()` where it is used. opw-4926317 Forward-Port-Of: odoo/enterprise#93043
Planning calendar invites now keep the correct times when no employee is assigned to a shift. This prevents invite times from being shifted incorrectly in cases where timezone fallback rules are used, improving reliability for schedule sharing.
Original PR description
The test `test_planning_ics_file_without_assigned_employee` failed when running without demo data because the slot timezone was `Europe/Brussels` while the employee timezone was `UTC`.
The previous code in the method `ics_datetime()` converted to the slot timezone and then relabeled it as the employee timezone with `.replace(tzinfo=...)`, which shifted the actual instant.
This change ensures that ICS datetimes are always converted using astimezone to a single target tz:
- employee tz if the slot is assigned,
- otherwise the current user tz or `UTC` as fallback.
The test was also updated to assert the correct fallback `UTC` values:
`DTSTART:20230602T080000Z`
`DTEND:20230602T170000Z`
[runbot-231213](https://runbot.odoo.com/odoo/error/231213)
Forward-Port-Of: odoo/enterprise#9369215 changes
Enhancements to existing features
Public website pages can now be cached after they are generated, helping them load faster for visitors and reducing server/database workload. Safeguards avoid caching pages that may contain dynamic or sensitive information, while allowing teams to customize cache behavior where needed.
The Argentina electronic invoicing test certificates were refreshed so Odoo can keep connecting to ARCA's testing services. This prevents test failures caused by expired digital certificates and keeps validation workflows running smoothly.
Original PR description
Homologation certificates are required to connect Odoo with ARCA's test web services. When they expire, electronic invoicing tests fail, displaying a “Digital certificate expired” warning. In this PR, I'm updating the certificates so we can continue using the testing environment for our tests. Odoo Task 1359 Adhoc Task 57144 Forward-Port-Of: odoo/enterprise#94128
This update removes duplicate shortcuts in Belgian accounting add-ons and uses the standard accounting settings action instead. It also simplifies related bank statement source handling, reducing maintenance without changing day-to-day accounting workflows.
Original PR description
#### [IMP] l10n_be_{codabox,soda}: remove obsolete actions
Currently the modules `l10n_be_codabox` and `l10n_be_soda`
define their own actions to open the accounting settings.
Such an action exists already in `account`. So they can be removed.
To remove
- `l10n_be_codabox.action_open_accounting_settings`
- `l10n_be_soda.action_open_accounting_settings`
Use instead
- `account.action_account_config`
#### [IMP] account: remove `__get_bank_statements_available_sources`
The function `__get_bank_statements_available_sources` is pointless
and can just be replaced with `_get_bank_statements_available_sources`
(single underscore version).
See related community PR. (odoo/odoo/pull/226347)
#### References
task-NoneThe mobile point of sale now remembers the customer display chosen by the user and reopens it automatically the next time POS starts. This saves staff time and reduces repeated setup when using customer-facing screens.
Original PR description
- Save the selected display in cookie - Open the selected display automatically when open the PoS Forward-Port-Of: odoo/enterprise#94391
Resolved issues and error corrections
POS GST reports in India now report service product quantities as zero, matching GST portal requirements. This prevents validation errors during filing while keeping normal quantity reporting unchanged for goods.
Original PR description
Before this PR: - Service products in POS GSTR lines were reported with their actual quantity. - This caused GST portal validation error: `RET191355: The Quantity entered is not valid`. After this PR: - For service-type products, `qty` is always set to `0`. - For goods, `qty` continues to reflect the actual ordered quantity. OPW: 5070636 Forward-Port-Of: odoo/enterprise#94607 Forward-Port-Of: odoo/enterprise#94272
This fixes an issue that prevented users from saving the document sorting setup for Finance folders when certain pinned actions were present. It also avoids selecting actions by default that the AI assistant cannot reliably run, reducing failed automation attempts while still allowing users to choose them manually if needed.
Original PR description
Bug === When trying to save the sort wizard for a folder having a pinned multi action, with a `documents_account_record_create` child action, then the constraint `_check_use_in_ai` was triggered, and it shouldn't. The reason is the way recursive compute work, we can not set `False` as the default, because it will allow the parent to be computed with that. Task-5077569 Forward-Port-Of: odoo/enterprise#94290
Payslip simulations now use the normal default pay period instead of forcing the employee contract start date. This helps avoid errors when salary rule parameters are not available for older contract dates, making payroll simulations more dependable.
Original PR description
Issue: by specifying the payslip date_from to the contract date start when simulating a payslip, there was a risk that some salary rule had no parameter for that date. Solution: not specify the date and let the payslip compute the default dates, which will default to this month. Forward-Port-Of: odoo/enterprise#94601
This fixes an issue where state or government checks in an audit could not be turned off. Businesses can now manage audit checks as intended, reducing unnecessary review steps when those checks are not needed.
Original PR description
State/Governement checks inside an Audit couldn't be disabled. Forward-Port-Of: odoo/enterprise#94614
The Planning app now handles schedules grouped by multiple fields more safely. This prevents an error screen when users group planning data without choosing resource as the first grouping, making schedule review more reliable.
Original PR description
Steps to reproduce: - Open planning and use multi groupby. - Dont use resource as first groupby. Issue: - Traceback Reason: - When we multi-groupby each row has a id, and we try to extract resource id, but we dont get it undefined/open rows. - Missed proper error handling. Fix: - Add better error handling to prevent further traceback using optional chaining. task-5065999 Forward-Port-Of: odoo/enterprise#93922
Fixed an issue where German DATEV reporting could miss the main account when a POS session contained both sales and refunds with different tax rates. The export now reliably selects the correct account, helping ensure complete accounting data for affected POS entries.
Original PR description
In _get_datev_account, the l10n_de_datev_main_account_id is determined by identifying a singular debit or credit account used in the journal entry. If there’s no unique account, it falls back to…
In _get_datev_account, the l10n_de_datev_main_account_id is determined by identifying a singular debit or credit account used in the journal entry. If there’s no unique account, it falls back to searching for a unique non-tax line among debit or credit lines. In POS, however, there is the possibility of generating journal entries that break this flow: - In a single POS session, add product A with tax 19% and product B with tax 7%. - In the same session, refund product A. - Close the session to generate the entries. In the resulting entry, since both sale and refund are present, it is not possible to discriminate using debit and credit amounts alone, and as a result, the field l10n_de_datev_main_account_id is not populated. Since account 1411 is always the one to be used for l10n_de_datev_main_account_id in this specific case, this commit adds a final fallback filter to select the correct line and ensure the field is populated. Ticket [link](https://www.odoo.com/odoo/project/967/tasks/4915272) opw-4915272 Forward-Port-Of: odoo/enterprise#92664
The AI live chat snippet now handles cases where the standard live chat widget is not present, such as a new database without demo data or deleted live chat channels. This prevents website visitors from encountering an error when starting a chat with the AI agent.
Original PR description
Steps to reproduce: - Go to the livechat app. - Delete all the livechat channels. - Open the website app. - Click on edit -> Contacts & Forms and add the ai_livechat snippet. - Set the 'AI Agent' on the snippet and save. - Start chatting with the ai agent using the snippet. - An error occurs. This error will happen in any case such that the livechat isn't available. For example: - Deleting all the livechat channels. - Installing a fresh db without demo data. This will result in the element '.o-livechat-root' not appearing on the website. This causes the ai_livechat component to have an error when trying to hide that element. This commit fixes the issue by adding optional chaining before accessing the class list of the element '.o-livechat-root'. Forward-Port-Of: odoo/enterprise#94622
Default salary input values now appear as expected when payroll rules are selected for employees or payslips. This helps payroll teams avoid manual corrections and reduces the risk of incorrect payslip calculations.
Original PR description
## Steps to reproduce 1. Make a new salary rule with condition based on 'salary input'. 2. Enable 'Input on' employee and payslip both and set a default value. 3. Go to employees 'Payroll tab' and 'add inputs', then select the rule. 4. Similary in 'Payslip' on 'Salary inputs' tab, 'add inputs' and select the rule. ## Issue - The default values on the employee and payslips were not being reflected on selection of the rule. ## Fix - Modified '_update_payroll_properties'. It now fetches active_id and updates properties based on the default values of input rules. - Updated '_compute_payslip_properties'. Ensures that payslips without common payroll properties fall back to the default values of the related input rules. task-5072646
Repair orders with quality checks can now be saved without triggering an error. This prevents interruptions when users work with repaired products and their lot or serial numbers.
Original PR description
Issue: ---------------------------------------- When creating a repair order that has a quality point (defined for all products or for a specific product), or when trying to create a new lot/serial…
Issue: ---------------------------------------- When creating a repair order that has a quality point (defined for all products or for a specific product), or when trying to create a new lot/serial number from the repair order, a traceback is triggered: `ValueError: Invalid field 'lot_id' in 'quality.check'` Steps to reproduce: ---------------------------------------- - Install the `quality_repair` module. - Create a Quality Point for Operation: Repair Orders and set Control per Product/Operation. - Create a Repair Order and add a product to repair. - Save the Repair Order. - Traceback is triggered. Cause: ---------------------------------------- In PR https://github.com/odoo/enterprise/pull/90930, the `lot_id` field was replaced by a many2many field `lot_ids`. Repair orders were still trying to assign `lot_id`, causing the error. Solution: ---------------------------------------- In this commit, we ensure that `lot_ids` is set properly, allowing repair orders with quality checks to work smoothly and enabling users to assign lots/serial numbers without triggering errors. Task ID:- 5067457 Forward-Port-Of: odoo/enterprise#94199
This fix makes the AI assistant more reliable when gathering information from discussion records. It prevents errors in cases where related conversation details are not available, helping users avoid interruptions.
Original PR description
This commit adds optional chaining to access thread properties in the getRecordInfo function. Forward-Port-Of: odoo/enterprise#94555
A display issue on account return cards has been corrected so users no longer see two "Reset" buttons. This reduces confusion when managing accounting and Intrastat returns and ensures the form shows the right action controls.
Original PR description
Two buttons "Reset" are shown in the card of an account return. This is due to the invisible attributes that wrongly computes the value. Indeed, it is not possible to write something like "type_id.is_intrastat_return_type" in an invisible condition, so we need to make a related field. Forward-Port-Of: odoo/enterprise#94393
20 changes
Enhancements to existing features
A confusing help message related to multi-actions has been removed from the Base module. This reduces user confusion by avoiding guidance that was not useful or clear.
Original PR description
This help message was not really helpful, and was actually confusing for users. Task: task-5085285
The work entries Gantt view now avoids loading favorite work entry data unless users are in the mode that needs it. This reduces unnecessary data fetching and can make the view feel more responsive in regular use.
Original PR description
If the gantt view is not in multi create mode, it is not necessary to fetch userFavoritesWorkEntries.
The Argentina electronic invoicing module now includes refreshed demo and testing certificates needed to connect to ARCA's test services. This prevents test failures caused by expired certificates and keeps the electronic invoicing testing environment usable.
Original PR description
Homologation certificates are required to connect Odoo with ARCA's test web services. When they expire, electronic invoicing tests fail, displaying a “Digital certificate expired” warning. In this PR, I'm updating the certificates so we can continue using the testing environment for our tests. Odoo Task 1359 Adhoc Task 57144 Forward-Port-Of: odoo/enterprise#94128
Resolved issues and error corrections
Test code was updated to use the shared web test helpers instead of reaching into internal framework folders. This is an internal cleanup that makes tests easier to maintain and reduces the risk of future test breakage, with no expected impact on end users.
Original PR description
This commit reduces imports to the 'tests/_framework/' subfolder, which is meant to be accessed through the 'web_test_helpers' module as to reduce the amount of imports, as well as centralizing all web helpers to have a quick overview of the available helpers. Community: https://github.com/odoo/odoo/pull/225865 Forward-Port-Of: odoo/enterprise#94131 Forward-Port-Of: odoo/enterprise#94074
This update improves Odoo's internal unit testing tools so automated checks run faster, display failures more clearly, and clean up test data more reliably. The changes are limited to the testing ecosystem, reducing risk to normal business workflows while helping developers catch issues sooner.
Original PR description
## Pull Request HOOT (PRHOOT) 36 This pull requests brings various improvements and fixes to Hoot and the Odoo unit test ecosystem. See the different commit messages for more details. Note: these changes are made in stable to avoid having to support multiple versions of the HOOT API. As such, these changes are intended to be strictly limited to unit tests as to not put the rest of the code base at risk. Enterprise: https://github.com/odoo/enterprise/pull/93167 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#226406 Forward-Port-Of: odoo/odoo#221367
This update makes the website snippet selection modal clearer and more consistent. It removes misleading parallax preview behavior, refreshes an outdated product preview image, and labels product-related dynamic snippets so users can better distinguish them from static content blocks.
Original PR description
This pr address minor UX issues for the snippets modal. - Disable the parallax effect for both `s_banner_product` and `s_floating_blocks` snippets: despite these make technically use of the parallax…
This pr address minor UX issues for the snippets modal. - Disable the parallax effect for both `s_banner_product` and `s_floating_blocks` snippets: despite these make technically use of the parallax feature, the effect is really subtle and not as strong as the one used by the preview. - Update one old `s_dynamic_snippet_products` preview image - Add the "Dynamic Content" label for both the `s_dynamic_snippet_products` and `s_dynamic_snippet_category_list` snippets. The goal is to differentiate the two from the static ones in the same category. A similar solution should be used for other dynamic snippets, like blog and events... but since everything in those categories is dynamic, the use of the same label would have been noisy and unnecessary. task-5088157 | 19.0 | this pr | |--------|--------| | <img width="445" height="243" alt="image" src="https://github.com/user-attachments/assets/98cadb04-f8cb-4b44-ad3f-6a8ff18ea05b" /> | <img width="444" height="243" alt="image" src="https://github.com/user-attachments/assets/7f7f471a-a11d-4131-9bd6-f8d7954eb1ca" /> | | <img width="441" height="260" alt="image" src="https://github.com/user-attachments/assets/c31a36d7-3c57-434a-b999-1bdb00430b63" /> | <img width="438" height="259" alt="image" src="https://github.com/user-attachments/assets/a124d022-0763-47c4-a72c-a9a992b83a8c" /> | | <img width="444" height="208" alt="image" src="https://github.com/user-attachments/assets/076c3b8e-ee89-470e-a780-93c657979273" /> | <img width="458" height="215" alt="image" src="https://github.com/user-attachments/assets/eca7e514-c947-4ce7-bb37-feae0377b229" />| | <img width="445" height="241" alt="image" src="https://github.com/user-attachments/assets/967c7093-7c20-4912-ab80-072059fa2124" /> | <img width="445" height="246" alt="image" src="https://github.com/user-attachments/assets/d6522f0d-c36e-4627-9d2e-145e1ecb61ff" /> | --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix updates the translation configuration to match a recently renamed disallowed expenses module. It helps ensure translations continue to be tracked and maintained correctly after the rename, with no expected impact on everyday users.
Original PR description
The modules have been renamed in https://github.com/odoo/enterprise/commit/31b5e33b0035c37d53f011f362bab739440e0271 but the weblate hasn't been changed.
This update keeps Odoo's email server checks aligned with a newer message returned by the underlying email testing tool. It helps prevent false test failures during maintenance without changing day-to-day user behavior.
Original PR description
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#226489
Manufacturing orders now prefill the first serial number from the product's custom lot/serial setting when generating serial numbers. Duplicated manufacturing orders also continue from the correct next serial number instead of restarting at 1, reducing manual corrections and duplicate tracking risks.
Original PR description
Back port of https://github.com/odoo/odoo/pull/226046 intended to target 19.0 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix prevents Indonesian e-Faktur downloads from crashing when an invoice line has more than one regular tax applied. Users can complete compliant tax document downloads more reliably instead of encountering an error during invoice processing.
Original PR description
The system crashes with an error when a user tries to `download the e-Faktur` document. **Steps to produce:-** - Install `Accounting` and switch to `ID Company`(with demo data). - Create a `new…
The system crashes with an error when a user tries to `download the e-Faktur` document.
**Steps to produce:-**
- Install `Accounting` and switch to `ID Company`(with demo data).
- Create a `new invoice` and select customer as `ID Company`.
- Add the product and in `taxes add 11% and 0% (2 non-luxury taxes)` and confirm the invoice.
- Click on gear icon and click on `Download e-Faktur` button.
**Error:-**
`ValueError: ValueError('Expected singleton: account.tax(5, 15)') while
evaluating 'action = records.download_efaktur()'`
**Root cause:-**
- When more than one non-luxury tax is applied and the e-Faktur document is downloading, the code at [1] expects a single tax record, but multiple non-luxury taxes are found.
**Solution:-**
- Since luxury tax is already excluded from the regular tax computation at [2], I think we can directly sum all non-luxury taxes.
[1]: https://github.com/odoo/odoo/blob/52aa6231130ea165fdb44e6370ec3e396b7603cc/addons/l10n_id_efaktur_coretax/models/account_move_line.py#L52
[2]: https://github.com/odoo/odoo/blob/52aa6231130ea165fdb44e6370ec3e396b7603cc/addons/l10n_id_efaktur_coretax/models/account_move_line.py#L24-L25
**sentry-6837559933**
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#224419This fixes an issue where the Point of Sale could show an error if no user was available for the cashier lookup. The system now safely returns no cashier instead of failing, helping avoid interruptions during POS use.
Original PR description
When there is no user, you get a traceback when it tries to access user.id. As the code that call getCashierUserId handles the fact that a falsy value is returned, we return undefiened when there is no user. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#226821
Manufacturing orders now prefill the first serial number from the product’s custom lot or serial value when generating serial numbers. Duplicated manufacturing orders also continue from the correct next serial number instead of restarting, reducing manual corrections and duplicate serial risks.
Original PR description
Steps to reproduce Bug #1: - Add Custom Lot/Serial to a product - Create a manufactoring order with a quantity > 1 - Confirm and Generate Serial Problem: First SN is not prefilled by the Custom Lot/Serial added. Steps to reproduce Bug #2: - Create a duplicate from the previous MO - Generate Serial Numbers Problem: First SN is not updated and generates serial numbers starting with "1" again rather than incrementing the previous serial number. Note: On adding new serial numbers different than the custom (changing the prefilled First SN), it will only be applied on that specfic MO only. To apply it to any new MO, it must be added to the Custom Lot/Serial field in the product form. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Appointment quick creation now correctly calculates the end time even when the duration field is not shown. This prevents incomplete or incorrect appointment times when users create calendar events from the streamlined appointment view.
Original PR description
In [1] we remove the field "duration" from the calendar quick create view in appointment. `default_get` relies on "duration" being in the default values to compute the "stop" based on it. Since the field is not in the view this does not work anymore. Now always ask for that field in `default_get` and just remove it if it was not requested. [1]: c8eb4fe4ba9938b1c7e07034e6ca7c08a0d6f215 task-5081903
Payroll salary input default values are now applied when users select salary rules on employee records or payslips. This helps payroll teams avoid missing or incorrect input amounts and reduces manual corrections during payroll processing.
Original PR description
## Steps to reproduce 1. Make a new salary rule with condition based on 'salary input'. 2. Enable 'Input on' employee and payslip both and set a default value. 3. Go to employees 'Payroll tab' and 'add inputs', then select the rule. 4. Similary in 'Payslip' on 'Salary inputs' tab, 'add inputs' and select the rule. ## Issue - The default values on the employee and payslips were not being reflected on selection of the rule. ## Fix - Modified '_update_payroll_properties'. It now fetches active_id and updates properties based on the default values of input rules. - Updated '_compute_payslip_properties'. Ensures that payslips without common payroll properties fall back to the default values of the related input rules. task-5072646
This fix ensures Uruguayan electronic documents correctly read document numbers that start with more than one letter. This helps avoid incorrect processing or validation issues for affected invoices, credit notes, and debit notes.
Original PR description
If UY EDI document has latam document number with more than one letter at the beggining, it is needed to take in consideration all the letters and not only the first one. Task Latam side: 1352 Task Adhoc side: 53173 Forward-Port-Of: odoo/enterprise#90696
A Turkish payroll employee field is now only visible to HR users. This prevents non-HR staff from encountering an access error when employee records are read, improving reliability for internal users.
Original PR description
The test `test_employee_fields_groups` crashed with: `AccessError: The fields “l10n_tr_is_net_to_gross”, which you are trying to read, are not available for employee public profiles.` This field exist without HR group restriction as a result, a non-HR internal user calling .read([]) triggered the AccessError. This commit adds `groups="hr.group_hr_user"` to this field so it is only accessible to HR users, resolving the error. [RB-231736](https://runbot.odoo.com/odoo/error/231736)
Code cleanup and technical improvements
This update reorganizes internal test code so shared web testing helpers are accessed through one central place. It should make future maintenance easier and reduce conflicts without changing day-to-day product behavior for users.
Original PR description
This commit reduces imports to the 'tests/_framework/' subfolder, which is meant to be accessed through the 'web_test_helpers' module as to reduce the amount of imports, as well as centralizing all web helpers to have a quick overview of the available helpers. Enterprise: https://github.com/odoo/enterprise/pull/94074 Originally contained within the following pull request: https://github.com/odoo/odoo/pull/225744 But has been separated for convenience sake since the original PR was involving security overrides, and would be consistently interrupted by conflicts ensuing from this specific commit. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#225974 Forward-Port-Of: odoo/odoo#225865
This update reorganizes how several enterprise add-ons load their Discuss and live chat resources, removing an unused VoIP public asset bundle. The change is mainly internal maintenance, helping keep the product easier to maintain without introducing expected functional changes for users.
Original PR description
Enterprise counter-part. https://github.com/odoo/odoo/pull/226643
This refactoring streamlines how Discuss-related assets are organized across Odoo modules, reducing duplicate configuration work and lowering the risk of inconsistent behavior. It mainly benefits maintainability by making asset bundle names match their file paths more clearly, with little expected direct impact for end users.
Original PR description
Currently, each module is responsible of adding discuss overrides into each of the top level bundle (backend, public page, livechat, portal). This means when adding one folder in a new module, it…
Currently, each module is responsible of adding discuss overrides into each of the top level bundle (backend, public page, livechat, portal). This means when adding one folder in a new module, it might need to be added into 4 different bundles. This requires knowledge of the bundles and forgetting one of them might lead to unexpected behavior. The bundle name also does not match with the path of the file, which adds confusion. This also doesn't give much granularity for where overrides are applied: they are always applied after all files of the dependent modules, but this might not always be desirable. This commit refactors the discuss bundles so that one bundle = one path. The intent of the path was already correct (to match the top level bundle), which is unchanged. The only change is now having matching intermediate bundle names. As an example: overrides of `core/web` in a module can directly be included in `mail.assets_core_web` (matching name, single line in manifest) rather than having to override each of the top-level bundle separately (backend, public page, livechat embed, portal) to add the new folder. https://github.com/odoo/enterprise/pull/94493
Miscellaneous changes
This pull request does not list any changed files or functional updates, so no business-facing behavior appears to change. It seems to be an empty or administrative tutorial commit with no expected impact on Odoo users.
Original PR description
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
18 changes
Enhancements to existing features
The Argentina electronic invoicing module now includes refreshed demo and testing certificates needed to connect to ARCA's test services. This prevents certificate-expiry warnings from disrupting electronic invoicing tests and keeps the testing environment usable.
Original PR description
Homologation certificates are required to connect Odoo with ARCA's test web services. When they expire, electronic invoicing tests fail, displaying a “Digital certificate expired” warning. In this PR, I'm updating the certificates so we can continue using the testing environment for our tests. Odoo Task 1359 Adhoc Task 57144 Forward-Port-Of: odoo/enterprise#94128
Resolved issues and error corrections
Corrects an issue that could prevent Italian companies from posting tax return closing entries. This ensures the tax return workflow completes normally instead of failing with an unexpected error.
Original PR description
The `osv.expression.AND` operator was incorrectly used, leading to an invalid search domain and raising an error. Steps to reproduce: - Set the company country to Italy - Go to Accounting > Reporting > Tax return - Create a closing entry - Try to post the closing entry - An error is raised: ```python elif token[1] == 'in' and not (isinstance(token[2], Query) or token[2]): ~~~~~^^^ IndexError: string index out of range ``` The fix wraps the subdomain in a list so the domain is properly evaluated. opw-5075640 Forward-Port-Of: odoo/enterprise#94277
Fixes an issue where Razorpay OAuth webhook generation could fail when Website Payment was installed. The update builds callback URLs more safely, preventing authentication errors caused by malformed links.
Original PR description
A bad URL could be generated when the `website_payment` module is installed, as it overrides `get_base_url` and may return a URL ending with `/`. Using f-strings to create URLs could result in a double slash `//`, causing errors. Steps to reproduce: - Install `website_payment` and `payment_razorpay_oauth` - Go to Payment Acquirers and connect via OAuth - Click "Generate your webhook" - "Authentication failed" error appears This fix uses `url_join`, like other payment providers, to build URLs correctly and avoid the double slash issue. opw-5079295 Forward-Port-Of: odoo/odoo#226248
This fixes an access issue where timesheet approvers could not see other users' time entries on tasks they followed in private projects. Approvers with the right permissions can now view those timesheets both on the task and in reporting, aligning access with their task visibility.
Original PR description
**Issue:** Users with "All Timesheets" rights can't see other users’ timesheets on tasks they followed within private projects, even though they had access to the task itself. **Cause:** The security…
**Issue:** Users with "All Timesheets" rights can't see other users’ timesheets on tasks they followed within private projects, even though they had access to the task itself. **Cause:** The security rules for approvers (`timesheet_line_rule_approver` and `timesheet_analysis_report_approver`) only check project-level follower access and ignore task-level access. https://github.com/odoo/odoo/blob/48cfd650053c794a838c130605c4280351b4f5d9/addons/hr_timesheet/security/hr_timesheet_security.xml#L66-L76 https://github.com/odoo/odoo/blob/48cfd650053c794a838c130605c4280351b4f5d9/addons/hr_timesheet/security/hr_timesheet_security.xml#L108-L117 **Steps to reproduce:** 1. Create a private project (`privacy_visibility == 'followers'`) 2. Give another user (e.g., Marc Demo) "All Timesheets" rights and only "User" project access 3. Add Marc Demo as a follower of a task in that private project 4. Have another user log time on that task 5. Log in as Marc Demo Marc cannot see the other user's timesheets, neither on the task form nor in reporting. opw-5022877 Forward-Port-Of: odoo/odoo#224025
Very small negative amounts that round to zero are now shown as regular zero values on printed PDFs. This prevents confusing displays like "-0.00" on business documents and keeps financial output clearer for users.
Original PR description
Previously, when an amount value that is passed to `value_to_html` is a really small negative number (e.g. -0.000000001), the rounded result will have the negative sign in front of it (e.g. "-0.00").
This commit fixes it so that they will be rendered without the negatives ("0.00").
opw-4685953Argentina partner records no longer crash when an invalid VAT or identification value is entered. This makes customer and vendor data entry more reliable by safely handling bad inputs instead of interrupting the workflow.
Original PR description
Manual backport of https://github.com/odoo/odoo/commit/b01a6640895c4dd4b5bcf849740aa6b3312e9a54. This is needed to prevent crashes when trying to sanitize invalid VAT inputs for Argentina partners due to the assumption that the identification number can always be safely cast to int(). --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
EU OSS taxes created for Spanish localization are now assigned the correct tax classification instead of being marked as a standard taxable type. This helps businesses keep OSS tax reporting aligned with Spanish compliance requirements and avoids incorrect tax categorization after refreshing mappings.
Original PR description
The EU OSS taxes were generated with the wrong l10n_es_type. - Install l10n_es and l10n_eu_oss. Then go to Settings and refresh the tax mapping in “EU Intra-community Distance Selling.” - In Taxes, filter by tax group containing “OSS.” All OSS taxes appear with l10n_es_type = sujeto. This is incorrect. The correct type should be “No Sujeto por reglas de localización” (see section 2): https://a3responde.wolterskluwer.com/es/s/article/version-3-05-del-moduloticketbai-batuz-de-a3erp-mejoras#OSS This commit adds the possibility of adding country specific field during the account_tax creation using chart_template -> fields mapping. opw-5009180 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#224192
Mexican electronic invoice PDFs now show the same customer fiscal regime as the official CFDI XML when billing a child contact under a company. This prevents mismatched tax information between the readable PDF and the legally relevant XML document, reducing confusion for customers and accounting teams.
Original PR description
In l10n_mx: - Create a child contact under a company contact. - Set the fiscal regime of the child contact to one different from the company’s fiscal regime. - Create an invoice with the child contact and send it to the CFDI. In the XML, the fiscal regime used is the company’s, whereas in the PDF it is the child contact’s. This commit applies the same logic from _add_customer_cfdi_values to the PDF generation. After this change, the fiscal regime shown in the PDF will be the company’s, consistent with the XML. opw-4989605 Forward-Port-Of: odoo/enterprise#92482
DIN5008 report layouts are updated so customer phone numbers no longer appear in the address block, and VAT details are moved out of that address section. This keeps printed business documents cleaner and better aligned with the intended DIN5008 format.
Original PR description
This commit removes the phone number from the DIN5008 report layout. The customer's VAT is also no longer displayed in the customer's address section. The VAT is moved to another section. Description of the issue/feature this PR addresses: Current behavior before PR: The customer's phone number and VAT are displayed in the customer's address in the DIN5008 report layout. Desired behavior after PR is merged: The customer's phone number is no longer displayed and VAT moved to another section in the DIN5008 report layout. opw-5049074 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#226630
Fixes an issue that prevented Ecuadorian delivery guides from being generated when barcode scanning was disabled in Inventory settings. This helps businesses create required delivery documents reliably without needing to enable an unrelated barcode feature.
Original PR description
Currently, an error occurs when generating a Delivery Guide if the Barcode Scanner is disabled in the Inventory settings. **Steps to reproduce:** - Install the `l10n_ec_edi_stock` module and switch…
Currently, an error occurs when generating a Delivery Guide if the Barcode Scanner is disabled in the Inventory settings. **Steps to reproduce:** - Install the `l10n_ec_edi_stock` module and switch to the `EC company`. - Uncheck `Barcode Scanner` in the Inventory `settings`. - Create a new warehouse and set the `Entity` and `Emission Point`. - Navigate to Inventory > Operations > Deliveries and create a new delivery. - Add details > mark as Todo > Validate > Generate Delivery Guide. **Error:** `AttributeError: 'stock.move.line' object has no attribute 'qty_done'` **Root Cause:** At [1], the code references `line.qty_done`, but this field is defined in the `stock_barcode` module at [2]. When the Barcode Scanner is `disabled`, the field is not available, leading to the `error`. **Fix:** This commit updates the delivery guide values to use `line.quantity` instead of `line.qty_done` at [1] and at [4]. Since in the `stock_barcode` module at [3], `qty_done` is derived from `quantity`. [1]: https://github.com/odoo/enterprise/blob/ba5b9790f28e2f7eabda22e5992737eab0e82c6e/l10n_ec_edi_stock/models/stock_picking.py#L354 [2]: https://github.com/odoo/enterprise/blob/8c53e50df1cf9dc6d3ca4cae19c39135ac85d4e4/stock_barcode/models/stock_move_line.py#L23 [3]: https://github.com/odoo/enterprise/blob/8c53e50df1cf9dc6d3ca4cae19c39135ac85d4e4/stock_barcode/models/stock_move_line.py#L48-L50 [4]: https://github.com/odoo/enterprise/blob/8b72fdef63f634ccf436b49adbac5c1f9358c127/l10n_ec_edi_stock/views/report_delivery_guide.xml#L165 sentry-6851008674
Users can now add several new comma-separated tags when creating a forum post without triggering an error. This prevents failed post submissions and makes forum tagging more reliable.
Original PR description
Currently, an error occurs when a user tries to add multiple comma-separated new tags to a forum post. **Steps to reproduce:** - Install the `website_forum` module. - Go to: `Website > Configuration…
Currently, an error occurs when a user tries to add multiple comma-separated new tags to a forum post. **Steps to reproduce:** - Install the `website_forum` module. - Go to: `Website > Configuration > Forums`, create a new forum, then click `Go to Website`. - Click on `Start by creating a post`, enter content, and set the `Tags` to `_test, retour affectif rapide`. - Click on `Post Your Question`. **Error:** `ValueError: invalid literal for int() with base 10: 'retour affectif rapide'` **Root Cause:** After PR #169472, at [1], the code prepends an underscore (_) only to the entire input string instead of each tag. When multiple tags are entered, the backend receives a mixed list of values (e.g., ['__test', 'retour affectif rapide']), leading to an error during `int()` conversion at [2]. **Fix:** This commit updates the `onCreateOption` logic to prepend an underscore to each tag in the comma-separated input, similar to [3]. Also updated the test case at [4], to click `Create option` to save the tags. [1]: https://github.com/odoo/odoo/blob/afa26af132566a68ad6bf67565062bd73ddd7429/addons/website_forum/static/src/js/website_forum.js#L54-L61 [2]: https://github.com/odoo/odoo/blob/afa26af132566a68ad6bf67565062bd73ddd7429/addons/website_forum/models/forum_forum.py#L304 [3]: https://github.com/odoo/odoo/blob/ac93a25b216e6194895a64fe12c0d01f6833f743/addons/website_forum/static/src/js/website_forum.js#L69-L80 [4]: https://github.com/odoo/odoo/blob/d155edfd729ab9b53f38939fe24b6d1e7b578083/addons/website_forum/static/tests/tours/website_forum_question.js#L34-L37 sentry-6761920887
Event searches on the website now show consistent results whether users choose from the search dropdown or press Enter. Events that match the search term in their description will no longer disappear from the full results page, making event discovery more reliable.
Original PR description
Purpose ======= Making sure that, when typing a search term, all the results displayed in the search bar dropdown are visible on the page when clicking Enter. Specification ============= Previously, the search bar dropdown was displaying all the events where the name or description matched the search term. However, when clicking Enter, only the events where the name matched were displayed on the page (the ones where only the description matched were ignored). Fixing the issue by considering the description in the event search options. Task-5039221 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#224414
This fix prevents an error screen when a bank journal is deleted while another user is reviewing duplicate bank transactions. Users can now change the starting date or open the duplicate transaction view without the process failing unexpectedly.
Original PR description
When the user tries to access duplicate transactions of bank, A traceback will appear. Steps to reproduce the error: - Install ``accountant`` module - Login as User A and User B - In User A > Go to…
When the user tries to access duplicate transactions of bank, A traceback will appear. Steps to reproduce the error: - Install ``accountant`` module - Login as User A and User B - In User A > Go to Dashboard > Bank > Actions > Find Duplicate Transactions - From User B, delete bank journal - In User A, change the ``Starting Date`` in duplicate transactions OR - Open ``account.duplicate.transaction.wizard.form`` view Traceback: ``` ValueError: Expected singleton: account.journal() ``` https://github.com/odoo/enterprise/blob/6b5702e232d21d5c197648c6600b3d38439769bc/account_online_synchronization/wizard/account_journal_duplicate_transactions.py#L36 When User deletes the bank journal and modifies the starting date of duplicate transactions, ``wizard.journal_id`` becomes False. So, it will lead to the above traceback at [1]. 1-https://github.com/odoo/enterprise/blob/9fcf35baf9215e6229b2d5dc7837925593e340e6/account_online_synchronization/models/account_journal.py#L265-L266 sentry-6134269577
Fixes an issue where using the Translate action on a message in the mobile chatter caused an error. Mobile users can now translate messages reliably, improving usability in multilingual conversations.
Original PR description
Steps to reproduce: - Open any chatter with a message on mobile - Try to translate the message using the Translate mobile action => Throws traceback This happens because the component here is `MessageActionMenuMobile` instead of `Message`, and MessageActionMenuMobile does not have the `onClickToggleTranslation` method. This PR fixes the issue. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Italian split payment taxes now show the correct label in the Taxes column on PDF documents instead of appearing as standard taxes. This helps users and customers read tax details accurately and reduces confusion in Italian accounting documents.
Original PR description
Split payment taxes were not labelled correctly in the PDF's "Taxes" column, they were labelled as standard taxes. <img width="1214" height="598" alt="image" src="https://github.com/user-attachments/assets/f1ea57bd-9a7f-460f-8c81-6a89585ba6d8" /> Forward-Port-Of: odoo/odoo#226366
Employees with more than one running contract can now open the Time Off app without encountering an error. This fixes a contract-handling issue so Odoo correctly processes unusual days across multiple active contract periods.
Original PR description
**Step to Reproduce** - install hr_contract and hr_holidays module - go to employee -> contracts - Add 2-3 contract to a employee, which can be done by having contracts in different interval (but…
**Step to Reproduce**
- install hr_contract and hr_holidays module
- go to employee -> contracts
- Add 2-3 contract to a employee, which can be done by having contracts in different interval (but same year)
- set their stage to `running`
- open Time off App
**Observation:**
- we receive a traceback
```
File "/data/build/odoo/addons/hr_contract/models/hr_employee.py", line 229, in _get_unusual_days
tmp_date_from = max(date_from_date, selected_contract.date_start)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/data/build/odoo/odoo/orm/fields.py", line 1424, in __get__
record.ensure_one()
File "/data/build/odoo/odoo/orm/models.py", line 5635, in ensure_one
raise ValueError("Expected singleton: %s" % self)
ValueError: Expected singleton: hr.contract(1, 2)
```
**Cause:**
- `_get_unusual_days` assumes that there is only one running contract
- Hence with multiple contract, it raises traceback
Fix:
- Adjust the method to accept multiple contracts
opw-5045306
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThe accounting KPI summary now counts posted entries that still need accountant review, not just draft entries. This gives teams a more accurate view of pending accounting work by journal category.
Original PR description
The `kpi.provider:get_account_kpi_summary` method should count draft moves by category, but also include posted moves that still are to be checked by the accountant. Task-id: 5062431 Forward-Port-Of: odoo/odoo#226976 Forward-Port-Of: odoo/odoo#226411
The email editor now handles certain copied marketing designs more safely, preventing an error when users switch between editing tabs. This helps staff reuse email layouts across marketing emails and templates without interrupting their workflow.
Original PR description
If we copy "Event Promo" design from mailing.mailing to mail.template JS will fail. The quesryselector can fail so better to safeguard the working function. To reproduce the bug: - open mailing.mailing and create a new record - Choose "Event Promo" to be mail body - copy the HTML of the body - go to mail.template and create a new record - paste that HTML in the body of mail.template new record - switch between Content and Settings tabs and observe. The next error will raise up UncaughtPromiseError > TypeError Uncaught Promise > can't access property 1 of null TypeError: can't access property 1 of null formatTables@http://localhost:8069/web/assets/319-85bee19/web.assets_backend.min.js:13286:268 toInline@http://localhost:8069/web/assets/319-85bee19/web.assets_backend.min.js:13275:478
9 changes
Enhancements to existing features
The Argentina electronic invoicing module now includes renewed certificates for demo and testing environments. This prevents test connections to ARCA services from failing due to expired certificates, helping keep invoice testing reliable.
Original PR description
Homologation certificates are required to connect Odoo with ARCA's test web services. When they expire, electronic invoicing tests fail, displaying a “Digital certificate expired” warning. In this PR, I'm updating the certificates so we can continue using the testing environment for our tests. Odoo Task 1359 Adhoc Task 57144 Forward-Port-Of: odoo/enterprise#94128
Resolved issues and error corrections
Steps to reproduce: 1. Add language Spanish(AR) 2. Go to Inventory (Inventario) > Operations (Operaciones) 3. Deliveries (Entregas) > Open any record. 4. Click ⚙ > Print (Imprimir) > Delivery Slip (Recibo de entrega) Issue: - The translation of "Delivery Slip" in Spanish (es_419) shows as "Recibo de entrega", which is incorrect for Argentina. Cause: - Odoo currently labels document as “Recibo de entrega”, but legally it must be “Remito de entrega”. According to AFIP General
Original PR description
Steps to reproduce: 1. Add language Spanish(AR) 2. Go to Inventory (Inventario) > Operations (Operaciones) 3. Deliveries (Entregas) > Open any record. 4. Click ⚙ > Print (Imprimir) > Delivery Slip (Recibo de entrega) Issue: - The translation of "Delivery Slip" in Spanish (es_419) shows as "Recibo de entrega", which is incorrect for Argentina. Cause: - Odoo currently labels document as “Recibo de entrega”, but legally it must be “Remito de entrega”. According to AFIP General Resolution 1415/2003(Arts. 28–30) a REMITO “R” or “X” must explicitly include “DOCUMENTO NO VÁLIDO COMO FACTURA” and follow the mandatory structure and data placement defined by law. Go through : https://www.odoo.com/mail/message/848099710 Solution: - Updated the translation from "Recibo de entrega" to "Remito de entrega" opw-5004345
Issue: - The translation of "Delivery Slip" in Spanish (es_419) shows as "Recibo de entrega", which is incorrect for Argentina. Cause : - Odoo currently labels document as “Recibo de entrega”, but legally it must be “Remito de entrega”. According to AFIP General Resolution 1415/2003(Arts. 28–30) a REMITO “R” or “X” must explicitly include “DOCUMENTO NO VÁLIDO COMO FACTURA” and follow the mandatory structure and data placement defined by law. Go through : https://www.odoo.com/mai
Original PR description
Issue: - The translation of "Delivery Slip" in Spanish (es_419) shows as "Recibo de entrega", which is incorrect for Argentina. Cause : - Odoo currently labels document as “Recibo de entrega”, but legally it must be “Remito de entrega”. According to AFIP General Resolution 1415/2003(Arts. 28–30) a REMITO “R” or “X” must explicitly include “DOCUMENTO NO VÁLIDO COMO FACTURA” and follow the mandatory structure and data placement defined by law. Go through : https://www.odoo.com/mail/message/848099710 Solution: - Updated the translation from "Recibo de entrega" to "Remito de entrega" opw-5004345
This fix ensures Odoo returns the nearest main view ID when a request starts from an extension view. It helps avoid mismatches between the displayed screen layout and the view identifier used by customizations or integrations.
Original PR description
Before this commit, when executing `ir.ui.view.get_view(view_id)` where view_id points to an extension view, the method return the correct arch but the inherited view's id. After this commit, it returns the id of the closest primary view. opw-4930800 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
The subscription portal no longer offers advance payment when there is nothing currently due to invoice. This prevents customers from attempting a zero-value payment and seeing an avoidable payment error.
Original PR description
## Issue: When you create a Subscription for a product that should be invoiced after Delivery with Required Payment, you can Anticipate the payment even if the amount to invoice is 0.0 When you do that, a payment error will be displayed ## Cause: The Anticipate Payment session is displayed based on the `invoice.amount_total` instead of the `invoice.amount_to_invoice` In 18.0, the session is hidden because it use a adapted version of the amount to invoice: https://github.com/odoo/enterprise/blob/2f3698b250092ad376344e959d46bdc0eebf1a81/sale_subscription/views/sale_subscription_portal_templates.xml#L262 ## Steps to reproduce: - Create a Product (Invoicing Policy: Delivered Quantity) - Add it to a New Subscription - Set the Recurring Plan to Monthly - In the Other Info tab, disable Online Payment - Send by Email and open the link in a Private Broser - Sign the Subscription - The Anticipate Payment is available for 0.0 opw-4914578
The printer interface now handles errors from the printing system when adding a printer, such as invalid printer names or read-only storage. Instead of stopping, it logs the issue and keeps the printer service running, improving reliability for connected printing devices.
Original PR description
Before this commit, if CUPS raised an error when adding a printer in the `supported()` method of the printer driver, the exception would not be caught causing the printer interface to stop. This can happen for example if the filesystem is read-only or the printer has an invalid name. After this commit, we catch any CUPS errors and log them, allowing the printer interface to continue running. We also enter write mode before adding the printer to prevent any read-only errors. task-5086036 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Fixed an issue where FedEx Home Delivery shipments could fail when generating return labels because the recipient address was not marked as residential. This helps businesses using FedEx Home Delivery avoid blocked delivery validation and return label creation errors.
Original PR description
**PROBLEM** When selecting FedEx Home Delivery service, and enabling the return label generation, we got the error `RECIPIENT.ADDRESS.ERROR`. **STEPS TO REPRODUCE** 1. Install delivery_fedex_rest (use the new fedex credentials). 2. On the FedEx US shipment method (demo data) select FedEx home delivery service, and check the `Generate Return Label` option. 3. Create a SO, add shipping with FedEx US, validate the SO. 4. Validate the delivery order, and notice the FedEx API return an error. **CAUSE** For Home Delivery Service, the recipient address need to have the `residential` flag set to true. In `_return_package()`, the request sent doesn't include this flag, leading to an error. **FIX** Fix `_return_package()` query to include the `residential` flag. opw-4939065
This update corrects a date used in an automated product margin test. It helps keep quality checks reliable without changing how users work with product margins.
Original PR description
runbot-230719 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an error that blocked users from logging timesheets on projects shared across multiple companies. When no company is set on the project, the system now uses the user's current company so the correct employee record is found.
Original PR description
steps to reproduce: ------------------- 1. Install Employees, Timesheets, Projects 2. Create 2 companies 3. On each company, create an employee for the same related user 4. Create a project without…
steps to reproduce: ------------------- 1. Install Employees, Timesheets, Projects 2. Create 2 companies 3. On each company, create an employee for the same related user 4. Create a project without setting a company (making it a global project). 5. Enable both companies in the systray 6. Try to log a timesheet on the global project. issue: ------ A ValidationError is raised: "Timesheets must be created with an active employee in the selected companies." cause: ------ During `vals_list` preparation, the `company_id` value is overwritten here: https://github.com/odoo/odoo/blob/605e47a85561614c17fe2e6f59618610f87c69bb/addons/hr_timesheet/models/hr_timesheet.py#L381 If the project has no company set, `company_id `becomes **False**. This condition fails if the user has two employees and no company set (or if it is missing): https://github.com/odoo/odoo/blob/d3c7e51e94d98da9086a3817b157c4e125c80790/addons/hr_timesheet/models/hr_timesheet.py#L211-L215 solution: --------- Use `self.env.company` if company_id is missing(or False) in the vals. opw-4892449 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr