Steps to reproduce: - Switch the user language to arabic - Go to CRM - Insert the CRM lead pivot in spreadsheet => the values are in #ERROR The reason is that `toFormat` returns the date with arabic numbers, which can't be parsed by the spreadsheet engine. Similartly, we have to tell `.fromFormat` to parse the string using latn numbering system. Task: 4102957 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo

Steps to reproduce:
- Switch the user language to arabic
- Go to CRM
- Insert the CRM lead pivot in spreadsheet => the values are in #ERROR

The reason is that `toFormat` returns the date with arabic numbers,
which can't be parsed by the spreadsheet engine.

Similartly, we have to tell `.fromFormat` to parse the string
using latn numbering system.


Task: 4102957


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

Forward-Port-Of: odoo/odoo#176039

**Current behavior:** In a scenario where dropshipping and subcontracting are being used to fulfill an order, if the dropship is split via backorder then the valuation layers which get created for each subsequent backorder will have a cumulative value instead of reflecting the value for the sequence portion for which they were generated. **Expected behavior:** The SVL records should have a value which accurately reflects the moves involved in the portion of the valuation sequence that they

**Current behavior:**
In a scenario where dropshipping and subcontracting are being used to fulfill an order, if the dropship is split via backorder then the valuation layers which get created for each subsequent backorder will have a cumulative value instead of reflecting the value for the sequence portion for which they were generated.

**Expected behavior:**
The SVL records should have a value which accurately reflects the moves involved in the portion of the valuation sequence that they are being created with respect to.

**Steps to reproduce:**
1. Create a component_product such that: - is storable - category has automated valuation and avg cost method - has the `dropship subcontractor on order` route - has some vendor

2. Create a final_product such that: - is storable - category has automated valuation and avg cost method - invoice policy is on quantity delivered - has a subcontract bom that consumes some quantity of component_product - has a subcontractor vendor

3. Create a sale order for >1 of the final_product, set the route on order line to dropship, confirm the SO and the PO which is generated

4. In the dropship transfer, set the quantity to half the demand and validate -> generate the backorder

5. On the SO, create an invoice for the completed quantity and confirm it

6. Complete the rest of the order in the backordered dropship transfer and create and confirm another invoice on the SO

7. Go to the SVL tree view and observe that the latest SVL is ~2x (before the compensatory SVL difference is applied)

**Cause of the issue:**
When the SVL is created, its value is calculated by taking the difference of subcontract SVL(s) values and dropship SVL(s) values. The subcontract SVLs come from the `move_orig_ids` of the current SVL's move.

When the sequence is broken up by backorders, these moves are still used in the calculation for the value of future SVLs. This results in the inaccuracy.

**Fix:**
Only use SVLs from the move in the current move's
`move_orig_ids` which has the maximum `backorder_sequence`.

opw-4078510

Forward-Port-Of: odoo/odoo#176958
Forward-Port-Of: odoo/odoo#176163

