When removing the date_scope normal in 6e607e662dd2, we missed an occurrence of it in the Aged Receivable report. As a result, auditing the Aged Receivable is currently broken:  Solution: since this domain is on Accounts Receivable / Accounts Payable, which are Balance Sheet accounts, the `normal` date_scope is equivalent to `from_beginning` in this case. taskid: 3177283 Forward-Port-

When removing the date_scope normal in 6e607e662dd2, we missed an occurrence of it in the Aged Receivable report. 

As a result, auditing the Aged Receivable is currently broken:
![image](https://github.com/odoo/enterprise/assets/74787742/73e0e03c-f00c-4d8a-8bc7-8528ea70b307)



Solution: since this domain is on Accounts Receivable / Accounts Payable, which are Balance Sheet accounts, the `normal` date_scope is equivalent to `from_beginning` in this case.

taskid: 3177283

Forward-Port-Of: odoo/enterprise#64270

We recently renamed `o-sidePanelButton` to `o-button` in the library but did not change it inside Odoo. Forward-Port-Of: odoo/enterprise#64199 Forward-Port-Of: odoo/enterprise#51744

We recently renamed `o-sidePanelButton` to `o-button` in the library but did not change it inside Odoo.

Forward-Port-Of: odoo/enterprise#64199
Forward-Port-Of: odoo/enterprise#51744

Forward-Port-Of: odoo/enterprise#63968

Forward-Port-Of: odoo/enterprise#63968

Before this commit, when we canceled a sign request, a traceback would occurs: ``` UncaughtPromiseError > TypeError Uncaught Promise > Cannot read properties of undefined (reading 'doAction') TypeError: Cannot read properties of undefined (reading 'doAction') ``` Even if goBackToKanban is correctly binded, controlPanelProps was not calling it properly. taskid: 3932003 Forward-Port-Of: odoo/enterprise#62772

Before this commit, when we canceled a sign request, a traceback would occurs:

```
UncaughtPromiseError > TypeError
Uncaught Promise > Cannot read properties of undefined (reading 'doAction')
TypeError: Cannot read properties of undefined (reading 'doAction')
```

Even if goBackToKanban is correctly binded, controlPanelProps was not calling it properly.

taskid: 3932003

Forward-Port-Of: odoo/enterprise#62772

Document fields in the salary configurator now check for existing files on the current contract. Fields are set to required only if no associated file is detected on the contract, otherwise we just show the already existed file. Task-3468245 Forward-Port-Of: odoo/enterprise#55641

Document fields in the salary configurator now check for existing files on the current contract. Fields are set to required only if no associated file is detected on the contract, otherwise we just show the already existed file.

Task-3468245

Forward-Port-Of: odoo/enterprise#55641

Increase window size for previously active employees Forward-Port-Of: odoo/enterprise#63995

Increase window size for previously active employees

Forward-Port-Of: odoo/enterprise#63995

Versions -------- - 17.0+ Steps ----- 1. Go to an employee w/ a running contract; 2. open their working schedule; 3. change lunch breaks from the default 12:00 to 12:30; 4. go to the Payroll app; 5. check the work entries of the employee. Issue ----- Each work entry has two rows: 1. first half of working day, pill takes up the entire column; 2. second half of working day, pill takes up half a column. Cause ----- Commit 19c957264ed reworked how gantt pills get rounded, maki

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

Steps
-----
1. Go to an employee w/ a running contract;
2. open their working schedule;
3. change lunch breaks from the default 12:00 to 12:30;
4. go to the Payroll app;
5. check the work entries of the employee.

Issue
-----
Each work entry has two rows:
1. first half of working day, pill takes up the entire column;
2. second half of working day, pill takes up half a column.

Cause
-----
Commit 19c957264ed reworked how gantt pills get rounded, making it so that a if a record extends on a day/half-day/hour/month for even a minute, the pill includes it.

Because the half-day is hardcoded to 12:00, this means that a lunch break that's one minute later than that will display the first shift as a full day in work entry gantt view.

Solution
--------
Partially re-introduce the old pill rounding logic for this specific view/module. Add it to the hr_gantt module so the same visual issue gets resolved in hr_attendance_gantt views.

opw-3895160

Forward-Port-Of: odoo/enterprise#63768
Forward-Port-Of: odoo/enterprise#62390

Currently, when a user has 2 pos preparation displays, one set on some categories the other on all, if you add on the order a product that is not in the categories of the first display, the order will show no changes. Steps to reproduce: ------------------- * Go to the **Kitchen display** App * Have two displays created * Display 1: `Product Categories`: Food * Display 2: `Product Categories`: All (Leave blank) * Go to the **Point of Sale** App * Open restaurant session * Select a

Currently, when a user has 2 pos preparation displays, one set on some categories the other on all, if you add on the order a product that is not in the categories of the first display, the order will show no changes.

Steps to reproduce:
-------------------
* Go to the **Kitchen display** App
* Have two displays created
  * Display 1: `Product Categories`: Food
  * Display 2: `Product Categories`: All (Leave blank)
* Go to the **Point of Sale** App
* Open restaurant session
* Select a table and add a drink to the order
> Observations: The order button is not highlighted.

Why the fix:
------------
Before the refactoring, the categories loaded for each display would use the function `_get_pos_category_ids()`. This function would return a list of all possible categories (ex: `[1, 2, 3, 4, 5]`) when the setting was set on all categories.

After the refactoring, the categories loaded correspond to the setting of the display. Thus, in the case of a display on all categories it would return `[]`.

At the end, we would end up concatenating stuff like `([5], [])` instead of `([5], [1, 2, 3, 4, 5])`. Only displays with categories set would be taken into account.

opw-3923383

Forward-Port-Of: odoo/enterprise#63315

In the reports, the groups called '(No Group)' fold and unfold together. ### Steps to reproduce: - in Accounting app go in Configuration > Account Groups and create an account group for the current company - Go in Reporting > Profit and Loss - All '(No Group)' lines fold and unfold together ### Cause: Line ids are duplicate for (No Group) lines: '\~account.group\~'. The hierarchy is ignored for these ids, there is no reference to the parent line. ### Solution: Integrate the parent

In the reports, the groups called '(No Group)' fold and unfold together.

### Steps to reproduce:
- in Accounting app go in Configuration > Account Groups and create an account group for the current company
- Go in Reporting > Profit and Loss
- All '(No Group)' lines fold and unfold together

### Cause:
Line ids are duplicate for (No Group) lines: '\~account.group\~'. The hierarchy is ignored for these ids, there is no reference to the parent line.

### Solution:
Integrate the parent line in the ids to take the hierarchy into consideration.

### opw-3885400

Forward-Port-Of: odoo/enterprise#63804
Forward-Port-Of: odoo/enterprise#62647

**Version:** - master **Steps to reproduce:**: - open 'subscription: payment reminder' template - click on preview **Issue:** - preview payment reminder template it is giving error because it is not getting payment link for 'pay now' button. **Solution:** - added a fallback value for 'pay now' button if it not get payment link value. task-3956795 Forward-Port-Of: odoo/enterprise#63444

**Version:**
- master

**Steps to reproduce:**:
- open 'subscription: payment reminder' template
- click on preview

**Issue:**
- preview payment reminder template it is giving error because it is not getting payment link for 'pay now' button.

**Solution:**
- added a fallback value for 'pay now' button if it not get payment link value.


task-3956795

Forward-Port-Of: odoo/enterprise#63444

With this commit whenever utm.source name is written it will check its uniquness (generating a unique name if necessary). [Reproduce] - Install marketing_automation - Have Campaign with a Template: - Access the Campaign's Template and go to the Settings tab. - Note down the NAME of the `utm.source` (found in the Advanced section, under the field "Name"). - Delete this template (which will also delete associated `mailing.mailing` records.) - Create new template (by returning to the Campaign

With this commit whenever utm.source name is written it will check its uniquness (generating a unique name if necessary).

[Reproduce]
- Install marketing_automation
- Have Campaign with a Template: - Access the Campaign's Template and go to the Settings tab. - Note down the NAME of the `utm.source` (found in the Advanced section, under the field "Name"). - Delete this template (which will also delete associated `mailing.mailing` records.)
- Create new template (by returning to the Campaign form, opening an activity, creating template)
- Open the Campaign's Template: - Disable read-only on the Name field in Advanced section (modify the `mailing.mailing.form` view). - Change its name to the previously noted `utm.source` NAME. - Save -> BUG: Trackback "The name must be unique"

[Why this bug happens?]
When you delete a template (`mailing.mailing`) related to a `utm.source`, the `utm.source` will still exist. Then, when attempting to change the `utm.source` name, the system is supposed to detect if the name already exists and generate a new unique name if necessary. However, due to the mechanism utilized in the function (ref.1), which searches for existing names based on existing templates (`mailing.mailing`), which you have deleted, the existing `utm.source` NAME won't be found. Consequently, the function mistakenly believes the name is unique and doesn't generate a new name, leading to the encountered error.

(ref.1) `UtmMixin._get_unique_names`
https://github.com/odoo/odoo/blob/205caa3d6539187009a8b8bbd1557e75fe045ff3/addons/utm/models/utm_mixin.py#L77

opw-3835704

Forward-Port-Of: odoo/enterprise#64240
Forward-Port-Of: odoo/enterprise#63360

For Greece, the ISO 3166 code (GR) and European Union code (EL) is not the same. Since this is a european report, we need the European Union code. opw-3890635 Forward-Port-Of: odoo/enterprise#64151 Forward-Port-Of: odoo/enterprise#64087

For Greece, the ISO 3166 code (GR) and European Union code (EL) is not the same. Since this is a european report, we need the European Union code.

opw-3890635

Forward-Port-Of: odoo/enterprise#64151
Forward-Port-Of: odoo/enterprise#64087

Following odoo/odoo@0bc65a8, the empty domain [] is normalized as True, which means that used with expression.OR, as it is the case in appointment portal, it will accept all records, leading to a useless search. Instead, append appropriate domains and use OR on the whole list, before using AND on the default domain, to restrict records to the search, as expected. Task-3976616 Forward-Port-Of: odoo/enterprise#64028

Following odoo/odoo@0bc65a8, the empty domain [] is normalized as True, which means that used with expression.OR, as it is the case in appointment portal, it will accept all records, leading to a useless search.

Instead, append appropriate domains and use OR on the whole list, before using AND on the default domain, to restrict records to the search, as expected.

Task-3976616

Forward-Port-Of: odoo/enterprise#64028

User using the filters in the bank reco widget want to be able to save them for next time. In the implementation of the search view of the kanban, we only added the filter. This commit will add the favorite section. task-3871505 Forward-Port-Of: odoo/enterprise#60860

User using the filters in the bank reco widget want to be able to save them for next time. In the implementation of the search view of the kanban, we only added the filter. This commit will add the favorite section.

task-3871505

Forward-Port-Of: odoo/enterprise#60860

In a multi-company environment, the Analytic Plans "Departments" and "Internal" are optional but have no analytic account. Because analytic account had a default on the env company. We want the analytic account to be available for every company. task-3970078 communtiy: https://github.com/odoo/odoo/pull/167995 Forward-Port-Of: odoo/enterprise#63898

In a multi-company environment, the Analytic Plans "Departments" and "Internal" are optional but have no analytic account. Because analytic account had a default on the env company. We want the analytic account to be available for every company.

task-3970078

communtiy: https://github.com/odoo/odoo/pull/167995

Forward-Port-Of: odoo/enterprise#63898

Purpose ------- Let's say a user works a lot on a spreadsheet and performs a lot of heavy operations generating very large revisions (with lots of commands), such as copy-pasting a very large zone (there's one UPDATE_CELL command per copy-pas cell) If the user does multiple such very large revision, one after the other, every thing is fine client side. The next time the spreadsheet is open though: the server needs to load all those revisions to send them to the client. The revisions ca

