Some of the records had their `groupby` set to `account_id` in previous versions That field was removed from the data file and new expressions were added. This means that the records which already have `groupby` set won't get that field updated during an upgrade, and will trigger [an error](https://github.com/odoo/odoo/blob/17.0/addons/account/models/account_report.py#L571-L578).

By explicitly removing the value from the field, we ensure the field will be emptied.

The change in the data files comes from: https://github.com/odoo/enterprise/pull/52603

```
odoo.tools.convert.ParseError: while parsing /home/odoo/src/enterprise/17.0/l10n_ro_reports/data/balance_sheet_short.xml:3
Groupby feature isn't supported by aggregation engine. Please remove the groupby value on 'SOLDE C | 43'
```

Note: The original change to the data file happened in saas~16.1. Given that it's not possible to upgrade to intermediate versions any more and there's no issue in standard, the PR targets 17.0.

Forward-Port-Of: odoo/enterprise#62421

Currently, an error occurs when the user tries to select a selection, boolean, or radio field.

Steps to produce an error:
1. Install web_studio
2. Go to Settings > Users & Companies > Users > Select any user
3. Open studio mode by clicking the studio icon.
4. Try to select the Administration field from the access right page

Error:
```
TypeError: WebStudioController.get_default_value() missing 1 required positional argument: 'field_name'
  File "odoo/http.py", line 2139, in __call__
    response = request._serve_db()
  File "odoo/http.py", line 1715, 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 1742, in _serve_ir_http
    response = self.dispatcher.dispatch(rule.endpoint, args)
  File "odoo/http.py", line 1943, in dispatch
    result = self.request.registry['ir.http']._dispatch(endpoint)
  File "addons/website/models/ir_http.py", line 235, in _dispatch
    response = super()._dispatch(endpoint)
  File "odoo/addons/base/models/ir_http.py", line 191, in _dispatch
    result = endpoint(**request.params)
  File "odoo/http.py", line 717, in route_wrapper
    result = endpoint(self, *args, **params_ok)
```

This is because before the owl refactor of webstudio with https://github.com/odoo/enterprise/pull/37285/commits/e44403193cbfd7893708ff739fd072f8bb1197c6, the code tries
to access the field name from the 'attrs' of the node (see [1]), but after Commit[1],
it tries to access the field name from the 'field' of the node (see [1]), and it works for
normal fields like text, number, etc., but not for grouped fields like selection, boolean, radio, etc.

This commit fixes the above issue by not fetching or changing the
default value of reified fields. Now, after this commit, the default
value box is not showing for the reified fields.

 [1]-https://github.com/odoo/enterprise/blob/1fd7b1182146f1d7e6a7cbb9b725cb4d47281e14/web_studio/static/src/legacy/js/views/view_editor_manager.js#L1029 [2]-https://github.com/odoo/enterprise/blob/50b6e04d2e2f47797ec14bf506a030bd1d9bc797/web_studio/static/src/client_action/view_editor/interactive_editor/properties/field_properties/field_properties.js#L117

sentry-4156923959

Forward-Port-Of: odoo/enterprise#63465
Forward-Port-Of: odoo/enterprise#50249

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#63643
Forward-Port-Of: odoo/enterprise#62390

Steps to reproduce [17.0]:

- Go to website (in "Edit" mode) > Click on the "Contact Us" button
- Save the page > The menu will be saved with the "oe_edited_link" class
applied to it.

Technical explanation (one of many scenarios causing the bug) [1]:

After the website headers redesign in [2], two header navbars were added
(for the desktop view and mobile). Which means that the "Contact Us"
field is duplicated in the DOM.

When clicking on the "Contact Us" desktop link, the `LinkPopoverWidget`
will initialize a popover on it. The bootstrap code is automatically
adding `data-original-title` and 'title' attributes to the targeted link
(see: [3]), and as a consequence, the field observer will take in
consideration the mutations and copy the DOM in the mobile version,
leading to save the link in the same state when the BS popover was
applied to it (with the `oe_edited_link` class).

Remarks:

- This behaviour was detected on 17.0, but we target 15.0 here to prevent
similar issues linked to duplicated fields with links in the DOM.

