This module adds support for "codaclean" integration.
CODA files can be periodically (or on demand) fetched from codaclean
and imported into bank journals.
The module only connects to the IAP server.
The IAP side does the actual calls to codaclean (with a secret API key).

To use the module you have to create a connection to IAP / codaclean
and set up a bank journal:
- To manage the connection to IAP / codaclean go to
  Settings -> Accounting -> Codaclean -> Manage Connection
- To set up the bank journal you need to configure the following
  in the "Journal Entries" tab on the journal:
  - Put the IBAN in the "Bank Account Number" field
  - Select "Codaclean Synchronization" for the "Bank Feeds" field

Coda files will be automatically fetched 2 times per day via the
scheduled action called "Accounting: Sync Coda Files from Codaclean".
They can also be manually fetched by clicking "Fetch from Codaclean"
below the journal on the accounting dashboard (only available
when the journal and connection are setup correctly).

On an empty journal we start fetching from 1 year ago.
When the journal is not empty we start fetching after the last bank statement
/ bank statement line in the journal.

task-4844423

backport of commit 518ab9e

Forward-Port-Of: odoo/enterprise#95747

Issue:
When updating partner fields such as `email`, `name` and `phone` on the partner records,
the ticket fields are recomputed. During the recomputation, the `description` field is loaded into memory and with
many helpdesk tickets, this will cause a memory error.

Purpose of this PR:
To explicity fetch `partner_id` before computing partner fields on the helpdesk ticket.

Example:
With a partner record with 25,000 helpdesk tickets each with a description of varying text and images,
we hit the memory limit when trying to update the partner phone. With these changes, peak memory usage reached 271.4 MB.

Notes:
Originally wanted to avoid changing the field definition however this would require adding `with_context(prefetch_fields=False)`
to most of the compute methods on helpdesk ticket model.`with_context(prefetch_fields=False)` to most of the compute methods on helpdesk ticket model.

Memgraph and Stats before changes
<img width="1912" height="862" alt="memgraph_b4_changes" src="https://github.com/user-attachments/assets/f5e95a42-83c8-4250-bdf3-440740a9fb33" />
<img width="640" height="352" alt="stats_b4_changes" src="https://github.com/user-attachments/assets/a82ccd69-1359-4ba8-81a0-52aeace762db" />


opw-5069424

Versions
--------
- 17.0+

Steps
-----
1. Have a coupon program;
2. add a 10% discount on order reward for 1 point;
3. add a 50% discount on order reward for 5 points;
4. generate a coupon with 10 points;
5. use coupon code on a confirmed order;
6. select 10% discount reward;
7. change to a 50% discount reward;
8. check coupon point total.

Issue
-----
Even though the 5 point reward was used, only 4 out of 10 points remain.

Cause
-----
When updating the reward line of a confirmed order, it keeps track of point cost changes before & after a write. Its purpose is to restore back the point difference on the coupon record.

The issue is that while point changes are stored, coupon changes are not. When updating reward lines, `_reset_loyalty` is used, which removes the `coupon_id` from the lines. As a consequence, attempting to restore the point difference on `line.coupon_id` after an update, it writes to an empty record.

Solution
--------
Store both coupons & their used points before write. After write, restore the previous points to the previous coupon, and subtract the current point cost from the current coupon.

This way, any combination of coupon/point changes should have the points updated as expected.

opw-4910922

Forward-Port-Of: odoo/odoo#222054

## Issue 1: "Allow Extra Products" option ignored for packages

### Steps to reproduce:

- In the settings enable "Packages"
- Go to Inventory > Configuration > Warehouse Management > Operation Types
- Disable "Allow Extra Products" on the "Delivery" operation type
- Create two storable product P1, P2 and add on hand quantities
    - 10 x P1 in a package PACK01
    - 10 x P2 in a package PACK02
- Create and confirm a delivery for 10 unit of P1
- Open your delivery from the barcode app
- Scan PACK02
#### > The content of PACK02 is added to the delivery even thought it contains extra products.

### Cause of the issue:

The check for extra products is only applied when scanning individual products but is bypassed by package scan. To be more precise, the `barcode_allow_extra_product` option is checked in the public method `createNewLine`:
https://github.com/odoo/enterprise/blob/331442fd9cbd59d542432b2237299df9497ce241/stock_barcode/static/src/models/barcode_picking_model.js#L59-L80
While this method is called at new line creation when a product is scanned, scanning a package will add new lines during the  `_processPackage` adn bypasses the rest of the `_processBarcode`:
https://github.com/odoo/enterprise/blob/331442fd9cbd59d542432b2237299df9497ce241/stock_barcode/static/src/models/barcode_model.js#L1261-L1267
The issue being that the `__processPackage` does not check the  `barcode_allow_extra_product` option and creates its new lines via the  private `_createNewLine` call:
https://github.com/odoo/enterprise/blob/331442fd9cbd59d542432b2237299df9497ce241/stock_barcode/static/src/models/barcode_picking_model.js#L1564-L1565
https://github.com/odoo/enterprise/blob/331442fd9cbd59d542432b2237299df9497ce241/stock_barcode/static/src/models/barcode_picking_model.js#L1655-L1667
https://github.com/odoo/enterprise/blob/331442fd9cbd59d542432b2237299df9497ce241/stock_barcode/static/src/models/barcode_picking_model.js#L1671

### Fix:

Since scanning a package is expected to add all its content to the  picking, and since a package can not be split among two locations, it is necessary to check in advance if any product of its content is extra and avoid any update in this case.

## Issue 2: impossibility of package line removal

### State of the art:

There is currently no option to remove a package line from the barcode. In particular, once the option `show_entire_packs`(Move Entire Packages) is enabled on a picking type, you can not remove the package line once generated by a scan.

#### Steps to reproduce:

- In the settings enable "Packages"
- Go to Inventory > Configuration > Warehoue Management > Operation Types
- Enable "Move Entire Packages" on the "Delivery" operation type
- Create a storable product and add on hand quanties:
    - 10 units in package PACK01
    - 10 units in package PACK02
- Create and confirm a delivery for PACK01 (in the package lines)
- Open your delivery from the barcode app
- Scan PACK02
#### > The new line associated to PACK02 can not be removed by any mean

opw-4863621
opw-5080637

This is the backport of https://github.com/odoo/odoo/pull/225558/commits/2373808e9768afa5a1a56dbd1491ebd13da3f88a

Issue:
In the list view of Journal Items, cash basis lines show a `move_name` of '/' event if the move is posted and has a name.

Steps to reproduce:
- Activate Cash Basis in the accounting settings
- Create a tax with "Tax Exigibility" set "Based on Payment"
- Set the "Cash Basis Transition Account" to "Current Assets"
- Activate reconciliation on "Current Assets"
- Create an invoice with this tax, confirm
- In the dashboard, click on Bank and new
- Set the name of the invoice as the label, and the amount of the invoice as amount
- Save & Close
- Go in Accounting > Transactions > Journal Items
- The lines created for the cah basis entry display '/' in the column "Journal Entry"

Cause:
This issue is linked to the order in which things are done in `_set_next_sequence`: the fields triggered by the sequence field are added in `self.env.transaction.tocompute` then the sequence is computed and assigned.