Purpose
-------

Let's say a user works a lot on a spreadsheet and performs a lot of heavy operations generating very large revisions (with lots of commands), such as copy-pasting a very large zone (there's one UPDATE_CELL command per copy-pas cell)

If the user does multiple such very large revision, one after the other, every thing is fine client side.

The next time the spreadsheet is open though: the server needs to load all those revisions to send them to the client. The revisions can be so large it can blow up the server memory limit.
The spreadsheet cannot be open anymore.

Solution
--------

In this commit, we increase the number of snapshot by snapshotting more often.

Previously, we used to snapshot when opening a spreadsheet and no activity was done in the spreadsheet in the last 12 hours. It's reduced to 2 hours in this commit.
The reason we don't want to snapshot too often is that it kills the local history (CTRL+Z) of connected users.

Task: 3940465

Forward-Port-Of: odoo/enterprise#63741

Fix the share availabilities button elevation happening on lower screen sizes. related PR: odoo/enterprise#51755 Task-3975976 Forward-Port-Of: odoo/enterprise#63990

Fix the share availabilities button elevation happening on lower screen sizes.

related PR: odoo/enterprise#51755

Task-3975976

Forward-Port-Of: odoo/enterprise#63990

Currently, a traceback with `KeyError: 'emisor'` occurs when attempting to update payments after creating and signing a PPD and external trade invoice, and registering a payment. opw-3904458 Forward-Port-Of: odoo/enterprise#62976

Currently, a traceback with `KeyError: 'emisor'` occurs when attempting to update payments after creating and signing a PPD and external trade invoice, and registering a payment.

opw-3904458

Forward-Port-Of: odoo/enterprise#62976