…workflow

This commit integrates the Dutch SBR tax reporting process into the `account.return` workflow to provide better visibility, UI feedback, and tracking for users.

Main changes:
* Added a new `l10n_nl_sbr_status` field (Pending, Accepted, Error) to `account.return` to track the submission status for Kanban UI color coding.
* Updated the Kanban view to dynamically apply custom CSS classes (`nl-sbr-error`, `nl-sbr-pending`) to the state bubble based on the SBR status.
* Introduced an `action_refresh_sbr_status` method and a corresponding "Refresh" button in the Kanban view to manually trigger the status check cron.
* Consolidated Chatter messages so that status updates, errors, and submission success notifications log directly on the `account.return` record rather than the closing entry.
* Added an `action_reset_tax_return_common` override to prevent resetting or modifying a tax return once it has been accepted by Digipoort.
* Modified the UI to hide the "Pay" button unless the SBR return has been fully accepted.
* Updated `_on_post_submission_event` to block further processing of the return until the SBR report is accepted.

task-6034675

Forward-Port-Of: odoo/enterprise#110516

### Steps to reproduce:

- Create a kit product with 6 bom lines (with a `cost_share` of `0.0%`)
- Create + confirm a purchase order for 1 unit of the kit product at 60
- Validate the delivery

#### > 6 layers were created with values 9.99, 10, 10, 10, 10 and 10

There are two issues with purchased kit valuation addressed in this PR:

### Issue 1:

Since 8c199f7783527735b35c9fbda334cbdcd55a004f, the product price unit is not supposed to be rounded anymore. However, kit products rely on the rounded `cost_share` field of the `mrp.bom.line` to determine which part of the price of the kit product is handled by which component: https://github.com/odoo/odoo/blob/591102ff37fef1f0b9a946fee3f9d85789653e65/addons/mrp/models/stock_move.py#L245-L246 https://github.com/odoo/odoo/blob/591102ff37fef1f0b9a946fee3f9d85789653e65/addons/purchase_mrp/models/stock_move.py#L28 https://github.com/odoo/odoo/blob/591102ff37fef1f0b9a946fee3f9d85789653e65/addons/purchase_mrp/models/stock_move.py#L38

This leads to inevitable rounding issues where `60/6` does not match `10`: https://github.com/odoo/odoo/blob/591102ff37fef1f0b9a946fee3f9d85789653e65/addons/purchase_mrp/tests/test_purchase_mrp_flow.py#L1273-L1275 simply because 1/6 is represented  as `16.67%` and not by `16.66666666666666%`. However, values such as 1/6 can be obtained if you do not set any `cost_share`, since the kit explosion will equidistribute its cost share:
https://github.com/odoo/odoo/blob/591102ff37fef1f0b9a946fee3f9d85789653e65/addons/purchase_mrp/models/mrp_bom.py#L42-L48

### Fix of this issue:

We set the digits to `False` for stability reason as the columns have 
been initiallised as "numeric" values and needs to stay numeric:
https://github.com/odoo/odoo/blob/b007b0a4f7e56f6dc44df3154e13745c9981eae3/odoo/fields.py#L1627-L1650

Note that when the digit is Falsy on the field, the field value is formatted to the second digit by the front end:
https://github.com/odoo/odoo/blob/3542c542eac5b204e69a8dd6ae1907cfcef60af3/addons/web/static/src/views/fields/float/float_field.js#L58-L76
https://github.com/odoo/odoo/blob/12e453302a950df4d9ee45954f54bdf610888eda/addons/web/static/src/core/utils/numbers.js#L214-L227

In particular, when we create the bom and set the `cost_share`, all possible values will be rounded to the second decimal just as before. This change will therefore only alter the rounding behavior in the DB for equidistributed values such as `16.66666666666666%`.

### Issue 2:

While the value of the kit product is exploded and distributed among components, the values of each individual `stock.valuation.layer` are themselves rounded before creation based on the company currency: https://github.com/odoo/odoo/blob/4188436a9e800b062bf9f3b0055cad86acc47e19/addons/stock_account/models/product.py#L240-L255 https://github.com/odoo/odoo/blob/4188436a9e800b062bf9f3b0055cad86acc47e19/addons/stock_account/models/stock_valuation_layer.py#L30

Now, this is problematic since the sum of the values of the layers is expected to match the total value of the purchase order line (that is, the non-rounded value of the components of the purchased kit).

### Fix of this issue:

We compute and distribute the rounding error among layers corresponding to the purchased kit product before creation (since layer values are not expected to be modified afterwards), based on the non-rounded computation, since this value should now be exact (as the unit cost is not rounded anymore).

opw-5085457
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#258124
Forward-Port-Of: odoo/odoo#252034

Issue:
----------------------------------------
When we have a fully flexible employee and a public holiday for another company, opening the planning app raises a traceback.

Steps to reproduce:
----------------------------------------
- Have Planning and Time Off installed
- Create a public holiday for another company
- Create an employee with no calendar
- Open Planning and try to add the new employee
- Traceback

