The barcode testing tools were modernized to make automated checks clearer and easier to maintain. Test failures now stop immediately, reducing noisy follow-up errors and helping teams identify issues faster.

- switch to individual exports, named functions, and namespaced import
- make `fail` fail immediately, otherwise the tour continues running until the python kills everything, which generates a bunch of additional and unhelpful errors[^1]
- fix up a few jsdocs

[^1]: https://runbot.odoo.com/runbot/build/67090511

URLs used in WhatsApp-related flows and supporting website/studio test scenarios were updated to a cleaner, more human-readable format. This improves clarity for users and aligns automated checks with the newer link style without changing core business behavior.

*= test_web_studio, test_website_sale_full,
whatsapp

This commit modifies existing URLs to the new format 
so that the URL's become more human readable.

Task-3820230

This update prepares manufacturing planning to distinguish products that share the same variant but have different non-variant options, such as pizza toppings or supplements. It supports more accurate stock, purchase, and manufacturing flows, though the user-facing display of these options will be handled separately.

As for now, it was not possible to differentiate products variants
with different attributes that did not create a variant.

Let's take a pizza as an example. The product template is a pizza,
with an attribute "type" with "margherita, veggie, bbq"
which create variants.

We also have another attribute "supplements" with values
"extra cheese" and "extra peperoni" that do not create variants.

As for now, it was not possible to differentiate stock moves with the same
pizza variant but with different values for the 'no_variants' attributes
(i.e. no difference between two pizza of same type with different supplements).

The same applies to purchases, but also to manufacturing orders.

The community pr addresses the technical part and thus the never attribute values
are not displayed on the different views, and this pr only updates some function signatures.
Another commit/PR will take care of making it accessible for the user

task-id: 4017183
community: https://github.com/odoo/odoo/pull/171727

When a field service project is moved to another company, its worksheet template now updates automatically to the appropriate template for that company. This helps keep project paperwork aligned with the correct company settings and reduces manual adjustments.

- Update worksheet template based on company change on project form: if moving to Company another company, switch to the template with the lowest sequence with that company.

task-3689394

This update changes automated tests to use Odoo's own time-freezing helper instead of an external decorator. It improves test cleanup and reduces the risk of unreliable test results, with no expected impact on end users.

As using freezegun.freeze_time decorator on test classes is discouraged, a custom freeze_time object can be used as a replacement that properly manage the cleanup.

With this commit, the problematic usages are replaced by the custom object.

Steps to reproduce 1. Go to the users, click on Marc Demo 2. apply empty groups for documents 3. Create an activity from the chatter of a document 4. Assign it to Marc Demo for instance 5. As Marc Demo, click on the "view document" button in the notification email 6. The user will arrive on AppSwitcher Technical Reason: With commit https://github.com/odoo/enterprise/commit/8e13e68d8a6dcff3da61c60b108e4583860cfcbe, the user clicks on the link will redirect them to the document preview u

Steps to reproduce
1. Go to the users, click on Marc Demo
2. apply empty groups for documents
3. Create an activity from the chatter of a document
4. Assign it to Marc Demo for instance
5. As Marc Demo, click on the "view document" button in the notification email
6. The user will arrive on AppSwitcher

Technical Reason:
With commit https://github.com/odoo/enterprise/commit/8e13e68d8a6dcff3da61c60b108e4583860cfcbe, the user clicks on the link will redirect them to the document preview using 'ir.actions.act_url'. This later appears on the AppSwitcher because the user does not have access to the document group.

After this Commit:
Users who have no document groups will access the form view of the document via the link.

Task-4052827

Forward-Port-Of: odoo/enterprise#66966

**Before this PR:** The style of some knowledge templates was broken when attempting to export or print, lacking proper formatting as per the templated structure. It seemed like there was an issue with the template's responsiveness. **After this PR:** Now, the issue has been addressed, and now the template is appropriately formatted and styled, ensuring correctness during export. **Task**-3664950 Forward-Port-Of: odoo/enterprise#56221

**Before this PR:**
The style of some knowledge templates was broken when attempting to export or print, lacking proper formatting as per the templated structure. It seemed like there was an issue with the template's responsiveness.
 