- The bootstrap attributes mutations (as explained in [1]) are just an
example of many possible mutations (filtered by `observerUnactive()` in
the main editor observer) that can cause the issue... Since we cannot
set filters for all these mutations in the fields' observer, we ignore
the `oe_edited_link` (and all editor's rendering classes) when copying
the field content to solve the issue here. The field observer logic
needs to be refactored to probably disable / enable the fields'
synchronization when the editor's observer is disabled / enabled.

[2]: https://github.com/odoo/odoo/pull/119650
[3]: https://github.com/odoo/odoo/blob/15.0/addons/web/static/lib/bootstrap/js/tooltip.js#L664

opw-3938383

Forward-Port-Of: odoo/odoo#167619
Forward-Port-Of: odoo/odoo#166736

Steps to reproduce:
	- Install Time off module
	- Create a public holiday with Working Hours 'calendar_id'
	- Go to env user Time off dashboard

Current behavior before PR:
The public holidays that has 'calendar_id' assigned to it will not be shown in Legend when checking the dashboard of the env user. This is happening because we assign the self 'hr.employee' with the employee_id in context https://github.com/odoo/odoo/blob/c6142d9f1432cfabedcaa7264af9e5bc8e538c20/addons/hr_holidays/models/hr_employee.py#L313 and in '_get_contextual_employee' we just check if employee_id exists in ctx or not
https://github.com/odoo/odoo/blob/17.0/addons/hr_holidays/models/hr_employee.py#L388:L392 
but we don't check the value so if ctx is like {'employee_id': None} it will return None.

Desired behavior after PR is merged:
We are now checking if the 'employee_id' in ctx
has a valid value as if it is not we need to return the employee object of the env user.

Other solution that we can add in this line https://github.com/odoo/odoo/blob/c6142d9f1432cfabedcaa7264af9e5bc8e538c20/addons/hr_holidays/models/hr_employee.py#L313 to check if the self._get_contetxtual_employee is None we assign self to self.env.user.employee_id

opw-3863947

Forward-Port-Of: odoo/odoo#166548

Currently, if you have `pos_restaurant` but not `pos_self_order`, if you add a note on one line of the restaurant order, it visually disappears if you change table and then come back to it.

Steps to reproduce:
-------------------
* Install `pos_restanrant`
* Uninstall `pos_self_order`
* Open the restaurant session
* Select a table and add an item to the order
* Write an internal note
  > You can see the note on the line
* Select **Change table**
* Come back to the previous table
> The note is not visible anymore

Why the fix:
------------
The note added is correctly registered but just invisible to the waiter. It is also visible in the display if you send the order in.

The note field is added by the module `pos_restaurant` but loaded to the ui in `pos_self_order`. Technically the module `pos_self_order` gets auto-installed when `pos_restaurant` is installed but some customer might not have `pos_self_order` if they uninstalled it for example.

`pos_self_order` depends on `pos_restaurant` so we can safely move the code that exports it inside the root module (`pos_restaurant`).

The fix starts in 17.0 as in previous versions it was working fine with only `pos_restaurant` installed.

opw-3917013

Forward-Port-Of: odoo/odoo#167223

**Steps to reproduce:**
- open attendance module
- go to overview and create a new attendance within 5:30 AM

**Issue:**
- Extra hours[overtime_hours] are not calculated accurately[output = 0].

**Cause:**
The [SQL Query](https://github.com/odoo/odoo/blob/17.0/addons/hr_attendance/models/hr_attendance.py#L77-L91)
[condition : date_trunc('day',att.check_in) = date_trunc('day', ot.date)] compares `att.check_in` time stored in UTC with `ot.date` stored in employee timezone, leading to incorrect calculations.

**Solution:**
Modify SQL query to convert `att.check_in` time to employee timezone before comparison with `ot.date`.

In saas-16.4, This [SQL Query](https://github.com/odoo/odoo/blob/saas-16.4/addons/hr_attendance/report/hr_attendance_report.py#L40-L46) is responsible for converting `check_in` time to employee 
timezone.

Description of the issue/feature this PR addresses:

**Current behavior before PR:**

RUNBOT-17.0
![runbot_17](https://github.com/odoo/odoo/assets/145324147/93e63367-54f4-49e0-b1e3-363af002bbc2)

**Desired behavior after PR is merged:**

![image](https://github.com/odoo/odoo/assets/145324147/ac73655d-9cc0-4a93-9494-5517fa262d6e)

UPG - 1573228
TASK - 3900287

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

Forward-Port-Of: odoo/odoo#167574
Forward-Port-Of: odoo/odoo#166302

The main purpose of this patch is to optimize how the location queries
are generated in saas-17.2 in `stock.orderpoint`:
https://github.com/odoo/odoo/blob/dd2da708bc4a42bba9670b874282a2206d8f5ffe/addons/stock/models/stock_orderpoint.py#L366-L374

The generated query is the same in 17.0. The advantage of the `any` operator is
clarity and simplicity in this case.

In saas-17.2 due to the presence of another branch using
`location_final_id` the generated queries are much more efficient with
```py
        dest_loc_domain = [
            '|',
            '&', ('location_final_id', '!=', False), ('location_final_id', 'any', paths_domain),
            '&', ('location_final_id', '=', False), ('location_dest_id', 'any', paths_domain),
        ]
```
vs (current code in saas-17.2)
```py
            dest_loc_domain = expression.OR([dest_loc_domain, [
                '|',
                    '&', ('location_final_id', '!=', False), ('location_final_id.parent_path', '=like', location.parent_path + '%'),
                    '&', ('location_final_id', '=', False), ('location_dest_id.parent_path', '=like', location.parent_path + '%'),
            ]])
```
https://github.com/odoo/odoo/blob/88e75bb11053e3a16455f7d0e882cf2afd4b79a6/addons/stock/models/product.py#L311-L317

The version using the `any` operator is much faster: in an extreme case
with 6K replenish locations the any-based query runs in 1m50s while the
other runs in more than 3h.

In effect this is an example query generated by the ORM without the use
of `any` (3 replenish locations)
```sql
SELECT
  "stock_move"."product_id",
  "stock_move"."location_id",
  SUM("stock_move"."product_qty")
FROM
  "stock_move"
  LEFT JOIN "stock_location" AS "stock_move__location_id" ON ("stock_move"."location_id" = "stock_move__location_id"."id")
  LEFT JOIN "stock_location" AS "stock_move__location_final_id" ON ("stock_m ove"."location_final_id" = "stock_move__location_final_id"."id")
WHERE
  (
    (
      (
        (
          (
            (
              (
                (
                  (
                    "stock_move"."product_id" IN (16, 17, 18, 20, 21, 23, 24, 12, 13, 14, 25, 30, 26, 37, 31, 5, 8, 29, 32, 6, 28)
                  )
                  AND (
                    "stock_move"."state" IN ('waiting', 'confirmed', 'assigned', 'partially_available')
                  )
                )
                AND (
                  "stock_move"."location_final_id" IS NULL
                  OR (
                    "stock_move__location_final_id"."id" IS NULL
                    OR (
                      NOT (
                        (
                          "stock_move__location_final_id"."parent_path" :: text LIKE '1/7/8/18/%'
                        )
                      )
                    )
                  )
                )
              )
              AND (
                "stock_move"."location _final_id" IS NOT NULL
                OR (
                  (
                    "stock_move"."location_dest_id" NOT IN (
                      SELECT
                        "stock_location"."id"
                      FROM
                        "stock_location"
                      WHERE
                        ("stock_location"."parent_path" :: text LIKE '1/7/8/18/%')
                        AND (( "stock_location"."company _id" IN (1))
                          OR "stock_location"."company_id" IS NULL
                        )
                    )
                  )
                  OR "stock_move"."location_dest_id" IS NULL
                )
              )
            )
            AND (
              "stock_move"."location_final_id" IS NULL
              OR (
                "stock_move__location_final_id"."id" IS NULL
                OR (NOT (("stock_move__location_final_id"."parent_path" :: text LIKE '1/7/8/17/%')))
              )
            )
          )
          AND (
            "stock_move"."location_final_id" IS NOT NULL
            OR (
              (
                "stock_move"."location_dest_id" NOT IN (
                  SELECT
                    "stock_location"."id"
                  FROM
                    "stock_locati on"
                  WHERE
                    ("stock_location"."parent_path" :: text LIKE '1/7/8/17/%')
                    AND (("stock_location"."company_id" IN (1))
                      OR "stock_location"."company_id" IS NULL
                    )
                )
              )
              OR "stock_move"."location_dest_id" IS NULL
            )
          )
        )
        AND (
          "stock_ move"."location_final_id" IS NULL
          OR (
            "stock_move__location_final_id"."id" IS NULL
            OR (
              NOT (( "stock_move__location_final_id"."parent_path" :: text LIKE '1/7/8/34/%')
              )
            )
          )
        )
      )
      AND (
        "stock_move"."location_final_id" IS NOT NULL
        OR (
          (
            "stock_move"."location_dest_id" NOT IN (
              SELECT
                "stock_location"."id"
              FROM
                "stock_location"
              WHERE
                ("stock_location"."parent_path" :: text LIKE '1/7/8/34/%')
                AND (
                  ("stock_location"."company_id" IN (1))
                  OR " stock_location"."company_id" IS NULL
                )
            )
          )
          OR "stock_move"."location_dest_id" IS NULL
        )
      )
    )
    AND (
      (
        ("stock_move__location_id"."parent_path" :: text LIKE '1/7/8/18/%')
        OR ("stock_move__location_id"."parent_path" :: text LIKE '1/7/8/17/%')
      )
      OR ("stock_move__location_id"."parent_path" :: text LIKE '1/7/8/34/%')
    )
  )
  AND (
    "stock_move"."company_id" IN (1)
  )
GROUP BY
  "stock_move"."product_id",
  "stock_move"."location_id"
ORDER BY
  "stock_move"."product_id" ASC,
  "stock_move"."location_id" ASC
```

vs the query using `any` variant:
```sql
SELECT
  "stock_move"."product_id",
  "stock_move"."location_id",
  sum("stock_move"."product_qty")
FROM
  "stock_move"
  LEFT JOIN "stock_location" AS "stock_move__location_id" ON ("stock_move"."location_id" = "stock_move__location_id"."id")
  LEFT JOIN "stock_location" AS "stock_move__location_final_id" ON ("stock_m ove"."location_final_id" = "stock_move__location_final_id"."id")
WHERE
  (
    (
      (
        (
          (
            "stock_move"."product_id" IN (16, 17, 18, 20, 21, 23, 24, 12, 13, 14, 25, 30, 26, 37, 31, 5, 8, 29, 32, 6, 28)
          )
          AND (
            "stock_move"."state" IN ('waiting', 'confirmed', 'assigned', 'partially_available')
          )
        )
        AND (
          "stock_move"."location_final_id" IS NULL
          OR (
            "stock_move__location_final_id"."id" IS NULL
            OR (
              NOT (
                (
                  (
                    ("stock_move__location_final_id"."parent_path" :: text LIKE '1/7/8/18/%')
                    OR ("stock_move__location_final_id "."parent_path" :: text LIKE '1/7/8/17/%')
                  )
                  OR ("stock_move__location_final_id"."parent_path" :: text LIKE '1/7/8/34/%')
                )
              )
            )
          )
        )
      )
      AND (
        "stock_move"."location_final_id" IS NOT NULL
        OR (
          (
            "stock_move"."location_dest_id" NOT IN (
              SELECT
                "stock_location"."id"
              FROM
                "stock_location"
              WHERE
                (
                  (
                    ("stock_location"."parent_path" :: text LIKE '1/7/8/18/%')
                    OR ("stock_location"."parent_path" :: text LIKE '1/7/8/17/%')
                  )
                  OR ("stock_location"."parent_pa th" :: text LIKE '1/7/8/34/%')
                )
                AND (
                  ("stock_location"."company_id" IN (1))
                  OR "stock_location"."company_id" IS NULL
                )
            )
          )
          OR "stock_move"."location_dest_id" IS NULL
        )
      )
    )
    AND (
      (
        ("stock_move__location_id"."parent_path" :: text LIKE '1/7/8/18/%')
        OR ("stock_move__location_id"."parent_path" :: text LIKE '1/7/8/17/%')
      )
      OR ("stock_move__location_id"."parent_path" :: text LIKE '1/7/8/34/%')
    )
  )
  AND (
    "stock_move"."company_id" IN (1)
  )
GROUP BY
  "stock_move"."product_id",
  "stock_move"."location_id"
ORDER BY
  "stock_move"."product_id" ASC,
  "stock_move"."location_id" ASC
```

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

Forward-Port-Of: odoo/odoo#167553

Problem:
When a user saves a quotation in the POS session, the quotation gets confirmed into a SO and its invoice_status is "invoiced" but no invoice was created. This occurs because the POS has another POS as its trusted POS. The user is expected the quotation to stay as a quotation when they save it in the POS.

Steps to reproduce:
- Install "Point of Sale" and "Sales" apps
- Create another POS that is not a bar/restaurant
- On the settings of the "Shop" POS, set the newly created POS as its trusted POS
- Create a sales quotation and save
- Open a session in "Shop" POS and click "quotation/order" to import the sales quotation and click on "Settle the order"
- Click on save
- The quotation is now confirmed into a SO when it should not be

Cause:
All quotations with state "draft" or "sent" are confirmed while they shouldn't if the sale is not completed

Solution:
As the variable "draft" from "create_from_ui" is True when saving a quotation and is False when confirming an order, we can use it to proceed or not the confirmation of the quotation

opw-3885845


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

Forward-Port-Of: odoo/odoo#167762
Forward-Port-Of: odoo/odoo#166485

Description of the issue this commit addresses:

When creating an invoice line with the analytic module installed, if the analytic field is show, focusing in on a line adds a little height offset to the entire line which makes the view shaky. This is not wanted.

---

Steps to reproduce:

1 - Install analytic app
2 - Open a new invoice and display the analytic field in the invoice lines
3 - Add a new line, don't add any data inside it.
4 - Focus out, focus in, focus out, focus in.
5 - You can see that focus in adds a few px and focus out removes them.

---

Desired behavior after this commit is merged:

This commit adds a fixed default height to the analyti widget to make sure there is no weird height computation when the focus happens. This way, we can make sure that the line height stays constant whether the focus is in or out of the line.

---

no task-feedback

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

Forward-Port-Of: odoo/odoo#167723