Current behavior: If you use a non cash payment method, with "identify customer" option and register a payment difference at the closing of the session. The difference is not taken into account in the session report. Steps to reproduce: - Activate "identify customer" option on the bank payment method - Open a session - Add a product to the order - Pay the order with the bank payment method - Close the session with a payment difference - Print the session report - Open the report, at

Current behavior:
If you use a non cash payment method, with "identify customer" option
and register a payment difference at the closing of the session. The
difference is not taken into account in the session report.

Steps to reproduce:
- Activate "identify customer" option on the bank payment method
- Open a session
- Add a product to the order
- Pay the order with the bank payment method
- Close the session with a payment difference
- Print the session report
- Open the report, at the bottom you should see the payment difference
  but it is not the case

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

Forward-Port-Of: odoo/odoo#148753
Forward-Port-Of: odoo/odoo#146341

- Inserting a cumulated graph view inside spreadsheet (e.g. cumulated subscription MRR breakdown), - apply a global filter to filter, let's say on the current month => the first data point does not include data from before the current month (the accumulation starts at 0) Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr F

- Inserting a cumulated graph view inside spreadsheet (e.g. cumulated subscription MRR breakdown),
- apply a global filter to filter, let's say on the current month => the first data point does not include data from before the current month (the accumulation starts at 0)

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




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

Forward-Port-Of: odoo/odoo#149084

Following a fix in 16.3 with 5052b9e4a15155c694cf005fdf330997770c6cac, backported in 16.0+ with commit d28a8f67da06e58358b40636d1dca1f91a84e1ad, the rates for the different carriers were computed on page loading, to make sure unavailable carriers were hidden. Nevertheless, this leads to significant increases of /shop/payment page loading time depending on the enabled carriers. This commit restricts the previous fix to the targeted type of carriers, aka `base_on_rule` ones, whose rates do n

Following a fix in 16.3 with 5052b9e4a15155c694cf005fdf330997770c6cac, backported in 16.0+ with commit d28a8f67da06e58358b40636d1dca1f91a84e1ad, the rates for the different carriers were computed on page loading, to make sure unavailable carriers were hidden.

Nevertheless, this leads to significant increases of /shop/payment page loading time depending on the enabled carriers.

This commit restricts the previous fix to the targeted type of carriers, aka `base_on_rule` ones, whose rates do not depend on third party API requests.

Forward-Port-Of: odoo/odoo#149602
Forward-Port-Of: odoo/odoo#149363

[Commit 1](https://github.com/odoo/odoo/commit/7594d71ca8610d5947e80f325ccb57abc23c2c76) changed the class from .ui-draggable to .o_draggable in the snippet_version test, specifically in the run function that checks if all snippets have their data-snippet properly set. Indeed, .o_draggable is set on the parents of draggable elements and not on the elements which are draggable themselves. This lead to a `.every` on an empty array which returns true, and therefore avoids the console.error

[Commit 1](https://github.com/odoo/odoo/commit/7594d71ca8610d5947e80f325ccb57abc23c2c76) changed the class from .ui-draggable to .o_draggable in the
snippet_version test, specifically in the run function that checks
if all snippets have their data-snippet properly set.

Indeed, .o_draggable is set on the parents of draggable elements and not
on the elements which are draggable themselves. This lead to a `.every`
on an empty array which returns true, and therefore avoids the
console.error but did not properly check the snippets.

This commit changes the selector to all snippets which do not have
a [data-module-id] which should be all snippets that are draggable.

[1]: https://github.com/odoo/odoo/commit/7594d71ca8610d5947e80f325ccb57abc23c2c76

Forward-Port-Of: odoo/odoo#148824

Step: ---- - install planning module - active the Dark Mode - open planning model - create shift with material resource - check the material resource icon Issue: ----- when dark mode active that time background and color are not proper show Fix: ----- We have fixed according the tag_list. task-3524295  - requires : https://github.com/odoo/enterprise/pull/54510

Step:
----
 - install planning module
 - active the Dark Mode
 - open planning model
 - create shift with material resource
 - check the material resource icon

Issue:
-----
   when dark mode active that time background and color are not proper show

Fix:
-----
   We have fixed according the tag_list.

task-3524295
![2023-10-11_18-44](https://github.com/odoo/odoo/assets/24606113/93d4167c-3dd3-493d-ae7d-05fa19f491a3)


- requires : https://github.com/odoo/enterprise/pull/54510

Forward-Port-Of: odoo/odoo#138391

Missing _t to translate a string made it so the cart notification title was always in English. opw-3683578 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#149761

Missing _t to translate a string made it so the cart notification title was always in English.

opw-3683578


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

Forward-Port-Of: odoo/odoo#149761

Before this commit, the `allowed_so_line_ids` has been introduced to always use `_default_sale_line_domain` method in the domain of `so_line` field and so instead of easing the domain in the field definition we will be able to override the domain by overriding `_default_sale_line_domain` method. However, since in `sale_timesheet` module, the new domain will contain a dynamic value in the right part of a leaf (`('order_partner_id', 'child_of', commercial_partner_id)`), the `allowed_so_line

Before this commit, the `allowed_so_line_ids` has been introduced
to always use `_default_sale_line_domain` method in the domain of
`so_line` field and so instead of easing the domain in the field definition
we will be able to override the domain by overriding `_default_sale_line_domain`
method. However, since in `sale_timesheet` module, the new domain will contain
a dynamic value in the right part of a leaf
(`('order_partner_id', 'child_of', commercial_partner_id)`), the
`allowed_so_line_ids` is instead use in the domain of `so_line` field to
easily add that leaf in the domain returned `_default_sale_line_domain`
in the compute method of that field. The problem is the number of SOLs
fetched could be really huge and caused a performance issues.

This commit reverts the commit b7491b5b94a1c411fce55565c2bdbddb99b32de5 by
- deprecating the `allowed_so_line_ids`, that is, that field will now always get an empty recordset.
- deprecating the `_default_sale_line_domain` method, that is the method will no longer be used
- manually adding the domain instead of calling `_default_sale_line_domain`
- altering the domain when the `sale_timesheet` module is installed to get the same domain used in the `sale_line_id` of `project.task` model

Forward-Port-Of: odoo/odoo#149747

This commit resolves an issue in the `link_tools` test, specifically addressing a failure that arises when verifying the synchronization between the link's href and the content of the `<a>` tag. The failure was attributed to the oversight of not clicking outside the popup to close it before interacting with the link. runbot-24929 Forward-Port-Of: odoo/odoo#149854 Forward-Port-Of: odoo/odoo#144234

This commit resolves an issue in the `link_tools` test, specifically addressing a failure that arises when verifying the synchronization between the link's href and the content of the `<a>` tag. The failure was attributed to the oversight of not clicking outside the popup to close it before interacting with the link.

runbot-24929

Forward-Port-Of: odoo/odoo#149854
Forward-Port-Of: odoo/odoo#144234

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: - Activa

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#149621
Forward-Port-Of: odoo/odoo#145782

This PR retrieves space between checkbox and label in course groups from view which may be lost in a major owl refactor(https://github.com/odoo/odoo/commit/48ef812a635f70571b395f82ffdb2969ce99da9e) in form view. **Task**-3557567 Forward-Port-Of: odoo/odoo#139313

This PR retrieves space between checkbox and label in course groups from view which may be lost in a major owl refactor(https://github.com/odoo/odoo/commit/48ef812a635f70571b395f82ffdb2969ce99da9e) in form view.

**Task**-3557567

Forward-Port-Of: odoo/odoo#139313

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 time

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#149620
Forward-Port-Of: odoo/odoo#148317

How to reproduce it: - Install website_slides - Go in the course "Basics of Gardening" - Do the test "Test you knowledge" in full screen mode - The information displayed about your answer is glued to the information icon This fix the problem by adding space between the icon and the text using a bootstrap class. Technical note: Although the html has not changed, the problem was not present in previous version because the rendering process was not removing all spaces which is now the cas

How to reproduce it:
- Install website_slides
- Go in the course "Basics of Gardening"
- Do the test "Test you knowledge" in full screen mode
- The information displayed about your answer is glued to the information icon

This fix the problem by adding space between the icon and the text using a bootstrap class.

Technical note: Although the html has not changed, the problem was not present in previous version because the rendering process was not removing all spaces which is now the case. So this doesn't solve the root cause but only that particular case.

Task-3607117

Forward-Port-Of: odoo/odoo#144985

"He lovesto" -> "He loves to" The msg is updated in translation file. Task-3685546 Forward-Port-Of: odoo/odoo#149531

"He lovesto" -> "He loves to"
The msg is updated in translation file.

Task-3685546

Forward-Port-Of: odoo/odoo#149531

remove `console.log` --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#149884

remove `console.log`




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

Forward-Port-Of: odoo/odoo#149884

Before this PR =================== 1). Go to website slides. 2). Open any Course. 3). Click on 'Add a review' or 'Edit your review'. -> We can see that textarea and div both have a border. After this PR ================= When we are in the pop-up view div border will be not shown. Task-3623765 Forward-Port-Of: odoo/odoo#149434

Before this PR
===================
1). Go to website slides.
2). Open any Course.
3). Click on 'Add a review' or 'Edit your review'.
  -> We can see that textarea and div both have a border.

After this PR
=================
When we are in the pop-up view div border will be not shown.

Task-3623765

Forward-Port-Of: odoo/odoo#149434

**How to reproduce** 1. Go to website slides. 2. Open any course which has quiz content. 3. Solve the quiz or open an already solved quiz. -> Here we can see that the reset and continue buttons are overlapped. **After this PR** Now there will be a space between the reset and continue buttons. Task-3635485 Forward-Port-Of: odoo/odoo#146646

**How to reproduce**
1. Go to website slides.
2. Open any course which has quiz content.
3. Solve the quiz or open an already solved quiz. -> Here we can see that the reset and continue buttons are overlapped.

**After this PR**
Now there will be a space between the reset and continue buttons.

Task-3635485

Forward-Port-Of: odoo/odoo#146646

When clicking on a filter on a progress bar of a group, the aggregates need to be recomputed. To do this, a web_read_group is called. Since [1], the key groupDomain was removed, with the result that, the web_read_group is called for all the groups and not only for the needed one. This can be a performance issue. Now, the key groupDomain was reintroduced and the web_read_group is done only for the modified filter's group. [1]: https://github.com/odoo/odoo/commit/8723f020c3587a900c811b8

When clicking on a filter on a progress bar of a group, the aggregates
need to be recomputed. To do this, a web_read_group is called.
Since [1], the key groupDomain was removed, with the result that, the
web_read_group is called for all the groups and not only for the needed
one. This can be a performance issue.

Now, the key groupDomain was reintroduced and the web_read_group is done
only for the modified filter's group.

[1]: https://github.com/odoo/odoo/commit/8723f020c3587a900c811b8cc23f53fe34b98df3

Forward-Port-Of: odoo/odoo#149695

The "Subscriptions" dashboard is wrong. - check the "Top Quotations" and "Top Subscriptions" tables: the both show the same records (wrong domain). - the amounts in the two tables mentionned above are displayed and ordered (!) in the sale order currency. Ordering amounts which are not all in the same currency makes no sense. To fix the issue, those two list now use the model `sale.subscription.report` (instead of `sale.order`) where the amounts are properly normalized to th

The "Subscriptions" dashboard is wrong.

- check the "Top Quotations" and "Top Subscriptions" tables:
the both show the same records (wrong domain).

- the amounts in the two tables mentionned above are displayed
  and ordered (!) in the sale order currency. Ordering amounts
  which are not all in the same currency makes no sense.
  To fix the issue, those two list now use the model
  `sale.subscription.report` (instead of `sale.order`) where
  the amounts are properly normalized to the same currency.
  This comes with a drawback however: 1 `sale.subscription.report`
  is roughly equivalent to a `sale.order.line`, which means we
  don't get the total amount of the SO and we could have twice
  the same SO in the table if it has 2 recurring lines which are
  among the top 10. The "See records" action is also les friendly
  because you end up on the auto-generated form view of
  `sale.subscription.report` (I'll add a form view, but in
  another PR, because it requires an upgrade exception)

- most domains were wrong. They were including cancelled
  subscriptions.

With all those changes, the dashboards show sensible numbers
on next.odoo.com

Task: 3680601

Forward-Port-Of: odoo/enterprise#54146

Before this commit, when a database was upgraded from 15 to 16 with subscription, the sale.order that created the sale.subscription records (O1) could not be updated without triggering the subscription python constraint preventing to have a recurring product and no recurrence. These order when confirmed created the sale.subscription records. During the upgrade, they were linked to the sale.subscription records migrated to sale.order record (O2) with the subscription_id o2m field and their subscr

Before this commit, when a database was upgraded from 15 to 16 with subscription, the sale.order that created the sale.subscription records (O1) could not be updated without triggering the subscription python constraint preventing to have a recurring product and no recurrence. These order when confirmed created the sale.subscription records. During the upgrade, they were linked to the sale.subscription records migrated to sale.order record (O2) with the subscription_id o2m field and their subscription_management field remained identical (empty or 'create' value).

After confirmation if these O1 records where updated to deliver non recurring products for example, it was impossible to update the line and invoice the remaining newly delivered products because they would trigger the python constraint. This commit exclude them based on their values: they have a subscription_id value but no subscription_management value.

opw-ticket: 3634253

Forward-Port-Of: odoo/enterprise#54282
Forward-Port-Of: odoo/enterprise#53081

- Requires : https://github.com/odoo/odoo/pull/138391 task-3524295 -------------------------- This PR fixes an issue about the `colorlist_item` contrast in dark mode. With Odoo 17, the dark mode received an update, and the way we handle our tags changed. We now use two CSS variables: 1. `--background-color` for the background ; 2. `--color` to handle the colors of the tags. This approach allow us to have full control on the visual result of our badges depending on the col

- Requires : https://github.com/odoo/odoo/pull/138391

task-3524295

--------------------------

This PR fixes an issue about the `colorlist_item` contrast in dark
mode.

With Odoo 17, the dark mode received an update, and the way we handle
our tags changed. We now use two CSS variables:

1. `--background-color` for the background ;

2. `--color` to handle the colors of the tags.

This approach allow us to have full control on the visual result of our
badges depending on the color scheme used by the user, by using the same
color but with different adjustments.

While this approach was applied to our badges, it was not applied to the
`colorlist_item_color` class, resulting in a readability issue in dark mode.

To fix this issue, we simply add a `--color` CSS variable inside the
color adjustments made to `colorlist_item`, with the same
parameters as the badges one, to ensure that the text/icon inside a
`colorlist` element is always readable.

| 17.0  | master-web-gantt-dark-mode-issue-irsa |
| ------------- | ------------- |
| ![image](https://github.com/odoo/enterprise/assets/128030743/2fb599ea-cf95-4e48-9fdb-b97241daac0a)  | ![image](https://github.com/odoo/enterprise/assets/128030743/4fbcedfb-4e06-41a8-9fb6-a141bff065b6)  |

Forward-Port-Of: odoo/enterprise#54510

Before this commit, when the user tries to update a timesheet of an archived employee, he got an error saying: "Timesheets before the {last_validated_timesheet_date set on the employee} (included) have been validated, and can no longer be modified" The reason is because the employee is archived and so the check does not fetch the employee to be sure the approver who alters the timesheet is the manager/timesheet manager of the employee archived. This commit fixes the issue by also fetching th

Before this commit, when the user tries to update a timesheet of an archived employee, he got an error saying:
"Timesheets before the {last_validated_timesheet_date set on the employee} (included) have been validated, and can no longer be modified" The reason is because the employee is archived and so the check does not fetch the employee to be sure the approver who alters the timesheet is the manager/timesheet manager of the employee archived.

This commit fixes the issue by also fetching the archived employees to be sure to check is correctly done as expected.

opw-3613473

Forward-Port-Of: odoo/enterprise#54356
Forward-Port-Of: odoo/enterprise#53832

Currently, there is a CSS rule constraining all form sheets of Odoo to have a maximal width of 2600px. Since the Knowledge editor is a form view, it is affected by this rule. As a result, the editor does not fully utilize the available space on large displays, leaving blank space on the right side of the screen. To enhance user comfort, we unset the max-width constraint of the form sheet of Knowledge. The page now takes all available space and the editor is now centered. task-3636625 Forw

Currently, there is a CSS rule constraining all form sheets of Odoo to have a maximal width of 2600px. Since the Knowledge editor is a form view, it is affected by this rule. As a result, the editor does not fully utilize the available space on large displays, leaving blank space on the right side of the screen.

To enhance user comfort, we unset the max-width constraint of the form sheet of Knowledge. The page now takes all available space and the editor is now centered.

task-3636625

Forward-Port-Of: odoo/enterprise#54513
Forward-Port-Of: odoo/enterprise#53926

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

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

Forward-Port-Of: odoo/enterprise#54493

- Fixes missing report label - Fixes incorrect accounts on salary rules - Remove unused salary rules - Adds missing salary rules - Fixes missing leave withhold - Fix report formatting task - 3569881 Forward-Port-Of: odoo/enterprise#54175

- Fixes missing report label
- Fixes incorrect accounts on salary rules
- Remove unused salary rules
- Adds missing salary rules
- Fixes missing leave withhold
- Fix report formatting

task - 3569881

Forward-Port-Of: odoo/enterprise#54175