**After this PR:**
Now, the issue has been addressed, and now the template is appropriately formatted and styled, ensuring correctness during export.

**Task**-3664950

Forward-Port-Of: odoo/enterprise#56221

Step to reproduce: - Activate analytic accounting in the Accounting settings - Create an analytic account - Create an invoice with this new analytic account - Create a horizontal group, for example on the product_id field. - Enable the Profit and Loss report on the horizontal group - Open the P&L report and activate both the analytical and the horizontal groupby filters. => no result is displayed in the column of the analytical filter. Cause of the issue: When activating the an

Step to reproduce:
 - Activate analytic accounting in the Accounting settings
 - Create an analytic account
 - Create an invoice with this new analytic account
 - Create a horizontal group, for example on the product_id field.
 - Enable the Profit and Loss report on the horizontal group
 - Open the P&L report and activate both the analytical and the horizontal groupby filters. => no result is displayed in the column of the analytical filter.

 Cause of the issue:
 When activating the analytic groupby, it creates a shadowing of
 the move lines based on the analytic lines. This shadowing loses
 most of the data of the move lines, which can therefore no
 longer be of use to create more advanced filters.

 Proposed solution:
 When doing the shadowing, if the account.analytic.line does not
 have the column present in the account.move.line, then takes the
 value of the related move line, instead of setting the value
 to NULL as it was done before.

 opw-4048157

Forward-Port-Of: odoo/enterprise#67364
Forward-Port-Of: odoo/enterprise#66980

Before this commit, users could encounter an access error when attempting to connect to Google Calendar. If a user was removed from an appointment but an existing calendar event still belonged to that user, all attendees of that event would be unable to sync their calendar with Google, resulting in an access error. The error message displayed was: Sorry, Marc Demo (id=6) doesn't have 'read' access to: - Appointment Type, Test Demo (appointment.type: 3). opw-4109304 Forward-Port-Of: odoo/

Before this commit, users could encounter an access error when attempting to connect to Google Calendar. If a user was removed from an appointment but an existing calendar event still belonged to that user, all attendees of that event would be unable to sync their calendar with Google, resulting in an access error. The error message displayed was:

Sorry, Marc Demo (id=6) doesn't have 'read' access to:
- Appointment Type, Test Demo (appointment.type: 3).

opw-4109304

Forward-Port-Of: odoo/enterprise#68673

Steps to reproduce: - open consolidation - Select one of the consolidation - Smart button > Consolidated balance - Change the unit currency and put e.g. `In K€` Issue: Keyerror Cause: When opening the consolidated balance, the line does not take into account all the keys ghenerally present in other reports https://github.com/odoo/enterprise/blob/saas-17.2/account_consolidation/report/builder/abstract.py#L272-L278 Solution: Using get to be more defensive. No change is made in the

Steps to reproduce:
- open consolidation
- Select one of the consolidation
- Smart button > Consolidated balance
- Change the unit currency and put e.g. `In K€`

Issue:
Keyerror

Cause:
When opening the consolidated balance, the line does not take into account all the keys ghenerally present in other reports
https://github.com/odoo/enterprise/blob/saas-17.2/account_consolidation/report/builder/abstract.py#L272-L278

Solution:
Using get to be more defensive. No change is made in the consolidation module as it will be deperecated in 18.0.

opw-4089130

Forward-Port-Of: odoo/enterprise#68436

As per section 34(2) of CGST Act 2017, credit notes for invoices from the financial year cannot be included in GSTR after November 30th. With this PR, if a credit note is created after November 30th of the financial year, an alert will be displayed to remind users to exclude the tax, as it cannot be included in GSTR. POT file also added for `l10n_in_gstr_reports` **task**-3915664 Forward-Port-Of: odoo/enterprise#68702 Forward-Port-Of: odoo/enterprise#66713

As per section 34(2) of CGST Act 2017, credit notes for invoices from the financial year cannot be included in GSTR after November 30th.

With this PR, if a credit note is created after November 30th of the financial year, an alert will be displayed to remind users to exclude the tax, as it cannot be included in GSTR.

POT file also added for `l10n_in_gstr_reports`

**task**-3915664

Forward-Port-Of: odoo/enterprise#68702
Forward-Port-Of: odoo/enterprise#66713

Purpose of this PR: CoA Report trial balance test adjusted to accommodate for the new account, 173.01 Deferred expenses Community PR that adds new account: #176681 opw-4105993 Forward-Port-Of: odoo/enterprise#68578

Purpose of this PR:
CoA Report trial balance test adjusted to accommodate for the new account, 173.01 Deferred expenses

Community PR that adds new account: #176681

opw-4105993

Forward-Port-Of: odoo/enterprise#68578

before this commit: Service type `FEDEX_INTERNATIONAL_CONNECT_PLUS` was not available the list 'fedex_service_type'. After this commit: Missing service type is added in the list. reference fedex doc: https://developer.fedex.com/api/en-us/guides/api-reference.html#servicetypes opw-4061797 Forward-Port-Of: odoo/enterprise#64250

before this commit:

Service type `FEDEX_INTERNATIONAL_CONNECT_PLUS` was not available the list 'fedex_service_type'.

After this commit:

Missing service type is added in the list.

reference fedex doc: https://developer.fedex.com/api/en-us/guides/api-reference.html#servicetypes

opw-4061797

Forward-Port-Of: odoo/enterprise#64250

We need to comply with DIAN validations for Credit/Debit notes that do not reference an invoice, by sending "Invoice Period". For now, send the invoice period start date and end date as invoice date for Credit/Debit notes without reference to the invoice. task-3926204 Forward-Port-Of: odoo/enterprise#68364

We need to comply with DIAN validations for Credit/Debit notes that do not reference an invoice, by sending "Invoice Period". For now, send the invoice period start date and end date as invoice date for Credit/Debit notes without reference to the invoice.

task-3926204

Forward-Port-Of: odoo/enterprise#68364

"Colony code" translation changed from: "Código postal" => "Código de colonia" Forward-Port-Of: odoo/enterprise#68600 Forward-Port-Of: odoo/enterprise#68566

"Colony code" translation changed from:
"Código postal" => "Código de colonia"

Forward-Port-Of: odoo/enterprise#68600
Forward-Port-Of: odoo/enterprise#68566

**Current behavior:** There are several related bugs when operating in a multi-company environment with the barcode app: *Given:* we have three companies in the selector (A, B, C) where company A is the first/default/primary of the three. ***Case 1: (CompanyB and CompanyC are checked, either can be focused)*** 1) Scanning the barcode for CompanyC's manufacturing operation and then, within the barcode view, scanning a product which belongs exclusively to CompanyB will make it impossib

**Current behavior:**
There are several related bugs when operating in a multi-company
environment with the barcode app:

*Given:* we have three companies in the selector (A, B, C) where
company A is the first/default/primary of the three.

***Case 1: (CompanyB and CompanyC are checked, either can be focused)***
1) Scanning the barcode for CompanyC's manufacturing operation and
then, within the barcode view, scanning a product which belongs
exclusively to CompanyB will make it impossible to use the back
button (despite the product correctly not being added as a line
in the operation).

2) Repeating the setup with a different operation type (e.g.,
receipt) *will* add the product to the picking but it will not
be possible to validate/take out of draft from either the
barcode app nor from the backend.


***Case 2: (only CompanyC checked and focused)***
1) Scanning the barcode for CompanyC's manufacturing operation type
will open the barcode operation view for CompanyA's manufacture
operation. Products available to CompanyC can be added. Trying
to validate the order will cause an access error, however the MO
is still created in the backend.

2) Scanning the barcode for either CompanyB or CompanyA's
non-manufacturing operations will show an access error dialog,
but an (empty) transfer will still be created in the backend for
the respective company.

---

**Expected behavior:**
In case 1, scanning a product which is not available to the
current company should not trap the user in the barcode
operation view. It should also not add these inaccessible
products to a picking thereby making them unable to be
validated.

In case 2, we should respect the company defined on a
manufacturing operation type which corresponds to a scanned
barcode. Additionally, it should not be possible to create empty
transfers for companies which are not currently checked/active.

---

