Timesheet pages now use clearer, more human-readable web addresses. This makes links easier for users to understand, share, and recognize while keeping the same timesheet functionality.

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

Task-3820230

This update improves internal documentation for product configuration in Sales Renting and Sales Subscription. It helps development tools better understand the code, making future maintenance smoother without changing what users see.

This cleanup will allow IDEs to recognise parameter types.

Indian payroll settings now let companies store their EPF employer ID and ESIC IP number. This supports more complete Provident Fund-related company records for payroll compliance and administration.

In this PR, EPF employer ID and ESIC IP number fields were added, which are used by the company for Provident Fund.

Task - 4023367

The report editor now avoids a visual overlap between heading hints and displayed field expressions. This makes report editing clearer and reduces confusion when working with dynamic heading content.

Before this commit, when a h2 node has a t-out, there was a collision between the display of `.o-we-hint` and the display of the expression of the `t-out` in terms of styling.

This commit solves this by giving priority to the expression.

This fixes an automated test so it waits for all four serial numbers to finish processing before checking results. The change helps prevent false build failures and improves confidence in the stock barcode workflow validation.

In the tour `test_serial_product_packaging`, we didn't wait for the four serial numbers to be fully processed before checking the app state, which can cause race condition (only 3 serial numbers processed when doing the asserts.)

