Monday, September 15, 2025
67 changes
16 changes
Resolved issues and error corrections
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
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 fix restores fast processing when Odoo determines who should receive mail notifications. It removes a slowdown introduced by a previous change, helping messaging-related actions respond more quickly without adding extra database load.
Original PR description
The commit 2e63fe11624b8abd9205ae94b6721fce660751db introduced a severe performance regression in some SQL query, going from 1.2ms to 450ms! Instead of computing the transitive closure of collected groups in pure SQL with a "WITH RECURSIVE", we use the computed field all_implied_ids. As the latter is based on ormcache'd data, the new solution has no marginal cost in terms of SQL queries.
This fix makes the Send button in Odoo's messaging composer respond reliably when used from the iOS progressive web app. It prevents the message box from shifting at the moment of tapping Send, reducing missed sends in Discuss and chatter conversations.
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
This fixes an issue where embedded Odoo pages, such as livechat, could fail because the web client tried to access browser window information that may be restricted. The change helps avoid access violations in cross-origin or sandboxed contexts, improving reliability for embedded experiences.
Original PR description
This [commit] introduced a cross-origin/sandbox access violation. `window.top` properties must never be accessed without guarding. Known issue: embedded livechat. [commit]: https://github.com/odoo/odoo/commit/27a85d650dee8345a4ec701bf7456eec07851718 task-5083154
The Time Off request dialog now shows the Submit Request button when there is no dashboard warning message available. This prevents employees or HR users from being blocked when creating absence requests in the Swiss payroll transmission setup, while keeping the usual validation after submission.
Original PR description
**Steps to reproduce** 1. Install l10n_ch_hr_payroll_elm_transmission 2. Go to an employee's profile 3. Click on "Absences" smart button 4. Create a new Time Off request Issue: the form view dialog is missing a button to confirm the request. Cause: the dashboard warning message is not part of the l10n_ch_hr_payroll_elm_transmission view. Solution: display the "Submit Request" button if we don't have any dashboard warning message. There will still be a validation after the request is submitted. opw-4972467 Forward-Port-Of: odoo/odoo#221427
This fixes an issue where a point of sale order could remain stuck when a cashier refreshed the browser before cancelling a Worldline terminal payment. The POS now continues to receive the terminal cancellation confirmation, reducing checkout interruptions and manual recovery work.
Original PR description
This PR fixes a bug where the point of sale didn't receive notifications from the Worldline payment terminal for the cancellations if the browser webpage was refreshed How to reproduce: 1. Open a POS session with Worldline terminal 2. Send a transaction to the terminal 3. Refresh the browser webpage before paying 4. Click on "Cancel" on the POS screen --> your order will be stuck and never receive the confirmation This PR removes the check for the iot longpolling action identifier which changes on refresh of the webpage + adds more error messages for Worldline terminals Related PR in v17 -> saas-18.2: https://github.com/odoo/enterprise/pull/94635 task-5075860 Forward-Port-Of: odoo/enterprise#94629
Bank reconciliation can now match payments to shorter sales order references such as SO0001. This helps reduce missed matches and manual reconciliation work for accounting teams.
Original PR description
Matching on references was limited to matching words > 8, to increase reliability, but the default sequence for sale orders is 6 characters (SO0001), so they would never be found unless we reach SO1000000 -_- Forward-Port-Of: odoo/enterprise#93640
Reloading a page now keeps users in the correct app menu instead of switching to another menu that uses the same underlying action. This prevents confusion when navigating shared customer or partner screens across Sales, Invoicing, and Purchase.
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 a page could show the wrong application menu when several apps shared the same customer or partner screen. This fix keeps users in the correct menu context, reducing confusion when navigating Sales, Accounting, or Purchasing pages.
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
Moving documents to a previously visited folder no longer accidentally removes access for existing members. This helps ensure authorized users keep the document permissions they were given, avoiding unnecessary access issues after organizing files.
Original PR description
When moving documents with members to a folder which has been visited by those same members (or some of them) they are removed from those documents access. This is caused by the document.access which has an entry for the members but with a null role. Task-5075196 Forward-Port-Of: odoo/enterprise#94684 Forward-Port-Of: odoo/enterprise#94149
This fixes a problem where a manually opened Kanban column could fail to reopen after users left and returned to the view, causing an error. Users can now resume their work without crashes, even when many grouped columns are already open.
Original PR description
[FIX] web: Fix opened groups of web_read_group This commit fixes an issue where groups manually opened by the user were not correctly restored, leading to a traceback. Steps to reproduce: In a kanban views, when we have already 10 columns opened automatically and others closed ones: - Manually open a closed group after the first 10 opened groups. - Navigate to another view. - Return to the kanban view. We got a traceback: `TypeError: can't access property "map", data.records is undefined` The `web_read_group` function does not reopen the manually opened group when the `MAX_NUMBER_OPENED_GROUPS` limit has been reached. The web client does not handle this case gracefully, as it expects the manually opened group to still be opened. Solution: Manually opened groups should remain open regardless of the `MAX_NUMBER_OPENED_GROUPS` limit. This approach is more functionally sound and aligns with the behavior the web client expects.
The workcenter planning view now shows the actual working hours defined for each workcenter instead of always displaying a full 24-hour day. This gives manufacturing teams a clearer view of available capacity and helps them schedule work orders more reliably.
Original PR description
## **Issue Before This Commit:** In the workcenter planning view, the total hours displayed were misleading, as they always showed 24 hours of the day instead of the workcenter’s defined working…
## **Issue Before This Commit:** In the workcenter planning view, the total hours displayed were misleading, as they always showed 24 hours of the day instead of the workcenter’s defined working hours. This caused confusion for users since the displayed total hours did not match the actual available working time of the workcenter. ## **Steps to Reproduce:** - Create a Manufacturing Order (MO). - Add "Drawer" as the product. - Add a "SEC-ASSEM: [FURN_8855] Drawer" BOM. - Set the quantity to produce as 10. - Confirm the MO and plan it. - Open the planning view and notice that the total hours count incorrectly shows 24 hours instead of the defined working hours. ## **Cause of the issue:** The bug was introduced by this PR (https://github.com/odoo/odoo/pull/205486), as the related changes were not adapted here. Because of that, pill.record.workcenter_id[0] returns an undefined value. ## **With This Commit:** The calculation of total hours has been corrected to consider only the workcenter’s defined working hours. Users now see accurate hours in the planning view, making it easier to plan and schedule work orders reliably. task - 4900885
12 changes
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 - 2082This 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
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#224231This 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
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-prChanging component lot or location details in a manufacturing order no longer marks the component as consumed unless the quantity actually changes. This prevents misleading consumption status updates and helps users trust manufacturing order information.
Original PR description
Issue Before This Commit: ============================ When only the quants/move line were changed without modifying the quantity, the system automatically marked components as consumed (manual…
Issue Before This Commit: ============================ When only the quants/move line were changed without modifying the quantity, the system automatically marked components as consumed (manual consumption and picked boolean were set). This created confusion for the user since no actual consumption took place. Steps to Reproduce: ============================ - Install the `mrp` module. - Create a tracked product (lot/serial) with quants. - Create and confirm an MO having that product as a component. - Change only the quants (e.g., location of the quant, not quantity); notice that manual consumption and picked boolean are set. Cause of the Issue: =========================== This issue occurs when clicking the 'Details' button (`action_show_details` method) on a stock move. That action passes the context `force_manual_consumption`, based on that which directly sets the `manual_consumption` and `picked` booleans in the `write` and `create` methods. [see](https://github.com/odoo/odoo/blob/master/addons/mrp/models/stock_move.py#L276). With This Commit: ============================ Manual consumption and picked boolean are no longer set when only quants (not quantity) are changed. Component consumption is now triggered only if the quantity differs from the demand, ensuring consistency and avoiding confusion for the user. This fix avoids unintended behaviour by ensuring that the picked and manual consumption booleans change only when the quantity differs from the demand. TaskID:- 5062365
Mobile users now see the template name as the main information when choosing a Sign template, instead of the creation date. This makes it easier to identify the right template and keeps the mobile experience aligned with desktop.
Original PR description
### Issue: - In mobile view, the template list was showing the creation date instead of the template name. - This made it hard to know which template you were selecting. --- ### Fix: - Changed the mobile view to show the template name as the main info. - The creation date is still shown, but as extra information. --- ### Impact: - Easier to find the right template on mobile. - Mobile and desktop views now look consistent. --- Task: 5038933
External values used in tax reports can no longer be changed once the relevant tax return lock date is set, helping preserve submitted tax data. The tax closing process now creates default values before locking the period so normal closing still works while preventing later edits.
Original PR description
[FIX] account_reports: external value check lock date This commit add the check that protects external values from being edited out of the lock date. For example when the tax report is submitted, the…
[FIX] account_reports: external value check lock date This commit add the check that protects external values from being edited out of the lock date. For example when the tax report is submitted, the user is not supposed to modify any external values anymore. To do this, we had to modify the tax closing flow a little bit: when closing the tax period, we now generate the default external values before setting the tax lock date. This is because the generation of the default external values was done for the period we were closing, but now that we forbid the creation of an external value after the lock date we had to change the order of the flow. Due to one specific corner case (l10n_fr), we had to keep a hack to bypass the Tax Return Lock Date check. This was done with a context key and will have to be removed in master. The case is the following : when the user generates the tax closing entry, the external values for the period are generated and the Tax Return Lock Date is set with the last day of the month. Then if the user tries to submit the EDI VAT report, it tries to create 2 external values for the carryover but as the lock date was set, it raises an error. task-5012442 Forward-Port-Of: odoo/enterprise#92949
Fixed an issue where loyalty points could be counted twice after a sales order was confirmed, preventing eligible additional rewards from being applied. Businesses using discount and loyalty programs can now expect all qualifying promotions to work correctly on confirmed orders.
Original PR description
## Versions: 16.0+ ## Issue: After confirming a Sales Order (SO), loyalty points are incorrectly calculated when applying additional promotions. This causes only one reward to be applied instead of…
## Versions:
16.0+
## Issue:
After confirming a Sales Order (SO), loyalty points are incorrectly calculated when applying additional promotions. This causes only one reward to be applied instead of all eligible ones.
## Cause:
When the SO is confirmed, the cost in points for each line is retrieved and deducted to compute remaining available points. However, when promotions are re-applied, the system re-evaluates the total cost of the SO and deducts the points again, effectively double-counting the same lines.
## Steps to reproduce:
- Set up a `Discount & Loyalty` promotion program:
- 2 points granted per purchase (minimum $0).
- Rewards:
- 5% discount on "Simple Pen" (costs 1 point).
- 10% discount on "Whiteboard Pen" (costs 1 point).
- Create a Quotation with "Simple Pen" and "Whiteboard Pen".
- Confirm the Quotation into a Sales Order.
- Apply promotions:
- The first reward applies correctly
- The second reward does not apply
opw-4753472
Forward-Port-Of: odoo/odoo#226656
Forward-Port-Of: odoo/odoo#211342Users can now add several new tags to a forum post at once without triggering an error. This makes forum posting smoother and prevents failed submissions when tags are entered as a comma-separated list.
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 Forward-Port-Of: odoo/odoo#227185 Forward-Port-Of: odoo/odoo#220058
3 changes
Resolved issues and error corrections
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
This fixes an error that could block Ecuadorian delivery guide generation when the Barcode Scanner setting was turned off. Businesses can now create delivery guides reliably regardless of whether barcode scanning is enabled in Inventory.
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 Forward-Port-Of: odoo/enterprise#93775
This fix ensures subscription recurring totals use the amounts returned by external tax calculators instead of being recalculated internally. Businesses using external tax services will see more accurate recurring totals on subscription orders.
Original PR description
sale_subscription now uses `account.tax` to recalculate the tax amounts [1], thus bypassing amounts set by external calculators. For externally calculated orders, we override the recurring_total calculation to restore the previous behavior of calculating the amount using `price_subtotal` on the lines. This field will contain the amount returned by the external calculator. [1] https://github.com/odoo/enterprise/commit/70376f94e9f26e631890312edc0857d9ff37dc7b opw-4964610 Forward-Port-Of: odoo/enterprise#93054
5 changes
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
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
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
12 changes
Resolved issues and error corrections
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#224419Manufacturing 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
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
Fixes Swiss ISO20022 payment exports so bank clearing numbers are placed in the expected XML sub-field. This helps generated payment files better match banking standards and reduces the risk of rejection during payment processing.
Original PR description
### Steps to reproduce: - Install 'account_iso20022', 'l10n_ch' and switch to a Swiss company - Have a bank with a BIC number and an account for that bank with a clearing number - Create a vendor…
### Steps to reproduce: - Install 'account_iso20022', 'l10n_ch' and switch to a Swiss company - Have a bank with a BIC number and an account for that bank with a clearing number - Create a vendor bill for a Swiss partner - Pay with "Swiss ISO20022" - Create a batch payment with that payment and validate - In the XML the field `ClrSysMmbId` contains the clearing number, but it should be in a nested field ([src](https://www.mx-message.com/m/pacs-010-001-05/FIDrctDbt/CdtInstr/Cdtr/FinInstnId/ClrSysMmbId)) ### Cause: The code directly inputs the value of `clearing_number` in `ClrSysMmbId`. ### Solution: Add `MmbId` to contain the clearing number. ### Note: The field `MmbId` when alone is supposed to contain the country's payment system prefix and the clearing number. This commit only input the value of the field `clearing_number` in `MmbId`, so it may be invalid, but at least the architecture is valid. See [this link](https://knowledge.xmldation.com/support/iso20022/general_rules/clearing_codes) for the documentation of `ClrSysMmbId`. This [commit](https://github.com/odoo/enterprise/commit/c277ffa81644b79d95e67a70f7170f5f39c30898#diff-568a46f66108a66d58d845c0e1e00b22db21507ac52576f75b83398112ad10f5) implemented the correct way to set up `ClrSysMmbId` for the Swedish localization. To be always valid, we would need to implement this on all localizations. opw-4872507 Forward-Port-Of: odoo/enterprise#94460
This fixes an issue where tapping Send in Odoo's iOS progressive web app could sometimes fail while writing messages in Discuss or chatter. The message composer no longer shifts at the moment of tapping, making message sending more dependable for mobile users.
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
The time off request dialog now shows the Submit Request button when no warning message is available. This lets employees continue creating absence requests in affected payroll setups while keeping the normal validation after submission.
Original PR description
**Steps to reproduce** 1. Install l10n_ch_hr_payroll_elm_transmission 2. Go to an employee's profile 3. Click on "Absences" smart button 4. Create a new Time Off request Issue: the form view dialog is missing a button to confirm the request. Cause: the dashboard warning message is not part of the l10n_ch_hr_payroll_elm_transmission view. Solution: display the "Submit Request" button if we don't have any dashboard warning message. There will still be a validation after the request is submitted. opw-4972467 Forward-Port-Of: odoo/odoo#221427
The bank reconciliation process now better matches imported bank transactions with payments created in Odoo, even when payment provider memos differ slightly. This helps reduce missed matches and keeps reconciliation smoother for accounting teams.
Original PR description
Commit 4c23de148eb3689842a48df81a5ced772c214861 introduced another query to look for outstanding payments to match in the bank reco widget, aiming to reduce the number of wrong matches found by the algorithm. Doing so, limiting the match between account.payment initiated in odoo and their matching bank transaction imported (through stripe for example), on an exact match of the memo seemed like a good idea. But for obscure reasons, the memo we're sending is not guaranteed to be found back, depending on the payment provider and the import flow. Also, for backward compatibility, it now appears important to allow the match to be on a part of the memo, like we used to do. So we're back on a solution that splits the memo using ' - '. Forward-Port-Of: odoo/enterprise#93237
This fix ensures the point of sale receives cancellation updates from Worldline payment terminals even after the browser page is refreshed. This prevents orders from getting stuck during cancelled card payments and adds clearer terminal error messages for staff.
Original PR description
This PR fixes a bug where the point of sale didn't receive notifications from the Worldline payment terminal for the cancellations if the browser webpage was refreshed How to reproduce: 1. Open a POS session with Worldline terminal 2. Send a transaction to the terminal 3. Refresh the browser webpage before paying 4. Click on "Cancel" on the POS screen --> your order will be stuck and never receive the confirmation This PR removes the check for the iot longpolling action identifier which changes on refresh of the webpage + adds more error messages for Worldline terminals Related PR in v17 -> saas-18.2: https://github.com/odoo/enterprise/pull/94635 task-5075860 Forward-Port-Of: odoo/enterprise#94629
This fixes imported sales orders so lines for products that cannot be matched no longer have their price reset to zero. It helps preserve the original RFQ/order values when exchanging documents between databases with different product catalogs.
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 Forward-Port-Of: odoo/odoo#226859
Quicksign now behaves consistently with regular signing by showing the completed signature in document previews and recording the signing activity in the related discussion history. This helps users trust that signed documents are complete and keeps document records easier to audit.
Original PR description
### Issues: - PDF preview mismatch: - Regular sign updates the preview in Documents with the actual signature. - Quicksign only shows placeholders in the preview. - Missing chatter logs: - Regular sign from chatter creates a 'Signature Request' log and stores the signed certificate in Documents. - Quicksign skips chatter logs and only displays in Sign app. ### Cause: - Request is fully signed but the sign request item state is not set as completed that's why the value was not shown. - The function to sign and create log is not called when reference doc is set. ### Fix: - Sign request item state is set to completed. - Called the function to throw log note when the reference doc is set. ### Impact: - Quicksign now provides consistent PDF previews. - Chatter history and document logging are aligned between regular signing and quicksign. --- task-5082925
This fixes calendar quick editing so that when a meeting start time is changed, the end time is recalculated using the intended duration. It prevents appointment lengths from being unexpectedly recomputed or changed during quick creation and editing.
Original PR description
`CalendarEvent._compute_stop` relies on "duration" being somehow available when "start" is changed. In quick-create, where the duration is not stored we need to "store" it in the front-end between onchange calls. For this reason "duration" needs to be force_save and invisible on the view so that it is not recomputed each time. Which otherwise defeats the purpose of the feature. In appointment duration is also used in default_get hence fetching a default value for it by having it in view actually changes the behavior of the default values. Though this can be mitigated in other, more reliable ways, this fix is sufficient for that case too. The field was removed during view refactoring in odoo/enterprise@c8eb4fe4ba9938b1c7e07034e6ca7c08a0d6f215 and 81e51985f2e01ee3ff115477ab324e2ad75a1b77 task-5081903
11 changes
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
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
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
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
Sales orders created from a branch company can now be confirmed when they use loyalty programs owned by the parent company. This prevents access errors and keeps loyalty discounts and history working consistently across company branches.
Original PR description
If you have a company parent with loyaltly programs and you try to confirm a sale order from a child company, an access error will be raised. Steps to reproduce: ------------------- * Create a…
If you have a company parent with loyaltly programs and you try to confirm a sale order from a child company, an access error will be raised. Steps to reproduce: ------------------- * Create a loyalty cards program * Set company to the current company * Create a branch company for the current one * Switch to branch company * Create a sale order, no need to add products, just a partner * Try to confirm the order > Observation: Access Error: > Sorry, Mitchell Admin (id=2) doesn't have 'create' access to: > -History for Loyalty cards and Ewallets (loyalty.history) Why the fix: ------------ Here's where the access error is being triggered: https://github.com/odoo/odoo/blob/35ea3dcb2eeb379c8b1127f0c7b42191853c0bd2/addons/sale_loyalty/models/sale_order.py#L106 Branches currently have access to the discounts & loyalty programs from the parent company, we extend the access to include loyalty history. Another solution could be to create the loyalty history using sudo() if the coupon's program id is a parent of the current company. opw-5055999
This fixes an issue where Point of Sale orders could remain stuck if the browser was refreshed before cancelling a Worldline terminal payment. The POS now continues receiving the cancellation confirmation, reducing checkout disruption and manual recovery for staff.
Original PR description
This PR fixes a bug where the point of sale didn't receive notifications from the Worldline payment terminal for the cancellations if the browser webpage was refreshed How to reproduce: 1. Open a POS session with Worldline terminal 2. Send a transaction to the terminal 3. Refresh the browser webpage before paying 4. Click on "Cancel" on the POS screen --> your order will be stuck and never receive the confirmation This PR removes the check for the iot longpolling action identifier which changes on refresh of the webpage + adds more error messages for Worldline terminals Related PR in >= saas-18.3: https://github.com/odoo/enterprise/pull/94629 task-5075860 Forward-Port-Of: odoo/enterprise#94635
8 changes
Resolved issues and error corrections
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 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
Shiprocket Cash on Delivery shipments now correctly include coupon discount amounts when orders are sent to Shiprocket. This helps ensure the amount collected from customers reflects promotional discounts, avoiding overcharging and reconciliation issues.
Original PR description
Issue ----- When using Shiprocket with the "Cash On Delivery", the request sent to the Shiprocket API doesn't contain the amounts discounted by coupons. Steps to reproduce ----- - Set an Indian…
Issue
-----
When using Shiprocket with the "Cash On Delivery", the request sent to the Shiprocket API doesn't contain the amounts discounted by coupons.
Steps to reproduce
-----
- Set an Indian company up (with valid address and some dummy mail & phone)
- Create a customer "IN Cust" (with valid address and some dummy mail & phone)
- Create a product "IN Prod"
- Sale price: 1000 INR
- Weight: 100g
- Set some reference, eg "INPROD"
- Create a Shiprocket delivery method
- Payment Method: COD
- Set some "Shiprocket Channel"
- Enable Debug requests
- In settings, enable "Promotions, Loyalty & Gift Card"
- Go to Sales > Products > Discount & Loyalty
- Create a new program
- Name: 50% off
- Program Type: Coupons
- Change the existing reward to 50% discount on order
- Generate some coupon
- Copy the code of the generated coupon
- Create a SO our product and customer
- Use the coupon code & apply the 50% discount
- Add shipping
- Shiprocket COD
- Get rate
- Confirm the SO
- Go to the picking & validate it
- Open logs (Settings/Technical/Database Structure/Logging)
- Open the "shiprocket_request_external/shipments/create/forward-shipment" log
--> total_discount is 0
Cause
-----
The problem comes from
https://github.com/odoo/enterprise/blob/a971f55e736f9645eda137fd6dcb574483886483/delivery_shiprocket/models/shiprocket_request.py#L301
There are 2 issues here.
The first and most important one is how we find the discount lines.
https://github.com/odoo/enterprise/blob/a971f55e736f9645eda137fd6dcb574483886483/delivery_shiprocket/models/shiprocket_request.py#L320
Discounts from coupons don't use the `sale_discount_product_id`. We can use the `_can_be_invoiced_alone` function to find both regular and loyalty discounts
https://github.com/odoo/odoo/blob/ee63fe7863dfa0083674dc927c1aa67c9e36c481/addons/sale/models/sale_order_line.py#L1033-L1041
def _can_be_invoiced_alone(self):
""" Whether a given line is meaningful to invoice alone.
It is generally meaningless/confusing or even wrong to invoice some specific SOlines
(delivery, discounts, rewards, ...) without others, unless they are the only left to invoice
in the SO.
"""
self.ensure_one()
return self.product_id.id != self.company_id.sale_discount_product_id.id
https://github.com/odoo/odoo/blob/ee63fe7863dfa0083674dc927c1aa67c9e36c481/addons/sale_loyalty/models/sale_order_line.py#L50-L51
def _can_be_invoiced_alone(self):
return super()._can_be_invoiced_alone() and not self.is_reward_line
We just have to be careful not to accidentally include delivery fees because of
https://github.com/odoo/odoo/blob/ee63fe7863dfa0083674dc927c1aa67c9e36c481/addons/delivery/models/sale_order_line.py#L18-L19
def _can_be_invoiced_alone(self):
return super()._can_be_invoiced_alone() and not self.is_delivery
The second issue is that we use the untaxed discount amount.
https://github.com/odoo/enterprise/blob/a971f55e736f9645eda137fd6dcb574483886483/delivery_shiprocket/models/shiprocket_request.py#L321
This leads to an incoherent total amount, since the tax is computed on the products' full prices. We should instead be forwarding the total discount value (with tax included to offset the taxes applied on the full product price).
-----
Community PR:
https://github.com/odoo/odoo/pull/223517
Ticket:
opw-4755357This fix ensures coupon and loyalty discounts are properly recognized on sales orders so Shiprocket Cash on Delivery requests include the correct discounted amounts. It also prevents manually created discount lines from being reset to zero when their quantity changes, improving order total accuracy.
Original PR description
Issue ----- When using Shiprocket with the "Cash On Delivery", the request sent to the Shiprocket API doesn't contain the amounts discounted by coupons. Steps to reproduce ----- - Set an Indian…
Issue ----- When using Shiprocket with the "Cash On Delivery", the request sent to the Shiprocket API doesn't contain the amounts discounted by coupons. Steps to reproduce ----- - Set an Indian company up (with valid address and some dummy mail & phone) - Create a customer "IN Cust" (with valid address and some dummy mail & phone) - Create a product "IN Prod" - Sale price: 1000 INR - Weight: 100g - Set some reference, eg "INPROD" - Create a Shiprocket delivery method - Payment Method: COD - Set some "Shiprocket Channel" - Enable Debug requests - In settings, enable "Promotions, Loyalty & Gift Card" - Go to Sales > Products > Discount & Loyalty - Create a new program - Name: 50% off - Program Type: Coupons - Change the existing reward to 50% discount on order - Generate some coupon - Copy the code to the generated coupon - Create a SO our product and customer - Use the coupon code & apply the 50% discount - Add shipping - Shiprocket COD - Get rate - Confirm the SO - Go to the picking & validate it - Open logs (Settings/Technical/Database Structure/Logging) - Open the "shiprocket_request_external/shipments/create/forward-shipment" log --> total_discount is 0 Cause ----- The problem comes from https://github.com/odoo/enterprise/blob/a971f55e736f9645eda137fd6dcb574483886483/delivery_shiprocket/models/shiprocket_request.py#L301 There are 2 issues here. The first and most important one is how we find the discount lines. https://github.com/odoo/enterprise/blob/a971f55e736f9645eda137fd6dcb574483886483/delivery_shiprocket/models/shiprocket_request.py#L320 Discounts from coupons don't use the `sale_discount_product_id`, we'll have to define a new function to override in `sale_loyalty` for this. The second issue is that we use the untaxed discount amount. https://github.com/odoo/enterprise/blob/a971f55e736f9645eda137fd6dcb574483886483/delivery_shiprocket/models/shiprocket_request.py#L321 This leads to an incoherent total amount, since the tax is computed on the products' full prices. We should instead be forwarding the total discount value (with tax included to offset the taxes applied on the full product price). ----- Enterprise PR: https://github.com/odoo/enterprise/pull/92310 Ticket: opw-4755357
The data merge process now ignores company differences when a database only uses one company. This lets users find and merge duplicate records that were previously missed, improving data cleanup accuracy.
Original PR description
**Issue** In single company databases, it wasn't possible to find duplicate records with different `company_id` values to merge them (in multi company databases, it is possible to enable the "Cross-Company" option on the deduplication rule). **Change** Always ignore the company field in single company databases. opw-4794408
The appointment booking page now shows the correct maximum number of people based on all available resources, rather than being limited by the first resource found. This prevents customers from seeing too few available spots and helps businesses make full use of their appointment capacity.
Original PR description
**How to reproduce:** - Create an appointment with availability assigned to a resource. - Enable 'Manage Capacity' - Set the capacity of the first resource lower than the second one. - Open the appointment's booking page. **Technical Reason:** If appointment is scheduled based on 'resource_time' then resource_default is updated as the first value of resource_possible. Related PR: https://github.com/odoo/enterprise/pull/47059 **After this PR:** 'Number of people' dropdown will display the maximum capacity from all available resources. Task-4664393
Customers who paid an invoice can now update their billing address when no country was previously set, even if VAT details are locked. This prevents them from being stuck with incomplete billing information in the portal.
Original PR description
After paying an invoice, a customer without a billing country cannot update the country in their billing address because the form is disabled by the VAT edition rule. **Steps to reproduce:** 1.…
After paying an invoice, a customer without a billing country cannot update the country in their billing address because the form is disabled by the VAT edition rule. **Steps to reproduce:** 1. Create a customer without a billing country. 2. Generate an invoice for that customer. 3. Pay the invoice (possible with some payment providers). 4. Go to the customer portal and try to update the billing address. The country field is disabled if VAT is not editable, preventing the customer from setting their country. This fix ensures that if the partner has no country set, the field remains editable even when the VAT field is locked. NOTE: Some payment providers indeed do not allow paying an invoice or a sale order without a country being set, but when this situation occurs the portal must still allow the customer to complete their billing address afterwards. **NOTE: This fix is applied starting from Odoo 17, but the issue mainly affects later versions in the `website_sale` module, where the country field is blocked in the checkout form.** --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr