This update fixes an internal test for Belgian tax reporting that was failing after stricter multi-company checks were introduced. It helps keep the Belgian reporting module reliable in environments where multiple companies are configured.

The test started failing because of a multi-company consistency check introduced in https://github.com/odoo/odoo/pull/197494

Community PR: https://github.com/odoo/odoo/pull/197494

This change updates an automated checkout test to match the current button wording in the Colombian e-invoicing website sales flow. It helps keep quality checks reliable without changing the customer-facing shopping experience.

The French profit and loss report has been corrected so accounts 638000 and 669000 are included in the appropriate report lines. This helps businesses using French accounting get more complete and accurate profit and loss reporting without manual adjustments.

screencast : https://drive.google.com/file/d/1O-03Mcd58KUbCAUqX7QLN48y2_6V5kQZ/view?usp=sharing

What are the steps to reproduce the issue?
Go to runbot 18.0 or master, install directly l10n_fr_reports

What is the current behavior you observe?
There are two account number that no request by the P&L

![image](https://github.com/user-attachments/assets/08bf8838-2c2f-4d3c-9c68-0134a27324a3)

What would you like the behavior/result to be?
I thinks that
638000 account would be in item "Taxes and duties" of french report P&L
669000 account would be in item "Interest and similar charges" of french report P&L

![2025-02-07_06h54_20](https://github.com/user-attachments/assets/5b2892b9-be78-401e-ae63-197b99b56a25)
![2025-02-07_06h59_23](https://github.com/user-attachments/assets/423afff4-91c6-45de-9b96-1e7d8880d3e4)

ticket : https://www.odoo.com/fr_FR/my/tasks/4557675

This update fixes an internal test for Belgian reporting so it works correctly with stricter multi-company checks. It helps keep reporting quality controls reliable without changing day-to-day user behavior.

The test started failing because of a multi-company consistency check introduced in https://github.com/odoo/odoo/pull/197494

Community PR: https://github.com/odoo/odoo/pull/197494

Add more info to the AR EDI XML file: new required tag CondicionIVAReceptorId where we inform the AFIP responsibility code of the partner. LATAM Task 1300 - ADHOC Task 47476 Forward-Port-Of: odoo/enterprise#78934

Add more info to the AR EDI XML file: new required tag CondicionIVAReceptorId where we inform the AFIP responsibility code of the partner.

LATAM Task 1300 - ADHOC Task 47476

Forward-Port-Of: odoo/enterprise#78934

The idea is: 1. Stop to do a lot of thing in the getter `relevantRecords` because all those operations are done every time this getter is called. To achieve that, relevant records are computed each time before the component should be re-rendered and the getter only returns the computed result. It was making the code very hard to work with and very unstable. 2. Move `MrpDisplaySearchModel` `recordCache.ids` into `MrpDisplay` `recordCacheIds`. Why ? Because this array is always used in `MrpD

The idea is:

1. Stop to do a lot of thing in the getter `relevantRecords` because all those operations are done every time this getter is called. To achieve that, relevant records are computed each time before the component should be re-rendered and the getter only returns the computed result. It was making the code very hard to work with and very unstable.

2. Move `MrpDisplaySearchModel` `recordCache.ids` into `MrpDisplay` `recordCacheIds`. Why ? Because this array is always used in `MrpDisplay` so it doesn't do a lot of sense to define it in `MrpDisplaySearchModel`. The only exception is in the `_notify` where the cache is invalidated (TODO: to check if it still relevant.) Also, instead of havin an object with one uniq key who refers to an array (`recordCache.ids`), it will now be an array directly.

3. Make `recordCacheIds` part of the `MrpDisplay` `state`. The purpose of this change is to refresh the app everytime the cache is modified.

Also, this commit fix an issue where the record cache wasn't correctly updated when the selected employee requieres a PIN code. The issue was the cache was invalided before the PIN code was validated, a lot of async methods weren't awaited and the dialog itself wasn't bound to a callback in a way to be able to invalidate cache at the right moment.

OPW-4256568

Forward-Port-Of: odoo/enterprise#78874
Forward-Port-Of: odoo/enterprise#74421

Barcode lookup is not working when activating `restrict_scan_product` Steps: - Go to 'Receipts' operations type - On the barcode tab, activate `restrict_scan_product` - Go to barcode app, receipts operation and scan a new product (eg 510002952387) -> Error: "Not the expected scan - You must scan a product" We should be able to create a new product. With this commit we make an extra check on the guilty condition in the stock_barcode_barcodelookup module opw-4429769 Forward-Port-Of: odoo/en

Barcode lookup is not working when activating `restrict_scan_product`

Steps:

- Go to 'Receipts' operations type
- On the barcode tab, activate `restrict_scan_product`
- Go to barcode app, receipts operation and scan a new product
  (eg 510002952387)
-> Error: "Not the expected scan - You must scan a product"
We should be able to create a new product.

With this commit we make an extra check on the guilty condition
in the stock_barcode_barcodelookup module

opw-4429769

Forward-Port-Of: odoo/enterprise#79276
Forward-Port-Of: odoo/enterprise#76652

Resetting a move to draft should detach the current attachments generated by the send and print and allow regenerating them after the user is done with the edits. task-4498564 Community PR: https://github.com/odoo/odoo/pull/195626 Forward-Port-Of: odoo/enterprise#78429

Resetting a move to draft should detach the current attachments generated by the send and print and allow regenerating them after the user is done with the edits.

task-4498564

Community PR: https://github.com/odoo/odoo/pull/195626

Forward-Port-Of: odoo/enterprise#78429

The project report query joins multiple tables and aggregates on some fields, everything else should be in the group by clause. The group by here is using the select alias but it is better to use the full column name including the table alias, in case one of the joined tables has a column with the same name as the alias. Forward-Port-Of: odoo/enterprise#79272

The project report query joins multiple tables and aggregates on some fields, everything else should be in the group by clause. The group by here is using the select alias but it is better to use the full column name including the table alias, in case one of the joined tables has a column with the same name as the alias.

Forward-Port-Of: odoo/enterprise#79272

1. Insert a graph view into the spreadsheet. 2. Click the "Share" button to generate a shareable link. 3. Open the link in an incognito window. 4. A blank screen appears, with errors logged in the console. The condition for detecting live data in the spreadsheet was incorrect, causing shared links to break. This PR updates the condition to correctly check for the presence of Odoo charts. Task: 4551470 Forward-Port-Of: odoo/enterprise#79290 Forward-Port-Of: odoo/enterprise#79151

1. Insert a graph view into the spreadsheet.
2. Click the "Share" button to generate a shareable link.
3. Open the link in an incognito window.
4. A blank screen appears, with errors logged in the console.

The condition for detecting live data in the spreadsheet was incorrect, causing shared links to break.

This PR updates the condition to correctly check for the presence of Odoo charts.

Task: 4551470

Forward-Port-Of: odoo/enterprise#79290
Forward-Port-Of: odoo/enterprise#79151

Status indicator was designed independently from the calendar indicator. Overriding its behavior leads to the situation where we show appointment status instead of the calendar indicator. This commit attempts to keep the changes minimal so we are hiding the status indicator for non-appointment events from the appointment template. Reproduce --- - Install appointment. - Schedule a meeting in the calendar. - Open the "Decline" link from the received confirmation email (as public_user)

Status indicator was designed independently from the calendar indicator.
Overriding its behavior leads to the situation where we show appointment
status instead of the calendar indicator.

This commit attempts to keep the changes minimal so we are hiding
the status indicator for non-appointment events from the appointment template.

Reproduce
---
- Install appointment.
- Schedule a meeting in the calendar.
- Open the "Decline" link from the received confirmation email (as public_user).
- BUG: See "Appointment Reserved!" even tho we clicked "Decline"

Note: The bug doesn't occur when the appointment is not installed.

opw-[4295448](https://www.odoo.com/web#id=4295448&view_type=form&model=project.task)

Forward-Port-Of: odoo/enterprise#76365

## Versions: 17.0+ ## Issue: Translation of the English "Balance" word is displayed as "Balanza" in all Spanish files but should be "Balance" as well. "Balanza" meaning "Scale", the translation is sometimes right. opw-4461450 Forward-Port-Of: odoo/enterprise#78116

## Versions:
17.0+

## Issue:
Translation of the English "Balance" word is displayed as "Balanza" in all Spanish files but should be "Balance" as well. "Balanza" meaning "Scale", the translation is sometimes right.

opw-4461450

Forward-Port-Of: odoo/enterprise#78116

The transfer tip messages displayed at the top in the Barcode app were constructed with `<b>` markup in the OWL template. However, the translation extraction mechanism for OWL templates splits the template up per tag it encounters. So if you had a message like `Scan a <b>transfer</b>, a <b>product</b> ...`, it would extract the `, a` part separately. Moreover, if the final string didn't contain more than 1 alphanumerical character, it wouldn't be exported in the .pot file and thus not be tran

The transfer tip messages displayed at the top in the Barcode app were constructed with `<b>` markup in the OWL template. However, the translation extraction mechanism for OWL templates splits the template up per tag it encounters. So if you had a message like `Scan a <b>transfer</b>, a <b>product</b> ...`, it would extract the `, a` part separately.

Moreover, if the final string didn't contain more than 1 alphanumerical character, it wouldn't be exported in the .pot file and thus not be translatable.

Also, having these messages chopped up doesn't allow translators to change word order in other languages.

In this commit we safely construct the messages in Javascript and have them translated as one full sentence. After this, we show them in the OWL template.

[task-4421055](https://www.odoo.com/odoo/project.task/4421055)

Related to https://github.com/odoo/odoo/pull/196805

Forward-Port-Of: odoo/enterprise#79078
Forward-Port-Of: odoo/enterprise#78717

Turns out it's used. To minimize the UI space, setting an activity type and user should be enough to "activate" the feature, no need to check a box. Note: removing the creation of activity at upload, this flow is supposed to work on alias upload (setting unavailable without alias defined). Task-4551761 Note: Only the last commit is really part of this PR Forward-Port-Of: odoo/enterprise#79213 Forward-Port-Of: odoo/enterprise#78681

Turns out it's used.

To minimize the UI space, setting an activity type and user
should be enough to "activate" the feature, no need to check a 
box.

Note: removing the creation of activity at upload, this flow
is supposed to work on alias upload (setting unavailable 
without alias defined).
 
Task-4551761

Note: Only the last commit is really part of this PR

Forward-Port-Of: odoo/enterprise#79213
Forward-Port-Of: odoo/enterprise#78681

This commit fixes an asset issue with web_gantt where the dark mode specific assets from web_gantt were included in the main (light mode) assets from pos_restaurant_appointment. Part of task-4571228 Forward-Port-Of: odoo/enterprise#79265

This commit fixes an asset issue with web_gantt where the dark mode specific assets from web_gantt were included in the main (light mode) assets from pos_restaurant_appointment.

Part of task-4571228

Forward-Port-Of: odoo/enterprise#79265

### Steps to reproduce: - Go to Accounting > Reporting > Tax return - Select a period in the past - Click on "Closing Entries" - Post - The period on the generated PDF is wrong ### Cause: This [commit](https://github.com/odoo/enterprise/commit/22878ec7e38c2a9fbf871beb239d01a42a17546a) changes `options['date']['filter']` to replace `tax_period` by the period (`'month', 'quarter', 'year'`). This causes `custom_tax_period` to be replaced by `custom_month` for example. Then in `_init_opt

### Steps to reproduce:
- Go to Accounting > Reporting > Tax return
- Select a period in the past
- Click on "Closing Entries"
- Post
- The period on the generated PDF is wrong

### Cause:
This [commit](https://github.com/odoo/enterprise/commit/22878ec7e38c2a9fbf871beb239d01a42a17546a) changes `options['date']['filter']` to replace `tax_period` by the period (`'month', 'quarter', 'year'`). This causes `custom_tax_period` to be replaced by `custom_month` for example.

Then in `_init_options_date` which computes the date for the report `options['date']['filter']` is checked:
- If any of these strings: `'month', 'quarter', 'year'` are in the filter name then it computes the period with today's date
- If `tax_period` and `custom` is in the filter name then it keeps the correct date

So since this commit, `_init_options_date` always return today's date with `custom_tax_period` as filter.

### Solution:
The value `custom_tax_period` wasn't expected by the commit introducing the issue and values like `custom_month` doesn't make sense. So this commit checks if `custom` is in the filter before replacing `tax_period`.

opw-4543231

Forward-Port-Of: odoo/enterprise#79011

See commit messages. Task-4510838 Forward-Port-Of: odoo/enterprise#79049 Forward-Port-Of: odoo/enterprise#77783

See commit messages.

Task-4510838

Forward-Port-Of: odoo/enterprise#79049
Forward-Port-Of: odoo/enterprise#77783

Forward-Port-Of: odoo/enterprise#79208

Forward-Port-Of: odoo/enterprise#79208

Before this commit, the context of the action was just ignored in the grid view and so the default values stored inside that context are not taken into account during `grid_update_cell` method. Steps to reproduce the issue ---------------------------- 0. Install timesheet_grid module 1. Open Employees app 2. Click on an employee to open the form view 3. Click on the timesheets smart button to view the timesheet grid view for that employee 4. Navigate to a week that already contains hour

Before this commit, the context of the action was just ignored in the grid view and so the default values stored inside that context are not taken into account during `grid_update_cell` method.

Steps to reproduce the issue
----------------------------
0. Install timesheet_grid module
1. Open Employees app
2. Click on an employee to open the form view
3. Click on the timesheets smart button to view the timesheet grid view for that employee
4. Navigate to a week that already contains hours for the current user
5. Update the grid cell containing a timesheet to reduce the number of hours for instance
6. Update another cell without any timesheets linked and set a hour

Current Behavior
----------------
After refreshing the page and going to the same week, the changes made in step 5 and 6 are no longer applied. The reason is because those changes have generated new timesheets for the current user instead of the employee displayed in the form view before doing the step 3.

Expected behavior
-----------------
The grid view should be unchanged after refreshing the page, the changes made in 5 and 6 should be applied without any issues.

opw-4491850

Forward-Port-Of: odoo/enterprise#79076

Purpose ======= Fix some UI issues in the appointment type kanban view. Specification ============= - The ribbon is now wrapped around a div which is messing up the kanban display. Applying some style to make it position absolute and avoid a strange spacing. - Keep UI consistency by resizing the empty avatar card for resources to match the one used for users. - On mobile view, align the appointment title with its details. Task-4518542 Forward-Port-Of: odoo/enterprise#77884

Purpose
=======
Fix some UI issues in the appointment type kanban view.

Specification
=============
- The ribbon is now wrapped around a div which is messing up the kanban display. Applying some style to make it position absolute and avoid a strange spacing.
- Keep UI consistency by resizing the empty avatar card for resources to match the one used for users.
- On mobile view, align the appointment title with its details.

Task-4518542

Forward-Port-Of: odoo/enterprise#77884