When `_set_next_sequence()` is called from [`_create_tax_cash_basis_moves()`](https://github.com/odoo/odoo/blob/849e4a87178d8c8588b75e3f7d9073d6a78326f9/addons/account/models/account_partial_reconcile.py#L649-L654) this order is problematic as `account.move.line.move_name` will be computed and removed from `self.env.transaction.tocompute`. So it will not be updated when the sequence is assigned in `account.move.name`. The callstack is something like this:
- `_set_next_sequence()` calls `_locked_increment()` to compute the sequence
- `_locked_increment()` calls `flush_recordset()` which will call `_recompute_recordset()` to recompute all fields
- `_compute_invoice_date_due()` needs the field `needed_terms` triggering `_compute_needed_terms()`
- `_compute_needed_terms()` needs `invoice_line_ids`
- the fetch on `account.move.line` is ordered by `move_name`
- So `_compute_related()` is triggered for `move_name` and `account.move.line.move_name` is removed from `self.env.transaction.tocompute` Then `_locked_increment()` returns the sequence, it gets assigned as the move name and `move_name` is never updated because it's not in `self.env.transaction.tocompute`.

This doesn't occur in other flows (like calling `action_post()`) because the value of `needed_terms` is read from the cache.

Solution:
Swap the order in which things are done in `_set_next_sequence()`: first compute and assign the sequence and then add the triggered fields in `self.env.transaction.tocompute` so that they are computed afterwards.

It seems more logic that way: we change the `_sequence_field` then mark all fields that will be impacted in `tocompute`.

Enterprise PR - https://github.com/odoo/enterprise/pull/96721

opw-4747878

This is the backport of https://github.com/odoo/enterprise/pull/94111/commits/e379cf04cc1aa97d28d73566daadad193310ae9a

Issue:
In the list view of Journal Items, cash basis lines show a `move_name` of '/' event if the move is posted and has a name.

Steps to reproduce:
- Activate Cash Basis in the accounting settings
- Create a tax with "Tax Exigibility" set "Based on Payment"
- Set the "Cash Basis Transition Account" to "Current Assets"
- Activate reconciliation on "Current Assets"
- Create an invoice with this tax, confirm
- In the dashboard, click on Bank and new
- Set the name of the invoice as the label, and the amount of the invoice as amount
- Save & Close
- Go in Accounting > Transactions > Journal Items
- The lines created for the cah basis entry display '/' in the column "Journal Entry"

Cause:
This issue is linked to the order in which things are done in `_set_next_sequence`: the fields triggered by the sequence field are added in `self.env.transaction.tocompute` then the sequence is computed and assigned.

When `_set_next_sequence()` is called from [`_create_tax_cash_basis_moves()`](https://github.com/odoo/odoo/blob/849e4a87178d8c8588b75e3f7d9073d6a78326f9/addons/account/models/account_partial_reconcile.py#L649-L654) this order is problematic as `account.move.line.move_name` will be computed and removed from `self.env.transaction.tocompute`. So it will not be updated when the sequence is assigned in `account.move.name`. The callstack is something like this:
- `_set_next_sequence()` calls `_locked_increment()` to compute the sequence
- `_locked_increment()` calls `flush_recordset()` which will call `_recompute_recordset()` to recompute all fields
- `_compute_invoice_date_due()` needs the field `needed_terms` triggering `_compute_needed_terms()`
- `_compute_needed_terms()` needs `invoice_line_ids`
- the fetch on `account.move.line` is ordered by `move_name`
- So `_compute_related()` is triggered for `move_name` and `account.move.line.move_name` is removed from `self.env.transaction.tocompute` Then `_locked_increment()` returns the sequence, it gets assigned as the move name and `move_name` is never updated because it's not in `self.env.transaction.tocompute`.

This doesn't occur in other flows (like calling `action_post()`) because the value of `needed_terms` is read from the cache.

Solution:
Swap the order in which things are done in `_set_next_sequence()`: first compute and assign the sequence and then add the triggered fields in `self.env.transaction.tocompute` so that they are computed afterwards.

It seems more logic that way: we change the `_sequence_field` then mark all fields that will be impacted in `tocompute`.

Community PR - https://github.com/odoo/odoo/pull/230751

opw-4747878

**PROBLEM**
When hiding a HtmlField field from a view with pending images in it, there is a traceback.

**STEP TO REPRODUCE**
1. Using studio, create a HtmlField on the view of your choice.
2. Add a checkbox next to it, and link the HtmlField visibility to the button.
3. Add a image to the HtmlField (don't save the record !)
4. Hide the HtmlField using the checkbox, there should be a traceback. (if not, try with a bigger image).

**CAUSE**
commitChanges() will try to retrieve the field value to commit by looking at the related element in the DOM. Before retrieving this value, we call savePendingImages() to save the new images added to the HtmlField. https://github.com/odoo/odoo/blob/1416aad902a97ce56aaecc2aadc4dd9f7814ee53/addons/html_editor/static/src/fields/html_field.js#L159-L162 This introduces a delay, during which the DOM element could be destroyed.

**FIX**
We don't call commitChanges() in OnBlur(). Instead, we cache the new value in a property of HtmlField called `newValue` when `OnChanges()` is called. Inside OnBlur(), we save the pending images by directly calling `savePendingImages()` and we commit the new value by calling `updateValue(this.newValue)`

opw-5061820

Chrome iOS wraps some text nodes (like measures, email...) with a
`<chrome_annotation>` tag, which breaks OWL rendering.

This commit works around it by adding the (undocumented) `<meta
name="chrome" content="nointentdetection">` tag to disable this Chrome
behavior. The tag has to be set before the onDOMContentLoaded event to
be taken into account.

Note: Looks like this behavior was present in Chrome iOS 127 and
disabled afterward (because it already had issues) but it appeared again
in version 140-141.

References:
- https://issues.chromium.org/issues/353650041
- https://issues.chromium.org/issues/388718411
- https://stackoverflow.com/questions/78207646/how-do-i-disable-chrome-annotation-tags
- https://stackoverflow.com/questions/78575970/prevent-auto-detection-of-phone-numbers-in-chrome-mobile
- https://stackoverflow.com/questions/78725191/stop-chrome-ios-auto-detecting-numbers-followed-by-letter-m-as-metre-units-an
- https://github.com/solidjs/solid/issues/2235

opw-4969197

Forward-Port-Of: odoo/odoo#230081

Steps to reproduce:
1. Install Time Off (hr_holidays).
2. Go to Time Off → Configuration → Mandatory Days.
3. Create a mandatory day.
4. Open the user profile (top right corner) and change the language to Hebrew.
5. Open Time Off and view the calendar.

Issue:
The mandatory day marker is displayed on the incorrect date when the interface is in Hebrew.

Cause:
https://github.com/odoo/odoo/blob/ea9cd8357e148654458e3505963ae847d181776e/addons/hr_holidays/static/src/views/hooks.js#L18-L32
This is because the code was using 'info.el.dataset.date' directly which is based on the rendered DOM element and can be influenced by locale formatting, instead of the canonical ISO date, leading to incorrect selectors when trying to add the hr_mandatory_day CSS classes to the date.

solution:
Use the correct date value derived from info.date via Luxon’s toISODate() method Replaced info.el.dataset.date in the DOM selectors with the normalized ISO date to ensure that the correct element is targeted
regardless of the current language or locale.

opw-4979274

Forward-Port-Of: odoo/odoo#222338

Problem: When there is an obligation type code with id greater than 9, and it is selected in the dropdown of the website sale address form for obligation type, the screen keeps loading forever and there is an “expected singleton” traceback in the logs. This is because in the method `_parse_form_data` in `l10n_co_website_sale`, the obligation type field on `form_data` is set to be a  list of “type ids” which leads to an error when `convert_to_cache` is called as the browse function in this attempts to convert the list to a tuple of single characters. For example, if the list is ["10"], it gets converted to ("1","0") hence leading to the expected singleton traceback.

Purpose: Instead of passing a form list to form_data,we pass the record set which will correctly set the values in the address, much like how `default_obligations_ids` is also currently set. After this correction, the website address screen will save the address properly and redirect to the delivery screen for further actions.

Steps to Reproduce on Runbot:
1. Create a Colombian company, make sure l10n_co is installed
2. Set the company on the website to this company
3. Ensure that there is a record in the table `l10n_co_edi_obligation_type_ids` with id > 9. Create one if it does not exist.
4. Open the /shop page in incognito mode as a public user.
5. Add a product, go to the checkout page, proceed to the address page.
6. Enter all the information including the Identification Number (e.g. 623.456.789-1). Choose “NIT” in identification type and select the type code from step 3 in the dropdown for obligation type. Choose country “Colombia” along with a state and city 
7. Click on "Continue checkout". The page gets stuck in a loading state
 forever.

opw-4776301

**Issue**
The lunch order merge logic was causing orders to be unexpectedly archived when they shouldn't be. Users would see their orders disappear from the list view after certain operations like clicking "Receive" multiple times or when trying to merge orders with existing ones in immutable states.

**Steps to Reproduce**
1st problem
- Create a lunch order
- From the order list view, select the order and click the "Receive" button
- Select and click the "Receive" button again on the same order
- The order gets archived and disappears from the view

2nd problem
- Create a lunch order
- From the order list view, select the order and click the "Receive" button
- Place another order for the same product as before
- From the order list view, once the second order is set to received, it gets archived and the update quantity logic not triggered

**Root Cause and Solution**
1st problem: When searching for matching orders to merge, the current order being processed could match itself, leading to self-deactivation. Fixed by adding matching_lines = matching_lines - line to exclude the current record from potential merge targets.

2nd problem: The merge logic was trying to combine new orders with existing "sent" and "confirmed" orders, but the update_quantity method correctly excludes these states since they shouldn't be modified once sent/received. This created a mismatch where orders would be archived but quantities wouldn't update. Fixed by excluding "sent" and "confirmed" states from merge target searches entirely.

Task ID: 5123211

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

This bug is in France localization. In some cases employee schedule seems ignored in timesheet entry
(`account.analytic.line`) creation, and the duration field is created using the company schedule.
The reason is the case which the employee schedule starts before company scheudle or ends after it.

To reproduce the bug:
1- Make a db with fr company (install l10n_fr)
2- Make two working schedule:
- Company schedule with working day on Monday from 8:00-12:00 13:00-17:00
- Employee schedule with working day on Monday from 8:30-12:25 13:30-17:15

3- Assign company schedule to company in `Company Working Hours` in Setting and apply employee schedule to an employee from `Payroll` tab of employee
4- Allocate some time off to the employee and take a time off on Monday
5- Check the work entries for the day you took the day off on timesheet app
6- 7:24 `Worked Hour` is shown instead of 7:40

The bug occurs because in calling `adjust_date_range`, the case which employee's schedule ends after company schedule is not considered.

opw-4868643

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

Forward-Port-Of: odoo/odoo#222262

[FIX] account: set correct links between invoices and payments
The problematic found case was the following:
- Create an invoice and register a payment for it, using the wizard,
with a journal having an outstanding account set
- Use the smart button on the invoice form view to open the payment and
reset it back to draft
- Duplicate the payment, confirm the new one and reconcile it with the
invoice

=> If we go back to the invoice form, the smart button linking payments
is now redirecting to the 1st payment, that's in draft state, instead of
the second confirmed one.

This is because there can be 2 types of links between payments and
invoices:
- When there's no journal entry for payment, the link is done via the
Many2many table 'account_move__account_payment'.
- When there's a journal entry, the link is done via the table
'account.partial.reconcile'.

Before this commit, the button on the invoice form view was based on
account_move__account_payment and wasn't looking at all at
account.partial.reconcile as one would expect.

To solve that, we now look at reconciled_payment_ids that is computed
as the union of account_move__account_payment and
account.partial.reconcile.

Task-4613193
Runbot: https://runbot.odoo.com/runbot/bundle/18-0-outstanding-double-link-roto-354130

[FIX] account: set correct links between invoices and payments
The problematic found case was the following:
- Create an invoice and register a payment for it, using the wizard,
with a journal having an outstanding account set
- Use the smart button on the invoice form view to open the payment and
reset it back to draft
- Duplicate the payment, confirm the new one and reconcile it with the
invoice

=> If we go back to the invoice form, the smart button linking payments
is now redirecting to the 1st payment, that's in draft state, instead of
the second confirmed one.

This is because there can be 2 types of links between payments and
invoices:
- When there's no journal entry for payment, the link is done via the
Many2many table 'account_move__account_payment'.
- When there's a journal entry, the link is done via the table
'account.partial.reconcile'.

Before this commit, the button on the invoice form view was based on
account_move__account_payment and wasn't looking at all at
account.partial.reconcile as one would expect.

To solve that, we now look at reconciled_payment_ids that is computed
as the union of account_move__account_payment and
account.partial.reconcile.

Task-4613193
Runbot: https://runbot.odoo.com/runbot/bundle/18-0-outstanding-double-link-roto-354130