**Cause of the issue:**
Problem 1: production records (unlike pickings) cannot be
created until a product is added in the barcode view. Because of
this different flow, they are created with less context than
other operation types and there was no mechanism by which their
`company_id` could be inferred.

This caused them to use the default value as defined in the
`MrpProduction` model (`self.env.company`)- which is problematic
in the barcode app, as this field does not actually correspond
to the focused/active company.

Problem 2: when scanning a picking type from the main menu of
the barcode app, the company of the picking type was not getting
respected which would cause a new picking record to be created
even when the current user/environment did not have permission.

---

**Fix:**
1. Create production records using a default `company_id` value
informed by their `picking_type_id` rather than the environment

2. In the main_menu barcode scan route, use the current user's
allowed company ids (from their cookies) to restrict searchable
records

3. When scanning products in a barcode operation view, use the
company_id of the opened operation type to restrict the domain
of searchable records.

opw-3999622

Forward-Port-Of: odoo/enterprise#67902
Forward-Port-Of: odoo/enterprise#65433

This commit fixes a small bug in the SQL. It removes an unused join with company_id to avoid adding unnecessary lines. Additionally, it uses fields_id instead of ir_prop.name and adds fallback options for ir_prop. If the res_id is not found in the database, the ir_prop without a res_id or company_id will be used. To test it, simply open the production analysis, create a BOM, and verify that the expected fields are correctly populated. Forward-Port-Of: odoo/enterprise#67819

This commit fixes a small bug in the SQL. It removes an unused join with company_id to avoid adding unnecessary lines. Additionally, it uses fields_id instead of ir_prop.name and adds fallback options for ir_prop. If the res_id is not found in the database, the ir_prop without a res_id or company_id will be used.

To test it, simply open the production analysis, create a BOM, and verify that the expected fields are correctly populated.

Forward-Port-Of: odoo/enterprise#67819