[Test](https://runbot.odoo.com/runbot/build/66575239) was failing as website module is not dependency for test_assetsbundle, but we were trying to call website model. As a solution, test was moved from test_assetsbundle to website. The test was always failing, but we didn't catch it before as we were not testing said module. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#176007 Forward-Port-Of: odoo/odoo#175894

[Test](https://runbot.odoo.com/runbot/build/66575239) was failing as website module is not dependency for test_assetsbundle, but we were trying to call website model. As a solution, test was moved from test_assetsbundle to website.

The test was always failing, but we didn't catch it before as we were not testing said module.
 



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

Forward-Port-Of: odoo/odoo#176007
Forward-Port-Of: odoo/odoo#175894

before this commit: When the user removes the end date and then selects a new date, that date is update the start date. after this commit: When the user removes the end date and then selects a new date, that date should update the end date. Task-3899581 Forward-Port-Of: odoo/odoo#171215

before this commit:
When the user removes the end date and then selects a new date, that date is
update the start date.

after this commit:
When the user removes the end date and then selects a new date, that date should
update the end date.

Task-3899581

Forward-Port-Of: odoo/odoo#171215

Steps to reproduce: - Download french accouning localization module - Switch company to 'FR Company' - Invoicing > Customers > Invoice > New - Fill in a product - Confirm > Gear > Print > Invoice It's the typical column formatting error where columns are squeezed to the left and overlapping (See ticket for picture). opw-4089199 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#176209

Steps to reproduce:
- Download french accouning localization module
- Switch company to 'FR Company'
- Invoicing > Customers > Invoice > New
- Fill in a product
- Confirm > Gear > Print > Invoice

It's the typical column formatting error where columns are squeezed to the left and overlapping (See ticket for picture).

opw-4089199

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

Forward-Port-Of: odoo/odoo#176209

Description of the issue/feature this PR addresses: Passing a context as a dict rather than a key-value pair will drop the current context and only keep the explicitly passed dict. In some modules methods like `name_get` have been overridden to have a conditional behavior based on context. This, however, will never work if `_compute_translated_display_name` drops all the context before it gets to said method. This fix simply makes all the upstream context pass through. Current behavi

Description of the issue/feature this PR addresses:

Passing a context as a dict rather than a key-value pair will drop the current context and only keep the explicitly passed dict.

In some modules methods like `name_get` have been overridden to have a conditional behavior based on context. This, however, will never work if `_compute_translated_display_name` drops all the context before it gets to said method.

This fix simply makes all the upstream context pass through.

Current behavior before PR:

Calls to methods that have `_compute_translated_display_name` somewhere in the call stack will not see the context that they have been originally given.

Desired behavior after PR is merged:

All methods will see the context that they have been given at the call



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

Forward-Port-Of: odoo/odoo#170682
Forward-Port-Of: odoo/odoo#170050

Description of the issue/feature this PR addresses: This PR simply adds a hook to allow changing the parameters used by _select_seller during order line price computation. Current behavior before PR: Unable to inherit properly to change the selection of the seller, and have the correct price Desired behavior after PR is merged: Can change the parameter of _select_seller before price computation --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-p

Description of the issue/feature this PR addresses:
This PR simply adds a hook to allow changing the parameters used by _select_seller during order line price computation.

Current behavior before PR:
Unable to inherit properly to change the selection of the seller, and have the correct price

Desired behavior after PR is merged:
Can change the parameter of _select_seller before price computation


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

Forward-Port-Of: odoo/odoo#176943
Forward-Port-Of: odoo/odoo#170021

When adding a new field to a website form, the label width is copied from the first label inside the form. This fails if all fields have been deleted. One form where all fields can be deleted is the extra info step in eCommerce. This commit fixes this by using the default "200px" width (which is the default value inside the form templates) when there are no more field labels inside the form. Steps to reproduce: - Install eCommerce. - In Settings/Website, enable the extra info step. - G

When adding a new field to a website form, the label width is copied from the first label inside the form. This fails if all fields have been deleted.
One form where all fields can be deleted is the extra info step in eCommerce.

This commit fixes this by using the default "200px" width (which is the default value inside the form templates) when there are no more field labels inside the form.

Steps to reproduce:
- Install eCommerce.
- In Settings/Website, enable the extra info step.
- Go in shop, add a product to the cart and proceed until you reach the extra info step.
- Edit the extra info page.
- Remove all form fields.
- Add a field to the form.

=> An error dialog was displayed.

opw-4102127

Forward-Port-Of: odoo/odoo#176559

`Other income` and `Other income previous years` are obviously income accounts and not expense accounts. Forward-Port-Of: odoo/odoo#176629 Forward-Port-Of: odoo/odoo#175023

`Other income` and `Other income previous years` are obviously income accounts and not expense accounts.

Forward-Port-Of: odoo/odoo#176629
Forward-Port-Of: odoo/odoo#175023

Before this commit, accessing start and stop values directly from new event values could lead to a KeyError if these keys were missing. This commit adds a safeguard to prevent such errors by checking for the existence of these keys before attempting to access them, ensuring a more robust handling of event data. Here is traceback: ``` File "/home/odoo/src/odoo/addons/google_calendar/controllers/main.py", line 46, in google_calendar_sync_data need_refresh = request.env.user.sudo()._syn

Before this commit, accessing start and stop values directly from new event values could lead to a KeyError if these keys were missing. This commit adds a safeguard to prevent such errors by checking for the existence of these keys before attempting to access them, ensuring a more robust handling of event data.

Here is traceback:
```
  File "/home/odoo/src/odoo/addons/google_calendar/controllers/main.py", line 46, in google_calendar_sync_data
    need_refresh = request.env.user.sudo()._sync_google_calendar(GoogleCal)
  File "/home/odoo/src/odoo/addons/google_calendar/models/res_users.py", line 73, in _sync_google_calendar
    synced_recurrences = self.env['calendar.recurrence'].with_context(write_dates=recurrences_write_dates)._sync_google2odoo(recurrences)
  File "/home/odoo/src/odoo/addons/google_calendar/models/google_sync.py", line 197, in _sync_google2odoo
    odoo_record.with_context(context)._write_from_google(gevent, vals)
  File "/home/odoo/src/odoo/addons/google_calendar/models/calendar_recurrence_rule.py", line 122, in _write_from_google
    if old_event_values and any(new_event_values[key] != old_event_values[key] for key in base_event_time_fields):
  File "/home/odoo/src/odoo/addons/google_calendar/models/calendar_recurrence_rule.py", line 122, in <genexpr>
    if old_event_values and any(new_event_values[key] != old_event_values[key] for key in base_event_time_fields):
KeyError: 'start'
```

opw-4100958

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

Forward-Port-Of: odoo/odoo#176634

**Issue:** When several invoices are selected and sent via "Send & print" action, it happens that some invoices are sent several times. It seems to be caused by a serialization failure on an invoice in "_compute_debit_credit" when a concurrent write operation is executed on an invoice being sent. This serialization failure cause a retry on the batch being sent, resulting on the invoice to be re-sent. **Cause:** "Send & print" action triggers "_compute_debit_credit" method that writes

**Issue:**
When several invoices are selected and sent via "Send & print"
action, it happens that some invoices are sent several times.
It seems to be caused by a serialization failure on an invoice
in "_compute_debit_credit" when a concurrent write operation is
executed on an invoice being sent.
This serialization failure cause a retry on the batch being sent,
resulting on the invoice to be re-sent.

**Cause:**
"Send & print" action triggers "_compute_debit_credit" method that
writes on debit and credit fields.
The values are generally the same, so no write is really performed.
However, for some values (e.g. 14.79), there is a floating point
issue (i.e. 14.790000000000001) and the "get_records_different_from"
method considers the record as different and triggeres an actual
write.

**Solution:**
In "get_records_different_from" method, for monetary fields, apply
the same rounding to the current value than the one applied when the
value is converted to cache.

opw-3773287




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

Forward-Port-Of: odoo/odoo#176218

[FIX] website_sale_slides: scale down big num price Before this commit price had h2 class always. With this commit if price is longer than 10 digits we'll use smaller heading. [Reproduce] - Install website_sale_slides - Have a course: - "Enroll Policy": "On Payment" - It's related product's price has more than 10 digits - You not enrolled in it yet - Open course page -> UX BUG: price overflows opw-4075034 Forward-Port-Of: odoo/odoo#176754 Forward-Port-Of: odoo/odoo#175987

[FIX] website_sale_slides: scale down big num price

Before this commit price had h2 class always. With this commit
if price is longer than 10 digits we'll use smaller heading. 

[Reproduce]
- Install website_sale_slides
- Have a course:
	- "Enroll Policy": "On Payment"
	- It's related product's price has more than 10 digits
	- You not enrolled in it yet
- Open course page -> UX BUG: price overflows

opw-4075034

Forward-Port-Of: odoo/odoo#176754
Forward-Port-Of: odoo/odoo#175987

@amoyaux Following the conversation there : https://github.com/odoo/odoo/pull/75806#discussion_r1184797977 Thanks --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#120538

@amoyaux Following the conversation there : https://github.com/odoo/odoo/pull/75806#discussion_r1184797977

Thanks



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

Forward-Port-Of: odoo/odoo#120538

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

This update fixes the visual styling of appointment descriptions in the Odoo Appointments module. The styling issue has been corrected to ensure appointment details display properly for users booking appointments.

Commit fixes appointment description styling

task-3446959

This update corrects the Spanish translation for "Colony code" in the Mexican EDI module from "Código postal" (postal code) to "Código de colonia" (colony code). This ensures accurate terminology for Mexican users when processing electronic invoices, improving clarity and compliance with local standards.

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