Cause:
----------------------------------------
This commit 55ce1e3411d0693807d883ac159039b8141ff6b6 added the new method called `_get_flexible_resource_valid_work_intervals()` which will call `_leave_intervals_batch()` on `self.env['resource.calendar']`. In `_leave_intervals_batch()`, the resource list will contain the fully flexible employee and `self.env['resource.resource']`.

During the handling of the public holiday we created, we loop through the resource list. 
The first one is the flexible employee, but it gets skipped by the `continue` as it has a different company. Because of this the variable `tz` still equals `None`. 
The second resource is `self.env['resource.resource']` which doesn't validate the condition to be skipped. So it reaches the line
```py
tz = tz if tz else timezone((resource or self).tz)
```

But `tz` is still `None` and both `resource` and `self` are empty, so it gives `False` to the timezone constructor, which crashes.

Solution:
----------------------------------------
Add a default value to 'UTC' to handle this specific case.

opw-6107269

Forward-Port-Of: odoo/odoo#259404

### Issue before this commit:
When handling many2many fields with a large number of records (e.g., 20k+), the client-side performance degraded significantly. In extreme cases, the browser became unresponsive or crashed when triggering onchange or compute logic.

### Steps to Reproduce:
Create a computed many2many field.
Add it to a form view (can be invisible).
Populate the related model with a large dataset (20k+ records). Trigger an onchange that recomputes the field.

### Cause of the Issue:
In _applyCommands (LINK case), the system checks for existing record IDs using Array.includes(), which has O(n) time complexity.
When handling thousands of records, repeated ID lookups using includes() result in O(n²) complexity.

### With This Commit:
Replaced Array.includes() with a Set (Set.has()), reducing lookup time to O(1). The set is updated incrementally as new IDs are added, improving overall complexity to O(n) and preventing UI freezes for large datasets.

opw-6122024

Forward-Port-Of: odoo/odoo#261093
Forward-Port-Of: odoo/odoo#260993

### Issue before this commit:
The "Source" (origin) field was missing from the PDF of replacement invoices. While the original invoice correctly displayed the Sales Order reference, the new invoice generated through the request cancel process had an empty origin field.

### Steps to reproduce the issue:
1. Download Sales and l10n_mx
2. Set a UNSPSC Category for one product
3. Go to Sales, create a new Quotation and confirm it
4. Create invoice, confirm and send & print
5. Request cancel button -> create replacement invoice
6. In the new invoice there is no source origin invoice

### Cause of the issue:
The invoice_origin field is defined with copy=False. Since the replacement logic uses the copy_data method without explicitly passing the origin value, the field was automatically cleared during the creation of the new invoice.

### Reason to introduce the fix:
To ensure document traceability, the fix explicitly passes the invoice_origin from the original invoice to the replacement. This maintains the link to the Sales Order in the database and ensures the "Source" label appears on the printed PDF.

opw-6070016

Forward-Port-Of: odoo/enterprise#114099

Steps to reproduce:
Bug 1 (The Crash):
1. Open Documents app, select a PDF, and click Action > Sign.
2. In the Sign app, delete the newly created Sign Template.
3. Return to the Documents app.
4. A traceback occurs (`KeyError: <document_id>`) in `web_read`.

Bug 2 (The Broken Lineage):
1. Create two separate Sign Templates from the exact same Document.
2. Send a signature request from the second template.
3. The `reference_doc` on the signature request fails to link back to the original Document.

Current behavior:
When creating a sign template from a document, `documents_sign` intentionally unlinks the original `ir.attachment` (`res_model = False`) to pass custody to `sign.document`. If the template is deleted, the attachment is orphaned, permanently corrupting the original `documents.document` and crashing the UI. 
Furthermore, the lineage tracking (`reference_doc`) relies strictly on a 1:1 shared `attachment_id`. If a user creates multiple templates from one document, the system is forced to make a copy for the second template, natively breaking the lineage tracking because the IDs no longer match.

Expected behavior:
Documents should not be corrupted when generating or deleting sign templates. Furthermore, lineage tracking (`reference_doc`) should successfully link back to the original document regardless of how many templates have been generated from it.

Fix:
1. Replaced the `res_model = False` custody-handoff hack in `documents_sign` with a safe `.copy({'original_id': attachment.id})`. This sandboxes the Sign app's files, completely preventing the deletion crash and the multi-template conflicts.
2. Updated the `reference_doc` computation in `sign.request` to dynamically search for both the current `attachment_id` AND its `original_id` (utilizing a minimal-diff recordset union `|`). This perfectly preserves the lineage tracking for all templates without requiring database schema changes.

Task: 5432116

Forward-Port-Of: odoo/enterprise#114221
Forward-Port-Of: odoo/enterprise#113167