runbot build error: [75125](https://runbot.odoo.com/web#id=75125&view_type=form&model=runbot.build.error&menu_id=405&cids=1)

This update reorganizes the setup of internal enterprise messaging performance tests. It helps keep the test suite easier to maintain without changing how users experience the product.

Enterprise counter-part.

https://github.com/odoo/odoo/pull/177239

Barcode scanning and related tools were moved into a shared core area to remove an incorrect internal dependency. This keeps shared features easier to maintain and reduces the risk of future issues across apps that rely on barcode or view behavior.

This commit fixes a dependency issue by moving the barcode logic (dialog, scanner...) from webclient/ to core/. Indeed, Many2OneField uses it, but ideally, the views/ folder should not have dependencies to the webclient/ folder. That dependency showed that the barcode logic wasn't defined at the right place.

Part of task 3446824

The display for the Month 13 date filter was kind of ugly after the date filters refactoring. This makes it more useable and pretty to use. Forward-Port-Of: odoo/enterprise#66894

The display for the Month 13 date filter was kind of ugly after the date filters refactoring. This makes it more useable and pretty to use.

Forward-Port-Of: odoo/enterprise#66894

Whenever there is faulty data, it returns only one value, but it requires two. I have made a fix for that. Traceback group: 1415 ```py ('social.menu_social_post', 609, 'Social Marketing > Posts', 860): Traceback (most recent call last): File /tmp/tmpccnj1owi/migrations/base/tests/test_mock_crawl.py, line 256, in crawl_menu self.mock_action(action_vals) File /tmp/tmpccnj1owi/migrations/base/tests/test_mock_crawl.py, line 429, in mock_action mock_method(model, view, fiel

Whenever there is faulty data, it returns only one value, but it requires two. I have made a fix for that.

Traceback group: 1415

```py
('social.menu_social_post', 609, 'Social Marketing > Posts', 860):
 Traceback (most recent call last):
   File /tmp/tmpccnj1owi/migrations/base/tests/test_mock_crawl.py, line 256, in crawl_menu
    self.mock_action(action_vals)
   File /tmp/tmpccnj1owi/migrations/base/tests/test_mock_crawl.py, line 429, in mock_action
    mock_method(model, view, fields_list, domain, group_by)
   File /tmp/tmpccnj1owi/migrations/base/tests/test_mock_crawl.py, line 458, in mock_view_form
    [data] = record.read(fields_list)
   File /home/odoo/src/odoo/saas-17.4/odoo/models.py, line 3670, in read
    return self._read_format(fnames=fields, load=load)
   File /home/odoo/src/odoo/saas-17.4/odoo/models.py, line 3902, in _read_format
    vals[name] = convert(record[name], record, use_display_name)
   File /home/odoo/src/odoo/saas-17.4/odoo/models.py, line 6727, in __getitem__
    return self._fields[key].__get__(self)
   File /home/odoo/src/odoo/saas-17.4/odoo/fields.py, line 1263, in __get__
    self.compute_value(recs)
   File /home/odoo/src/odoo/saas-17.4/odoo/fields.py, line 1445, in compute_value
    records._compute_field_value(self)
   File /home/odoo/src/odoo/saas-17.4/addons/mail/models/mail_thread.py, line 428, in _compute_field_value
    return super()._compute_field_value(field)
   File /home/odoo/src/odoo/saas-17.4/odoo/models.py, line 5037, in _compute_field_value
    fields.determine(field.compute, self)
   File /home/odoo/src/odoo/saas-17.4/odoo/fields.py, line 101, in determine
    return needle(*args)
   File /home/odoo/src/enterprise/saas-17.4/social_instagram/models/social_post_template.py, line 36, in _compute_instagram_preview
    faulty_images, error_code = post._get_instagram_image_error()
 ValueError: too many values to unpack (expected 2)
```

Forward-Port-Of: odoo/enterprise#68232

A coding mistake was added in d53aae967c5b44b2ca1ed716e90e065fbbe938d4 Indeed, for resource bookings, we decrease asked capacity to allocate the full reserved capacity to available resources. However, it is decreased directly. This means that event values have a 0 asked_capacity, leading in turns to an inexact use of _get_default_appointment_attendee_status, used to determine whether the status should be 'accepted' or 'needsAction' depending on the manual treshold percentage if set, asked cap

A coding mistake was added in d53aae967c5b44b2ca1ed716e90e065fbbe938d4 Indeed, for resource bookings, we decrease asked capacity to allocate the full reserved capacity to available resources. However, it is decreased directly.

This means that event values have a 0 asked_capacity, leading in turns to an inexact use of _get_default_appointment_attendee_status, used to determine whether the status should be 'accepted' or 'needsAction' depending on the manual treshold percentage if set, asked capacity and existing bookings.

Indeed, the asked_capacity will not be counted when computing the total reserved percentage. In practice, this means that events crossing the treshold will be automatically 'accepted' instead of 'needsAction'

The fix creates another variable to avoid the issue and adds a test.

Task-4084727

Forward-Port-Of: odoo/enterprise#67626

Steps to reproduce: - Open Aged Receivable report - Press the Days Interval filter -> Traceback stating "TypeError: optionPath.split is not a function" The issue was introduced in the following commit, which reworked how filters are updated: https://github.com/odoo/enterprise/commit/10d61ca19ea850be7023043051c31f2b4bd3354c task-4122464 Forward-Port-Of: odoo/enterprise#68532

Steps to reproduce:
 - Open Aged Receivable report
 - Press the Days Interval filter -> Traceback stating "TypeError: optionPath.split is not a function"

The issue was introduced in the following commit, which reworked how filters are updated: https://github.com/odoo/enterprise/commit/10d61ca19ea850be7023043051c31f2b4bd3354c

task-4122464

Forward-Port-Of: odoo/enterprise#68532

### Steps to reproduce: - Create a storable product P tracked by SN - Create a consumable (or a storable with 5 units on hand) product COMP 1 and a storable product COMP 2 (without units on hand) - Create a BOM for P with an operation op 1 and two component lines: - 1 x COMP 1 consumed in op 1 - 1 x COMP 2 consumed in op 1 - Create and confirm an MO for 5 units of P - Go to the shopfloor and click on register production. **> the qty is updated to 1 on COMP 2 but to 5/1 on

### Steps to reproduce:

- Create a storable product P tracked by SN
- Create a consumable (or a storable with 5 units on hand) product
  COMP 1 and a storable product COMP 2 (without units on hand)
- Create a BOM for P with an operation op 1 and two component lines:
    - 1 x COMP 1 consumed in op 1
    - 1 x COMP 2 consumed in op 1
- Create and confirm an MO for 5 units of P
- Go to the shopfloor and click on register production.

**> the qty is updated to 1 on COMP 2 but to 5/1 on COMP 1**

As such, if you click on the 5/1, 5 units of COMP 1 will be consumed to produce only one unit of P

### Cause of the issue:

When you confirm the MO, since Comp 1 is a consumable its quantity is automatically set to 5.0 because reservation are bypassed. On the other hand, since Comp 2 is a storable without on hand qty, its quantity stays at 0.0. When you click on register production, or on the plus sign will trigger a call of the "_set_qty_producing" method. This call will update the qty_producing of the final product:
https://github.com/odoo/odoo/blob/f86c68ec8340a59407ea9c51dd0ba942f9b4429c/addons/mrp/models/mrp_production.py#L1214-L1218
However, the update of the qty consumed by the raw move will be bypassed because of these lines:
https://github.com/odoo/odoo/blob/f86c68ec8340a59407ea9c51dd0ba942f9b4429c/addons/mrp/models/mrp_production.py#L1225-L1226
https://github.com/odoo/enterprise/blob/0646022d7726a0cc183b191ca5be4e4bb4368f93/mrp_workorder/models/stock_move.py#L10-L13
And the quantity will therefore not be updated by these lines:
https://github.com/odoo/odoo/blob/f86c68ec8340a59407ea9c51dd0ba942f9b4429c/addons/mrp/models/mrp_production.py#L1228-L1231
However, as the quantity is not set to 0, it will be displayed as "quantity/should_consume_qty" and clicking on the raw move line will not update the quantity so 5 units will be marked as consumed ("picked").

Community: https://github.com/odoo/odoo/pull/168205

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

Forward-Port-Of: odoo/enterprise#68189
Forward-Port-Of: odoo/enterprise#63912

Before this commit, when scaning a GS1 barcode containing a packaging for a tracked product and a lot, it doesn't work. This commit fixes two issues: 1. Get back packaging data (product and quantity) when a GS1 barcode is scanned; 2. Be able to find the lot/serial number when a GS1 barcode with no product but a packaging is scanned. Forward-Port-Of: odoo/enterprise#68315 Forward-Port-Of: odoo/enterprise#67727

Before this commit, when scaning a GS1 barcode containing a packaging for a tracked product and a lot, it doesn't work.

This commit fixes two issues:
1. Get back packaging data (product and quantity) when a GS1 barcode is scanned;
2. Be able to find the lot/serial number when a GS1 barcode with no product but a packaging is scanned.

Forward-Port-Of: odoo/enterprise#68315
Forward-Port-Of: odoo/enterprise#67727

Problem: The quality_score field is not received in the response while syncing all the templates. As a result, the default 'none' quality will be applied to all the templates. And the same goes while syncing a single template. It will only be updated when Meta posts a request on the webhook to update the template quality. Solution: The quality_score field can only be received if we explicitly ask for the quality_score field in an API request, But the problem is that only the quality_sco

Problem:

The quality_score field is not received in the response while syncing all the templates. As a result, the default 'none' quality will be applied to all the templates. And the same goes while syncing a single template. It will only be updated when Meta posts a request on the webhook to update the template quality.

Solution:

The quality_score field can only be received if we explicitly ask for the quality_score field in an API request, But the problem is that only the quality_score field will be received here. Due to this, the API request to sync a single template and multiple templates are modified, and all the basic fields like name, components, language, status, category, and ID are included along with the quality_score field so we receive all basic fields and quality_score field.

Task-3908894

Forward-Port-Of: odoo/enterprise#67764
Forward-Port-Of: odoo/enterprise#61150

We replace some calls to runAllTimers by calls to advanceTime in order to not to have to remove components/services from mail (see https://github.com/odoo/enterprise/pull/68143 for more info). Forward-Port-Of: odoo/enterprise#68540

We replace some calls to runAllTimers by calls to advanceTime in order to not to have to remove components/services from mail (see https://github.com/odoo/enterprise/pull/68143 for more info).

Forward-Port-Of: odoo/enterprise#68540