Customers redirected from email have the access_token of invoice while subscription is expecting order access_token so it can not be paid for, and redirection on json url causes infinite loading and frozen screen. Steps to reproduce the issue: 1. Create a new subscription and confirm it 2. Create the invoice and confirm it 3. Send the invoice by email so the customer pay it 4. Select the payment method CARD by Stripe. 5. Select the option "Automate payments for this subscription" (

Customers redirected from email have the access_token of invoice
while subscription is expecting order access_token
so it can not be paid for, and redirection on json url
causes infinite loading and frozen screen.

Steps to reproduce the issue:

1. Create a new subscription and confirm it
2. Create the invoice and confirm it
3. Send the invoice by email so the customer pay it
4. Select the payment method CARD by Stripe.
5. Select the option "Automate payments for this subscription"
(Automatically the option save my payment details will be selected)

How this commits fixes the issue:

Replace invoice access_token by the subscription access_token.

opw-4080536

Forward-Port-Of: odoo/enterprise#67777

### Steps to reproduce the issue: 1. Create a Batch of Payments 2. Create a Bank Statement Line and reconcile it with one of the Payments in the Batch 3. Go on any other Bank Statement Line and go to the Batch section 4. The amount shown on the line of the batch did not change ### Explanation: If a Batch is partially reconciled with Bank Statement Lines, `_compute_from_payment_ids_`, which would recalculate `amount_residual`, is not called. ### Fix reasoning: `is_matched` updat

### Steps to reproduce the issue:

1. Create a Batch of Payments
2. Create a Bank Statement Line and reconcile it with one of the Payments in the Batch
3. Go on any other Bank Statement Line and go to the Batch section
4. The amount shown on the line of the batch did not change

### Explanation:

If a Batch is partially reconciled with Bank Statement Lines, `_compute_from_payment_ids_`, which would recalculate `amount_residual`, is not called.

### Fix reasoning:

`is_matched` updates on every reconciliation between a Bank Statement Line and a Payment. Adding it to the dependencies of `_compute_from_payment_ids` will make reconciliations trigger the method.

opw-4062387

Forward-Port-Of: odoo/enterprise#68547
Forward-Port-Of: odoo/enterprise#67519

Versions: ------------ 17.0 Steps to reproduce: ------------------------- 1. Send a sign request with 2 signers, setting a reminder to be sent every day. 2. Two emails will be sent to different signers. 3. Change the local date to 2 days ahead. 4. Run the "Send: Sign Reminder" cron. - Two more emails will be received, and one signer will complete their sign request. 5. Change the dates again and run the cron job. - One email will be sent to the remaining signer. 6. From the

Versions:
------------
17.0

Steps to reproduce:
-------------------------
1. Send a sign request with 2 signers, setting a reminder to be sent every day.
2. Two emails will be sent to different signers.
3. Change the local date to 2 days ahead.
4. Run the "Send: Sign Reminder" cron.
    - Two more emails will be received, and one signer will complete their sign request.
5. Change the dates again and run the cron job.
    - One email will be sent to the remaining signer.
6. From the old sign request email, copy the link and try to resend it.
    - The user should not be able to resend the new link.

Issue:
-------
Resending the link does not check the state of the sign request and items, allowing multiple sends.

Solution:
-----------
Resending the link is only possible if the request and items are not already completed, canceled, or refused.

task: 4002440

Forward-Port-Of: odoo/enterprise#68481
Forward-Port-Of: odoo/enterprise#65853

Steps to reproduce the bug: - Create a storable product “P1” with BoM: - Component: C1 - Create a quality point: - Product: P1 - Operation: Manufacturing - Control per: Quantity - Control Frequency: All - Create a manufacturing order: - Product: P1 - Quantity: 20 - Confirm the MO - Set the qty producing 12 - click on the quality check: - Button Fail - Quantity: 5 - Valide the Mo and create a backorder - click on the quality check:

Steps to reproduce the bug:
- Create a storable product “P1” with BoM:
    - Component: C1

- Create a quality point:
    - Product: P1
    - Operation: Manufacturing
    - Control per: Quantity
    - Control Frequency: All

- Create a manufacturing order:
    - Product: P1
    - Quantity: 20

- Confirm the MO
- Set the qty producing 12
- click on the quality check:
    - Button Fail
    - Quantity: 5

- Valide the Mo and create a backorder
- click on the quality check:
    - Button Fail
    - Quantity: 1

Problem:
A traceback is triggered:
```
  File "/home/odoo/odoo V16/enterprise/quality_control/models/quality.py", line 370, in _move_line_to_failure_location
    if not check._can_move_line_to_failure_location():
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/odoo/odoo V16/enterprise/quality_mrp/models/quality.py", line 49, in _can_move_line_to_failure_location
    self.move_line_id = self.production_id.finished_move_line_ids.filtered(
    ^^^^^^^^^^^^^^^^^
  File "/home/odoo/odoo V16/odoo/odoo/fields.py", line 1321, in __set__
    write_value = self.convert_to_write(value, records)
                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/odoo/odoo V16/odoo/odoo/fields.py", line 3118, in convert_to_write
    return value.id
           ^^^^^^^^
  File "/home/odoo/odoo V16/odoo/odoo/fields.py", line 5154, in __get__
    raise ValueError("Expected singleton: %s" % record)
ValueError: Expected singleton: stock.move.line(96, 98)
```

When we validate the MO to create the backorder, the `_split_productions`
function is called. This results in two move lines:
https://github.com/odoo/odoo/blob/4be8cac644c9471f98bf16e82825af0e9439e697/addons/mrp/models/mrp_production.py#L1837
The first one has a quantity of 15, which is the remaining quantity
to be processed, and the second line has a quantity of 5, which is the
quantity that has definitely failed. However, these two move lines are
supposed to be ordered first by the failed ones and then by the others.
Because, in the current situation, we take the move line with the
quantity of 15, reduce it by the 12 units processed in this MO,
leaving 3. As a result, we will have two remaining move lines:
3 + 5 (already failed), and both will be used in the backorder.
But if they were ordered by the failed ones first, we would subtract
12 from 5, resulting in -7, and then reduce the line with 15 - 7 = 8
in the move line that will be used in the backorder."
https://github.com/odoo/odoo/blob/4be8cac644c9471f98bf16e82825af0e9439e697/addons/mrp/models/mrp_production.py#L1848-L1858

opw-4064656

Forward-Port-Of: odoo/enterprise#68580
Forward-Port-Of: odoo/enterprise#67474