**Steps to reproduce:**
* Install the *Inventory* (`stock`) module.
* Create a *Storable Product* and set some *On Hand* quantity.
* Go to *Inventory → Operations → Receipts*.
* Create a new receipt.
* Add the product with a *Demand* quantity (e.g. 10).
* Validate the receipt:
  * Case 1: Validate with less quantity than demand (e.g. 8) and choose *No Backorder*.
  * Case 2: Validate with more quantity than demand (e.g. 12).
* Click on *Print( Delivery Slip)*.

**Observed behavior:**
* The *Ordered Quantity* is equal to the *Delivered Quantity*.
  * Case 1 (Demand=10, Done=8):
    * Ordered = 8, Delivered = 8.
  * Case 2 (Demand=10, Done=12):
    * Ordered = 12, Delivered = 12.

**Expected behavior:**
* Case 1 (Demand=10, Done=8):
    * Ordered = 10, Delivered = 8.
  * Case 2 (Demand=10, Done=12):
    * Ordered = 10, Delivered = 12.

 **Cause:**
* Clicking on *Print* triggers `stock.action_report_delivery`: https://github.com/odoo/odoo/blob/5c1000cb11da64bf317f9bd9b0ae71f6fbea910d/addons/stock/views/stock_picking_views.xml#L156
* This renders `stock.report_deliveryslip`: https://github.com/odoo/odoo/blob/5c1000cb11da64bf317f9bd9b0ae71f6fbea910d/addons/stock/report/stock_report_views.xml#L14
* The QWeb template calls `report_delivery_document`: https://github.com/odoo/odoo/blob/5c1000cb11da64bf317f9bd9b0ae71f6fbea910d/addons/stock/report/report_deliveryslip.xml#L288-L292
* Which relies on `_get_aggregated_product_quantities`: https://github.com/odoo/odoo/blob/5c1000cb11da64bf317f9bd9b0ae71f6fbea910d/addons/stock/report/report_deliveryslip.xml#L157

CASE- 1
* When validating with *less quantity* and *no backorder*:
  * In `_get_aggregated_product_quantities`, `qty_ordered` is initialized to `None` and only set when `backorders and not kwargs.get('strict')`: https://github.com/odoo/odoo/blob/5c1000cb11da64bf317f9bd9b0ae71f6fbea910d/addons/stock/models/stock_move_line.py#L881
  * If no backorder exists, the condition fails and `qty_ordered` remains `None` and it come out of condition
  * where it take  quantity `'qty_ordered': qty_ordered or quantity,` https://github.com/odoo/odoo/blob/5c1000cb11da64bf317f9bd9b0ae71f6fbea910d/addons/stock/models/stock_move_line.py#L898
  * As a result, *Ordered Quantity* becomes equal to *Delivered Quantity*.

CASE-2
* When validating with *more quantity* than demanded:
  * `_action_done` creates an extra move using `_create_extra_move()`: https://github.com/odoo/odoo/blob/5c1000cb11da64bf317f9bd9b0ae71f6fbea910d/addons/stock/models/stock_move.py#L1936
  * The extra move is merged back via `_action_confirm(merge_into=self)`: https://github.com/odoo/odoo/blob/5c1000cb11da64bf317f9bd9b0ae71f6fbea910d/addons/stock/models/stock_move.py#L1878
  * The original move keeps `product_uom_qty = 10` but now has two move lines (10 + 2).
  * In `_get_aggregated_product_quantities`: Both move lines share the same `line_key`
- **ML1** → `line_key` not yet in dict → enters [if] https://github.com/odoo/odoo/blob/5c1000cb11da64bf317f9bd9b0ae71f6fbea910d/addons/stock/models/stock_move_line.py#L880 **ML2** → `line_key` already in dict → enters `else` block https://github.com/odoo/odoo/blob/5c1000cb11da64bf317f9bd9b0ae71f6fbea910d/addons/stock/models/stock_move_line.py#L901-L903
  → `qty_ordered += 2`  →  `qty_ordered = 12`  ✗  (surplus added to demand)
  → `quantity += 2`     →  `quantity = 12`      ✓
  * The `else` branch was designed to aggregate multiple lines of the
same product (e.g. two lot lines). The bug was that it added the
**done qty** of each line to `qty_ordered` unconditionally, causing
the surplus from over-delivery to inflate the ordered quantity.

* After the fix:
  * Case 1 (Demand=10, Done=8):
    * Ordered = 10, Delivered = 8.
  * Case 2 (Demand=10, Done=12):
    * Ordered = 10, Delivered = 12.
    
*  NOTE:
Adapt the existing test case `test_kit_packaging_delivery_slip`
 to reflect the corrected behavior of delivery validation.
