Mirror of the following PR for WorldlineDriver_W: https://github.com/odoo/enterprise/pull/53951

Apart from the changes same as in the mentionned PR desribed below this PR also improves the WorldlineDriver_W.
It adds some very much needed logging and smart sleep mechanics already present in the WorldlineDriver_L.
It also adds a unique buffer size for all the variables used by C++ code (also already on WorldlineDriver_W).
Finally it adds some comments to the C++ variables mapping to easily identify them (you guessed it, also on WorldlineDriver_W already).

The description below matches the https://github.com/odoo/enterprise/pull/53951
Currently, if you have 2 browser tabs or 2 different PoS using the same Worldline terminal, there was a way to do some damage if requests were started at the same time
1) Since we call C++ code through a thread without a mutex, it was possible to get a race condition and provoke a segmentation fault
2) Even if there was no race condition, we were not specifying to who the driver is replying all the time. So a cancel request on the 1st PoS could cancel an active transaction on the 2nd PoS.

This PR fixes both issues by specifying the owner of the request and the cid in every single response sent from the driver to the frontend.
I am also adding the cid to the data sent in a cancellation request as otherwise we don't know which transaction line we're cancelling.
It replaces the threads by a queue to avoid race conditions in the future and respect the condition that all the Driver class logic must be executed in the "run" method for safe execution.
It also fixes the Last Transaction Status popup which could accidentally "catch" the response from a transaction since it doesn't care about the cid.
This PR also makes the popup consistent with the response (using error popup for a response resulting in an error).

task-3676153

Forward-Port-Of: odoo/enterprise#54073

This traceback arises when the user tries to create a new `Staff Booking` in a `gantt` view.

To reproduce this issue:

1) Install `Appointment`
2) Open `Appointment/Schedule/Staff Booking`
3) Click on `New` in gantt view of `Staff Booking`. 
4) Traceback arises.

Error:-

```
TypeError: 'int' object is not subscriptable
  File "odoo/http.py", line 2150, in __call__
    response = request._serve_db()
  File "odoo/http.py", line 1722, in _serve_db
    return service_model.retrying(self._serve_ir_http, self.env)
  File "odoo/service/model.py", line 133, in retrying
    result = func()
  File "odoo/http.py", line 1749, in _serve_ir_http
    response = self.dispatcher.dispatch(rule.endpoint, args)
  File "odoo/http.py", line 1953, in dispatch
    result = self.request.registry['ir.http']._dispatch(endpoint)
  File "odoo/addons/base/models/ir_http.py", line 222, in _dispatch
    result = endpoint(**request.params)
  File "odoo/http.py", line 722, in route_wrapper
    result = endpoint(self, *args, **params_ok)
  File "addons/web/controllers/dataset.py", line 24, in call_kw
    return self._call_kw(model, method, args, kwargs)
  File "addons/web/controllers/dataset.py", line 20, in _call_kw
    return call_kw(request.env[model], method, args, kwargs)
  File "odoo/api.py", line 466, in call_kw
    result = _call_kw_multi(method, model, args, kwargs)
  File "odoo/api.py", line 453, in _call_kw_multi
    result = method(recs, *args, **kwargs)
  File "addons/web/models/models.py", line 953, in onchange
    if cmd[0] in (Command.UPDATE, Command.LINK):
```

In `default_get` method, the `partner_ids` value is given as a list of ids.

https://github.com/odoo/enterprise/blob/43f09c5ed91f012a4caa12379ef913ab77de8d2c/appointment/models/calendar_event.py#L41-L42

Which leads to a traceback from here.

https://github.com/odoo/odoo/blob/5e9918f8459c113f1fbf5e59c167fc79a0767f6a/addons/web/models/models.py#L946-L954

After applying this commit, It will resolve the issue by assigning a value using command.

sentry-4625709760

Descritpion of the issue/feature this commit addresses:

At the moment, trying to use the analytic groupy on the Journal Report results in a traceback. It is not possible to use it at all.

---

Steps to reproduce:

1-Activate the Analytic Accounting in the settings 
2-Activate the Analytic Groupby in the Journal Report's options 
3-Go to the Journal Report and apply any Analytic Groupby filter 
4-A traceback shows up

---

Desired behavior after this commit is merged:

This commit handles the issue by adding a check at the very start of the custom handler of the Journal Report. This new check verifies that no analytic groupby filter is being applied on the report. If it is the case, an error is raised to tell the user the feature is not supported by that report.

While at it, the Horizontal Grouping and Period Comparison options have also been disabled because their rendering was making the report unreadable and they added no value to it.

With this commit, the Journal Report can't use Analytic Groupby, Horizontal Grouping or Period Comparison.

---

task-3600349

Forward-Port-Of: odoo/enterprise#53807

Problem
---------
In the commit 24345812cb015e86f362f8c35176646239bfb803 (odoo), we modified the extraction of attachment in such a way that mails coming in a journal from aliases with several attachments create several invoices. Due to the urgency of the task, the computation of whether an attachment needs auto-extraction or not, has been skipped which failing some tests that had been silenced. Linked https://github.com/odoo/enterprise/pull/49816 fixes it. However, as a comment on the said PR suggested, we should add a context key that disable the auto-extraction.

Objective
---------
Add a context key that disable the auto-extraction and update commit [2bfe69be5c64743d0bf35793a427878170d0b3c6](https://github.com/odoo/enterprise/commit/2bfe69be5c64743d0bf35793a427878170d0b3c6) (enterprise) to use the said context key.

Solution
---------
1. Remove the override of the `_needs_auto_extract`
2. Manually set the main attachment of the created moves so that `register_as_main_attachment` is not called when accessing the move. This removes the auto-extraction without the need to use the key (we still keep the context key as suggested by the OCR team).

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

… project upgrade report

Issue Description:
======================
There is an issue in the project upgrade report where an expense with a related analytic account appears twice. This occurs once as "Expenses" and again as "Vendor Bills". This problem does not manifest on runbot with all apps installed, indicating a specific configuration issue.

The installation of the 'project_purchase' module resolves the issue, as the method "_get_already_included_profitability_invoice_line_ids" within both the "project_purchase" and "project_hr_expense" modules performs a check for an 'expense_sheet_id' in account moves. This check helps to exclude these entries from the profitability items, thereby preventing duplication. However, while this solution is effective, it leads to an undesirable addition of the Purchase app to the client's database, which is not acceptable for the client. Relevant code sections: https://github.com/odoo/odoo/blob/1fbcfdf69b503e77e1a931d23dd47df0daf8b2fe/addons/project_hr_expense/models/project_project.py#L70-L78
https://github.com/odoo/odoo/blob/1fbcfdf69b503e77e1a931d23dd47df0daf8b2fe/addons/project_purchase/models/project_project.py#L138

Steps to Reproduce:
======================
1. Install Expense, Accounting, Project, Sales, Employees, Contacts apps on base runbot.
2. Create a service product with 'Prepaid/Fixed Price' and ensure 'Create an Order: Project & Task' is selected.
3. Create and confirm a sales order for the service product created in step 2.
4. In the Expenses app, create an employee-paid expense linked to the sales order's analytic account (e.g., Analytic Distribution: Departments > S00074).
5. Follow the process in the Expenses app by clicking on 'Create Report' > 'Submit to Manager' > 'Approve' > 'Post Journal Entries'.
6. Access Project Updates in the Projects app.
7. Observe that in the project profitability cost section, the same expense is listed twice under different labels: once as "Expenses" and once as "Vendor Bills".

Proposed Solution:
======================
The proposed solution involves modifying the domain of the `_add_purchase_items` function within the `project_account` module, specifically at [this code section](https://github.com/odoo/odoo/blob/763f88e2d45cb7ba107db135eecd0365ba2b8c8b/addons/project_account/models/project_project.py#L14). The enhancement would entail adding a condition to the function's domain to exclude any IDs that are already present in the profitability report. This approach will efficiently prevent the double counting of expenses, ensuring that each expense is represented only once in the project profitability report, thereby maintaining accuracy and consistency in financial tracking. This solution focuses on enhancing the existing functionality with a targeted and efficient modification, ensuring minimal impact on other system components while effectively addressing the issue.

opw-3522293

Forward-Port-Of: odoo/odoo#149485
Forward-Port-Of: odoo/odoo#148986

Current behavior:
When you create an order for partner A but do not confirm it, then settle the order in the PoS and add some product. You will have 2 loyalty cards created for partner A. This is happening because when you confirm the order in the PoS it will confirm the sale order and create a first loyalty card, but the PoS will not be aware of this and when it will try to apply the point for the product added through the PoS it will create a new loyalty card.

Steps to reproduce:
- Activate a loyalty program
- Create a partner A
- Create a sale order for partner A but do not confirm it
- Go to the PoS and settle the order
- Add some product to the order
- Pay the order
- Go to the backend and check the loyalty cards for partner A
- You will have 2 loyalty cards created

To avoid this we will check if the partner has a loyalty card before creating a new one.

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

Forward-Port-Of: odoo/odoo#149482
Forward-Port-Of: odoo/odoo#145782

Curently when trying to select an existing/newly created project in the timesheet section of time off types, it will not recognize that the project exists and will suggest to create it.

Steps to reproduce:
-------------------
* Go to **Setting** -> Enable timesheets
* Go to **Time Off** App -> Configuration -> Time off types
* Create new type
* Go to **Project** App
* Create a new project
* Go back to the configuration of the new time off type
* Enable **developer mode**
* Under timesheet section, select project
* Try selection the new project created
* It suggests to create the project/does not recognize it is already created.

Why the fix:
------------
In multi-company this issue can be handled by going into the settings of the project and selecting the same company as the one in the time off type.

This issue is more problematic in case of single company because the field `company_id` is not available in neither the project form nor the time of type. As of currently, the `company_id` on time off type is by default the current company, while it is `False` by default for the project.

This PR introduced that behavior: https://github.com/odoo/odoo/pull/122144

Since the `company_id` can now also be `False`, it makes sense to enlarge the filter domain on the time off type form. With that in place, the field `timesheet_task_id` also requires changes because a task created in a project with no `company_id` will not have a `company_id`.

opw-3644265

Forward-Port-Of: odoo/odoo#148317

**Description of the issue/feature this PR addresses:**

As `_compute_quantities_dict` does use `stock.move` as a source of calculation we need to make sure that the dedicated owner is set also on inventory moves which was forgotten and resulted in wrongly computed quantities in the past in case of such an use case.


**Current behavior before PR:**
As the owner was not set properly on inventory moves, the dates in the past calculation went wrong and included those moves.

**Desired behavior after PR is merged:**
From now on only the proper moves will be taken into account.

To get this properly for instances out in the wild, it would be helpful to include a fix for the moves without the proper owner somewhere (basically align with `owner_id` of the `stock.move.line`)
Let me know where we will fix this to have again consistency in databases...

Info: @wt-io-it




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

Forward-Port-Of: odoo/odoo#149334