The test was originally introduced in this [commit](https://github.com/odoo/odoo/pull/161920/changes/47da1ec13a2189e826d3b0539e6494e35990ccc1).
Its main objective is to ensure that the Delivery Slip report prints successfully

Previously, when validating a transfer with:
Delivered quantity less than the demanded quantity, No backorder created
the Ordered Quantity was being reduced(24->12) to the delivered quantity.
After the fix, the Ordered Quantity correctly remains equal(24->24) to the original demand.

<details>
  <summary>Click here to see the results:</summary>

  <p><strong>Before:</strong></p>
  <div>
    <img src="https://github.com/user-attachments/assets/88d24079-b278-4ef9-bff2-c7f14fe7ecb7" />
    <img src="https://github.com/user-attachments/assets/c6181771-7d91-4ffe-9ed8-17dffac346f7" />
  </div>

  <p><strong>After:</strong></p>
  <div>
    <img src="https://github.com/user-attachments/assets/6ed57881-8af3-42ad-94d4-7c44a5b9b00e" />
    <img src="https://github.com/user-attachments/assets/b5506c81-3ed9-416b-8099-108a75588b13" />
  </div>
</details>

---

opw-5874759

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#250587

### Issue before this commit:
The "Source" (origin) field was missing from the PDF of replacement invoices. While the original invoice correctly displayed the Sales Order reference, the new invoice generated through the request cancel process had an empty origin field.

### Steps to reproduce the issue:
1. Download Sales and l10n_mx
2. Set a UNSPSC Category for one product
3. Go to Sales, create a new Quotation and confirm it
4. Create invoice, confirm and send & print
5. Request cancel button -> create replacement invoice
6. In the new invoice there is no source origin invoice

### Cause of the issue:
The invoice_origin field is defined with copy=False. Since the replacement logic uses the copy_data method without explicitly passing the origin value, the field was automatically cleared during the creation of the new invoice.

### Reason to introduce the fix:
To ensure document traceability, the fix explicitly passes the invoice_origin from the original invoice to the replacement. This maintains the link to the Sales Order in the database and ensures the "Source" label appears on the printed PDF.

opw-6070016

Forward-Port-Of: odoo/enterprise#114099

### Issue before this commit:
The "Source" (origin) field was missing from the PDF of replacement invoices. While the original invoice correctly displayed the Sales Order reference, the new invoice generated through the request cancel process had an empty origin field.

### Steps to reproduce the issue:
1. Download Sales and l10n_mx
2. Set a UNSPSC Category for one product
3. Go to Sales, create a new Quotation and confirm it
4. Create invoice, confirm and send & print
5. Request cancel button -> create replacement invoice
6. In the new invoice there is no source origin invoice

### Cause of the issue:
The invoice_origin field is defined with copy=False. Since the replacement logic uses the copy_data method without explicitly passing the origin value, the field was automatically cleared during the creation of the new invoice.

### Reason to introduce the fix:
To ensure document traceability, the fix explicitly passes the invoice_origin from the original invoice to the replacement. This maintains the link to the Sales Order in the database and ensures the "Source" label appears on the printed PDF.

opw-6070016

Forward-Port-Of: odoo/enterprise#114099

**problem:**
On timesheets, the overtime indication next to an employee's name is incorrect when using flexible work schedules. for example: a "Flexible 20h" schedule (4h a day) shows 1h of negative overtime even when the employee has logged exactly 20h for the week.

**steps to reproduce:**
1. Create a new working schedule with flexible hours enabled for example (20h/week, 4h/day average)
2. Assign this schedule to an employee
3. Go to Timesheets, search for the employee
4. Navigate to a past week
5. Enter 4h on each working day
6. Observe the overtime indication shows incorrect value (-01:00)

**cause:**
In `resource/models/resource_calendar.py`, the flexible hours algorithm that determines the date range by converts UTC boundaries to the employee's timezone. When the employee's timezone has a positive UTC offset (UTC+1, like in brussels time zone), `Sun 23:59:59 UTC` becomes `Mon 00:59:59 CET`, pushing `end_date` to the next Monday. This creates an 8 day range instead of 7. The algorithm then starts a new weekly budget for the spillover day and allocates 1 extra hour, making `allocated_hours` 20.9999998 instead of 20.

**fix:**
- Use the UTC date before conversion to the employee's timezone when determining the flexible date range.
- prefer `self` when it is the flexible calendar being queried, so hr_contract's `_get_calendar_at()` override cannot substitute the contract's calendar parameters (full_time_required_hours, hours_per_day) for the flexible ones.

**note**
Updating the test (`test_no_carried_over_leaves_for_flexible_resource`) in `hr_holidays/tests/test_expiring_leaves.py` expected duration logic, is to match the corrected inclusive day range and prevent asserting the previous spillover behavior.
link to the enterprise PR: https://github.com/odoo/enterprise/pull/112879

link to the community PR: https://github.com/odoo/odoo/pull/257269

opw-5970511

---

I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/enterprise#112879

### Issue before this commit:
The "Source" (origin) field was missing from the PDF of replacement invoices. While the original invoice correctly displayed the Sales Order reference, the new invoice generated through the request cancel process had an empty origin field.

### Steps to reproduce the issue:
1. Download Sales and l10n_mx
2. Set a UNSPSC Category for one product
3. Go to Sales, create a new Quotation and confirm it
4. Create invoice, confirm and send & print
5. Request cancel button -> create replacement invoice
6. In the new invoice there is no source origin invoice

### Cause of the issue:
The invoice_origin field is defined with copy=False. Since the replacement logic uses the copy_data method without explicitly passing the origin value, the field was automatically cleared during the creation of the new invoice.

### Reason to introduce the fix:
To ensure document traceability, the fix explicitly passes the invoice_origin from the original invoice to the replacement. This maintains the link to the Sales Order in the database and ensures the "Source" label appears on the printed PDF.

opw-6070016

Forward-Port-Of: odoo/enterprise#114099

The system will crash when we receive nothing in `response` and also tryig to retrieve values from response.

**Error:-**
`TypeError: 'NoneType' object is not subscriptable`

**Root Cause:-**
- While we are in `EC Company`.
- When we click `Process Now` on the invoice. It will call `button_process_edi_web_services` method. And while in execution when at [1], `move.company_id._l10n_ec_is_demo_environment()` is `False`, then it calls `_l10n_ec_send_document` method.
- While submitting electronic invoices to SRI, the method `_l10n_ec_get_client_service_response_new()` sometimes returns `None` .
- It may also lack expected keys like 'estado' or 'comprobantes', depending on SRI’s behavior.

[1]
https://github.com/odoo/enterprise/blob/ce9eed675db4de3bcd1b283688c5c44d2e1ecf12/l10n_ec_edi/models/account_edi_format.py#L425-L428

**Solution:-**
- Wrapped the access to response and its keys inside a `try...except` block that catches:- 
   - `TypeError`: for cases where the response is `None`.


**Sentry - 6708486009, 6728767866**

Forward-Port-Of: odoo/enterprise#88611

Before this PR:
Placeholder for empty char/text fields were disappearing in editor.
<br>

Steps to reproduce:
1. Open any appointment page with an operator assigned.
2. Go into edit mode.
3. The field with the placeholder "Add a function here..." will disappear.
> Similar issue can be seen for any char/text field types.
<br>

The issue occurs after the https://github.com/odoo/odoo/pull/165197 update, which uses the fillEmpty utility function to add:
- \<br> in empty **block** fields (char/text)
- and Zero Width Space (ZWS) in empty **inline** fields (char/text)

Since placeholders for fields are added via SCSS targeting empty fields, the char/text fields are no longer considered empty due to the \<br> tag and ZWS. As a result, placeholders are not displayed.
<br>

This fix ensures that the SCSS now applies the same styling to fields if they are empty, contain only a \<br> tag, or contain only ZWS.

Additionally, the value for `data-oe-zws-empty-inline` attribute is now updated dynamically, enabling CSS to target fields with only ZWS content, as ZWS cannot be selected directly from CSS.
<br>

task-4297507

Forward-Port-Of: odoo/odoo#187892

Description of the issue/feature this PR addresses:
allow portal attendees to be synced by google calendar

Current behavior before PR:
There was an `AccessError` happening when:
- One portal user was invited to more than one event.
- At least one of them was going to be notified in the future.
- Google cancelled the first of those.

<details>

```
2024-12-11 10:19:02,144 31 INFO odoo odoo.addons.base.models.ir_cron: Manually starting job `Google Calendar: sincronización`.
2024-12-11 10:19:02,151 31 INFO odoo odoo.addons.google_calendar.models.res_users: Calendar Synchro - Starting synchronization for res.users(29,)
2024-12-11 10:19:02,539 31 INFO odoo odoo.addons.google_calendar.models.res_users: Calendar Synchro - Starting synchronization for res.users(15,)
2024-12-11 10:19:03,029 31 INFO odoo odoo.addons.google_calendar.models.res_users: Calendar Synchro - Starting synchronization for res.users(50,)
2024-12-11 10:19:03,414 31 INFO odoo odoo.addons.google_calendar.models.res_users: Calendar Synchro - Starting synchronization for res.users(40,)
2024-12-11 10:19:03,823 31 INFO odoo odoo.addons.google_calendar.models.res_users: Calendar Synchro - Starting synchronization for res.users(52,)
2024-12-11 10:19:04,219 31 INFO odoo odoo.addons.google_calendar.models.res_users: Calendar Synchro - Starting synchronization for res.users(10,)
2024-12-11 10:19:04,580 31 INFO odoo odoo.addons.google_calendar.models.res_users: Calendar Synchro - Starting synchronization for res.users(28,)
2024-12-11 10:19:04,936 31 INFO odoo odoo.addons.google_calendar.models.res_users: Calendar Synchro - Starting synchronization for res.users(2,)
2024-12-11 10:19:05,501 31 INFO odoo odoo.models.unlink: User #2 deleted mail.message records with IDs: [1055490, 1055487, 1055480, 1055478, 1055403]
2024-12-11 10:19:05,518 31 INFO odoo odoo.models.unlink: User #2 deleted calendar.event records with IDs: [2920874, 2920875, 2920880]
2024-12-11 10:19:05,520 31 INFO odoo odoo.models.unlink: User #2 deleted mail.followers records with IDs: [6232226, 6232227, 6232228, 6232229, 6232230, 6232231, 6232232, 6232233, 6232234, 6232235, 6232236, 6232237, 6232238, 6232239, 6232240, 6232241, 6232242, 6232243, 6232270, 6232271, 6232272, 6232283]
2024-12-11 10:19:05,544 31 INFO odoo odoo.addons.base.models.ir_model: Access Denied by ACLs for operation: read, uid: 65, model: calendar.alarm
2024-12-11 10:19:05,545 31 INFO odoo odoo.addons.base.models.ir_model: Access Denied by ACLs for operation: read, uid: 65, model: calendar.alarm
2024-12-11 10:19:05,545 31 ERROR odoo odoo.addons.google_calendar.models.res_users: [res.users(2,)] Calendar Synchro - Exception : No puede ingresar a los registros 'Event Alarm' (calendar.alarm)

Se permite esta operación para los grupos siguientes:
      - User types/Internal User

Póngase en contacto con su administrador para solicitar acceso si es necesario. !
Traceback (most recent call last):
  File "/opt/odoo/custom/src/odoo/odoo/api.py", line 997, in get
    cache_value = field_cache[record._ids[0]]
KeyError: 8

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/opt/odoo/custom/src/odoo/odoo/fields.py", line 1161, in __get__
    value = env.cache.get(record, self)
  File "/opt/odoo/custom/src/odoo/odoo/api.py", line 1004, in get
    raise CacheMiss(record, field)
odoo.exceptions.CacheMiss: 'calendar.alarm(8,).alarm_type'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/opt/odoo/custom/src/odoo/odoo/fields.py", line 1187, in __get__
    recs._fetch_field(self)
  File "/opt/odoo/custom/src/odoo/odoo/models.py", line 3210, in _fetch_field
    self._read(fnames)
  File "/opt/odoo/custom/src/odoo/odoo/models.py", line 3220, in _read
    self.check_access_rights('read')
  File "/opt/odoo/custom/src/odoo/odoo/models.py", line 3480, in check_access_rights
    return self.env['ir.model.access'].check(self._name, operation, raise_exception)
  File "/opt/odoo/custom/src/odoo/odoo/addons/base/models/ir_model.py", line 1924, in check
    raise AccessError(msg)
odoo.exceptions.AccessError: No puede ingresar a los registros 'Event Alarm' (calendar.alarm)

Se permite esta operación para los grupos siguientes:
      - User types/Internal User

Póngase en contacto con su administrador para solicitar acceso si es necesario.

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/opt/odoo/auto/addons/google_calendar/models/res_users.py", line 100, in _sync_all_google_calendar
    user.with_user(user).sudo()._sync_google_calendar(google)
  File "/opt/odoo/auto/addons/google_calendar/models/res_users.py", line 79, in _sync_google_calendar
    synced_events = self.env['calendar.event'].with_context(write_dates=events_write_dates)._sync_google2odoo(events - recurrences, default_reminders=default_reminders)
  File "/opt/odoo/auto/addons/google_calendar/models/google_sync.py", line 185, in _sync_google2odoo
    cancelled_odoo._cancel()
  File "/opt/odoo/auto/addons/google_calendar/models/calendar.py", line 326, in _cancel
    super(Meeting, my_cancelled_records)._cancel()
  File "/opt/odoo/auto/addons/google_calendar/models/google_sync.py", line 152, in _cancel
    self.unlink()
  File "/opt/odoo/auto/addons/calendar/models/calendar_event.py", line 721, in unlink
    self.env['calendar.alarm_manager']._notify_next_alarm(partner_ids)
  File "/opt/odoo/auto/addons/calendar/models/calendar_alarm_manager.py", line 242, in _notify_next_alarm
    notif = self.with_user(user).with_context(allowed_company_ids=user.company_ids.ids).get_next_notif()
  File "/opt/odoo/auto/addons/calendar/models/calendar_alarm_manager.py", line 210, in get_next_notif
    last_found = self.do_check_alarm_for_one_date(in_date_format, meeting, max_delta, time_limit, 'notification', after=partner.calendar_last_notif_ack)
  File "/opt/odoo/auto/addons/calendar/models/calendar_alarm_manager.py", line 130, in do_check_alarm_for_one_date
    if alarm.alarm_type != alarm_type:
  File "/opt/odoo/custom/src/odoo/odoo/fields.py", line 1189, in __get__
    record._fetch_field(self)
  File "/opt/odoo/custom/src/odoo/odoo/models.py", line 3210, in _fetch_field
    self._read(fnames)
  File "/opt/odoo/custom/src/odoo/odoo/models.py", line 3220, in _read
    self.check_access_rights('read')
  File "/opt/odoo/custom/src/odoo/odoo/models.py", line 3480, in check_access_rights
    return self.env['ir.model.access'].check(self._name, operation, raise_exception)
  File "/opt/odoo/custom/src/odoo/odoo/addons/base/models/ir_model.py", line 1924, in check
    raise AccessError(msg)
odoo.exceptions.AccessError: No puede ingresar a los registros 'Event Alarm' (calendar.alarm)

Se permite esta operación para los grupos siguientes:
      - User types/Internal User

Póngase en contacto con su administrador para solicitar acceso si es necesario.
2024-12-11 10:19:05,547 31 INFO odoo odoo.addons.base.models.ir_cron: Job `Google Calendar: sincronización` done.
```

</details>

Desired behavior after PR is merged:
Google Sync works.



---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr


@moduon MT-8345
cc @arj-odoo

Forward-Port-Of: odoo/odoo#190708
Forward-Port-Of: odoo/odoo#190356

Steps:
- Install ai
- Open ai chat
- Try to send a message
- Traceback

The AI chat was failing on iOS with a traceback when trying to process
the stream response.

Even though MDN suggests compatibility, Safari (WebKit) versions prior
to 26.4 do not implement the AsyncIterator protocol on ReadableStream.
This makes `for await (const chunk of response.body)` throw a TypeError
as `[Symbol.asyncIterator]` is undefined.

https://developer.mozilla.org/en-US/docs/Web/API/ReadableStream

This commit replaces the async iteration with a manual reader loop
(`getReader().read()`). This is the low-level primitive supported by
all versions of Safari and ensures the stream is properly consumed and
unlocked even if the connection is interrupted.

Steps to reproduce:
1. Open Discuss/AI Chat on an iPad or iPhone (eg. 26.4).
2. Send a message.
3. The response triggers a JS error.

```js
Uncaught Promise > undefined is not a function (near '...chunk of asyncStream...')
```

opw-6054307

Forward-Port-Of: odoo/enterprise#113926

### Issue:
Some banks provide CODA files that do not strictly follow the specification, and increment the detail sequence on 3.2
https://febelfin.be/media/pages/publicaties/2023/febelfin-standaarden-voor-online-bankieren/5607daeda5-1754302976/standard-coda-2.7-en.pdf

Importing such files raises an error:
`Error R3004: CODA parsing error on information data record 3.2, seq 00020002! Please report this issue via your Odoo support channel.`

### Cause:
The parser compared the full `infoLine['ref']`, while only `infoLine['ref_move']` needs to remain consistent
https://github.com/odoo/enterprise/blob/a6efef92b86d95e05245c4ccf26324d37cc153e6/l10n_be_coda/models/account_journal.py#L683-L698

The `infoLine['ref_move_detail']` (3.2 sequence) change should not block import when incremented and should not trigger an error

### Steps to reproduce:
- Install `l10n_be_coda` and switch to the `BE company`
- Import a CODA file with incremented 3.2 detail sequence (e.g., files available in related tickets or test data)
Before the fix, the error is trigger

opw-6071761

Forward-Port-Of: odoo/enterprise#113904

### Issue before this commit:
The "Source" (origin) field was missing from the PDF of replacement invoices. While the original invoice correctly displayed the Sales Order reference, the new invoice generated through the request cancel process had an empty origin field.

### Steps to reproduce the issue:
1. Download Sales and l10n_mx
2. Set a UNSPSC Category for one product
3. Go to Sales, create a new Quotation and confirm it
4. Create invoice, confirm and send & print
5. Request cancel button -> create replacement invoice
6. In the new invoice there is no source origin invoice

### Cause of the issue:
The invoice_origin field is defined with copy=False. Since the replacement logic uses the copy_data method without explicitly passing the origin value, the field was automatically cleared during the creation of the new invoice.

### Reason to introduce the fix:
To ensure document traceability, the fix explicitly passes the invoice_origin from the original invoice to the replacement. This maintains the link to the Sales Order in the database and ensures the "Source" label appears on the printed PDF.

opw-6070016

Forward-Port-Of: odoo/enterprise#114099

Steps to reproduce Bug 1:
  1. Login as a user with "All Timesheets" (Approver) access.
  2. Disable the "Timesheet Assistant" feature for this user.
  3. Ensure "Billing Rate Indicators" is enabled in settings.

Steps to reproduce Bug 2:
  1. Login as a user with "All Timesheets" (Approver) access.
  2. Disable the "Billing Rate Indicators" setting in company settings.
  3. Ensure "Timesheet Assistant" is enabled in settings.
 
Steps to reproduce Bug 3:
 1. Only install 'sale_timesheet_enterprise'.
 2. Go to Timesheets > Configuration > Settings.
 3. Toggle "Billing Rate Indicators" (timesheet_show_rates) or change the encoding unit (timesheet_encode_uom_id), then save and check the menus.

Issue:
1. The "Configuration" menu is hidden, preventing access to billing targets even if the user has "All Timesheets" access.
2. The "Billing Time Targets" menu is still visible inside Configuration even if the "Billing Rate Indicators" feature is disabled in the settings.
3. Menu visibility does not update immediately after saving the settings. Menus that should appear (e.g., "Employee Billing Time Targets" or "Timesheets Assistant") remain hidden, or vice versa, until the cache is cleared or the server is restarted.

Cause:
1. The `hr_timesheet_enterprise_menu_configuration` was restricted in XML to groups that excluded "All Timesheets" users.
2. The `_load_menus_blacklist` logic in Python only blacklisted billing menus for users who were both Managers and System Admins, leaving them visible to regular Approvers even when the feature was disabled.
3. The load_menus method is decorated with @ormcache and stored in the Registry LRU cache. Menu visibility depends on timesheet_show_rates and timesheet_encode_uom_id through _load_menus_blacklist. When this field is updated, the ORM does not automatically invalidate the cached load_menus result because these specific fields are not part of the configuration fields. As a result, the stale old menu remains in memory.

Fix:
- Updated XML to include `hr_timesheet.group_hr_timesheet_approver` in the Enterprise Configuration menu permissions.
- Refactored `_load_menus_blacklist` to:
    - Hide all billing-related menus for all users when the feature is disabled.
    - Hide the parent Configuration menu if it would otherwise be empty.
- Override the write method in res.company in both modules and explicitly call env.registry.clear_cache() when the relevant configuration fields are modified.

task-5428010

Forward-Port-Of: odoo/enterprise#106464

### Issue before this commit:
The "Source" (origin) field was missing from the PDF of replacement invoices. While the original invoice correctly displayed the Sales Order reference, the new invoice generated through the request cancel process had an empty origin field.

### Steps to reproduce the issue:
1. Download Sales and l10n_mx
2. Set a UNSPSC Category for one product
3. Go to Sales, create a new Quotation and confirm it
4. Create invoice, confirm and send & print
5. Request cancel button -> create replacement invoice
6. In the new invoice there is no source origin invoice

### Cause of the issue:
The invoice_origin field is defined with copy=False. Since the replacement logic uses the copy_data method without explicitly passing the origin value, the field was automatically cleared during the creation of the new invoice.

### Reason to introduce the fix:
To ensure document traceability, the fix explicitly passes the invoice_origin from the original invoice to the replacement. This maintains the link to the Sales Order in the database and ensures the "Source" label appears on the printed PDF.

opw-6070016

Forward-Port-Of: odoo/enterprise#114099

**Steps to reproduce:**
* Install **Accounting** module.
* Open the `Partner Ledger report`.
* Type an entry/move name (e.g., 'INV/2024/00001') in the search bar.
* Export the report as `PDF` or `XLSX`.

**Observed behavior:**
* The exported file is empty or improperly generated.
* Filtering by partner name or viewing unfiltered works correctly.

**Cause:**
* When exporting `(export_mode == 'print')`,` _custom_options_initializer` adds a forced_domain to filter AMLs matching the search bar text.
* This domain only checks `partner_id.name` and reconciled partner names (matched_debit_ids/matched_credit_ids), but does NOT check `move_id.name` (the entry/journal entry name).
* As a result, when the search text is an entry name like 'INV/2024', no AML matches the partner-name-only domain, and the query returns no results — producing an empty export.

**Fix:**
* Add ('move_id.name', 'ilike', ...) as an additional OR branch in the forced domain, so AMLs whose journal entry name matches the search text are also included in the export.

opw-5972664

### Issue before this commit:
The "Source" (origin) field was missing from the PDF of replacement invoices. While the original invoice correctly displayed the Sales Order reference, the new invoice generated through the request cancel process had an empty origin field.

### Steps to reproduce the issue:
1. Download Sales and l10n_mx
2. Set a UNSPSC Category for one product
3. Go to Sales, create a new Quotation and confirm it
4. Create invoice, confirm and send & print
5. Request cancel button -> create replacement invoice
6. In the new invoice there is no source origin invoice

### Cause of the issue:
The invoice_origin field is defined with copy=False. Since the replacement logic uses the copy_data method without explicitly passing the origin value, the field was automatically cleared during the creation of the new invoice.

### Reason to introduce the fix:
To ensure document traceability, the fix explicitly passes the invoice_origin from the original invoice to the replacement. This maintains the link to the Sales Order in the database and ensures the "Source" label appears on the printed PDF.

opw-6070016

Forward-Port-Of: odoo/enterprise#114099

This PR replaces the legacy HTTP utility with a robust, production-ready HttpService class. The goal is to improve system reliability under high load and unstable network conditions.

Key Features:

Resilience: Implements Exponential Backoff + Jitter for retries. Respects Retry-After headers.

Strict Idempotency: Prevents dangerous retries on non-idempotent methods (POST/PATCH) to avoid data duplication.

Observability: Integrated Correlation IDs and detailed error objects (latency, attempt count) for better debugging.

Safety: Recursive parameter serialization with circular reference protection.

Resource Management: Abort-aware delays to prevent memory leaks during component unmounts.

Extensibility: Interceptor pipeline for request/response manipulation (e.g., Auth injection).

This refactor addresses previous limitations regarding error swallowing and lack of type safety in response parsing.

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