Point of Sale no longer briefly flashes the receipt preview when the system is configured to skip it. Receipts now print directly from the payment screen, creating a cleaner checkout experience for cashiers and customers.

Currently when the pos.config is set to "Skip Preview", when printing a receipt, the receipt or bill screen shows very quickly and disappears. This is not good UX.

Now, the receipt is printed from the payment screen itself. We don't need to show the receipt screen at all.

taskId: 3441238

This fixes how product attachments automatically generate related documents, making the process more reliable. It helps ensure product files are handled correctly with less manual correction needed.

Finetuning of #132739



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

This update corrects internal documentation for mail and discussion models so developer tools identify returned records accurately. It does not change business workflows or user-facing behavior, but helps reduce development errors and improve maintainability.

Before this commit, static methods on discuss models like `.get()` or `.new()` where not properly documented.

The superclass `Record` documents `@returns`, but jsdoc failed to deduce these static methods return subclass instances. We tried to find a way to define things once in `Record` and let typedoc deduce things automatically without overriding in each models just for the sake of type. However typedoc still sucks in 2023 despite requests for improvements to support this specific case since 2016, 7 years ago.

The resume form now prevents users from selecting an end date that is earlier than the start date. This keeps employee resume and certification records accurate and avoids confusing or impossible date entries.

before this commit, in resume we are able to put end date less than start date
which is not possible in real life.
inside form view add daterange widget to start date field so user not able to
select end date less than start date.

task-3397726

This fixes an issue where time off allocations that started in the past could be counted twice after the scheduled accrual process ran. The change ensures balances stay accurate, reducing the risk of employees receiving incorrect leave amounts.

Before this commit, creating a new allocation based on accruals and setting a start date prior to the creation date would compute the amount of days that should already have been accrued during that time. However, the lastcall field is not updated and running the accrual cron leads to a wrong duration.

How to recreate the issue:
- create an accrual plan
- create an allocation set on that accrual
- set a start date in the past for that allocation
- the duration should be automatically set to a value above 0
- save and validate
- run the accrual cron
- the allocation now has its duration doubled

After this commit, the lastcall should be set to the allocation creation date. This way, running the cron will correctly keep the value of the amount of days.

Point of Sale orders now use one consistent order date instead of separate creation and validation dates. This reduces confusion in order processing and helps keep order information aligned across the checkout, tickets, loyalty, online payment, restaurant, and self-order flows.

In this commit:
===============
Revised parsing of order date flow. Eliminated the confusion caused by separate "creation_date" and "validation_date" by consolidating both into the "date_order"  field. This change provides clarity to the parsing of order date process.

The activity dialog now closes directly after scheduling or creating a meeting instead of briefly reloading its buttons. This removes a visible flicker where the Schedule button could momentarily change to Save, especially on slow networks, making the workflow feel smoother and more reliable.

This commit solves a flicker in the action buttons of the activity dialog:
- open project task kanban view
- schedule an activity on a record => this open a dialog
- in that dialog, notice the Schedule button
- click on it
- the button is now, for a small amount of time, replaced by a Save button (If the network goes bad, it can be pretty obvious. Reproduced with the network dev tool)
- the dialog is closed 

When creating a meeting, the save button would be added to the buttons for a small amount of time without replacing any other button instead. By adding the close=1 attribute, the form view of the dialog will no longer reload after the create call which prevents the flicker.

task-3270301

Sale orders now show only the relevant contact name for invoice and delivery address fields after changing the customer, instead of also displaying the full address. This keeps the form easier to read and avoids unnecessary clutter for sales users.

Since https://github.com/odoo/odoo/pull/122085, on the sale order form (with website_sale installed), changing the "Customer" changes the "Invoice Address" & "Delivery Address". But the latter are displayed with the partner name, but also with the full partner address. This last information makes the form uglier than before and are useless.

![image](https://github.com/odoo/odoo/assets/53175387/7ca27bdd-f09d-4d10-9228-c97b0d14613e)

The old `display_name` of `res.partner` was stored in the DB and did not depend on the context. Also, onchange calls add the context of the source field (the one being changed). In this case, `'show_address': 1` is added, and then `display_name` of `partner_invoice_id`/`partner_shipping_id` is also read with this context.

We cannot easily fix this in saas16-4 because it was not possible to change the read context of a particular field. With the new specification of onchange, we can override the read context on a particular field.

This fixes a small usability issue where, after confirming and closing a confirmation dialog, the page did not return focus to the element the user was using before. Restoring focus correctly improves keyboard navigation and makes the interface more predictable, especially for accessibility.

When a dialog is closed, the focus is meant to be restored to the previous focused element.

Before this commit, it did not work for the ConfirmationDialog when the confirm button was clicked. This was because the focus was lost **before** the dialog was closed (because the confirm button is disabled when clicked), and thus the previous focused element was not in the el of the dialog anymore, and thus the focus was not restored.

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

Fixed an issue where appointment booking pages displayed “Invalid DateTime” instead of the day for available slots. This ensures customers can clearly see and select appointment dates, avoiding confusion during booking.

Steps to Reproduce
===================
1. On website click on appointment tab from nav bar.
2. Click on any appointment.
-> on the slot selection page we can see that the day is not showing and instead of day it is showing 'Invalid DateTime'

Technical
==========
Changing fromJSDate() to fromISO() because fromJSDate() only takes date object as an argument but slotDate is a string so it is giving error like 'Invalid DateTime' on UI side.

This bug is comming after the refactor of moment to luxon https://github.com/odoo/enterprise/pull/44051/commits/f543608428dbc255962bf9b7fecc1de3ebeedb68

task-3491906

This update fixes several manufacturing workflow issues, including starting work orders when no user session is available, simplifying finished goods handling, and adding a quicker way to generate serial or lot numbers during quality checks. It also stabilizes a timesheet timer test to reduce unreliable failures in development.

Before this commit, trying to delete a recurrent event that was already synced with Google Calendar or Microsoft Calendar was raising a traceback and not showing the User Error which forbids this action to be done. After this commit, the traceback is not shown anymore and the User Error is correctly presented to the user while trying to delete a recurrent event (with Microsoft synchronization active). Traceback snippet: ``` result = _call_kw_multi(method, model, args, kwargs) File "/

Before this commit, trying to delete a recurrent event that was already synced with Google Calendar or Microsoft Calendar was raising a traceback and not showing the User Error which forbids this action to be done.

After this commit, the traceback is not shown anymore and the User Error is correctly presented to the user while trying to delete a recurrent event (with Microsoft synchronization active).

Traceback snippet: 
```
  result = _call_kw_multi(method, model, args, kwargs)
File "/data/build/odoo/odoo/api.py", line 448, in _call_kw_multi
  result = method(recs, *args, **kwargs)
File "/data/build/odoo/addons/microsoft_calendar/models/calendar.py", line 168, in action_mass_archive
  if self._check_microsoft_sync_status() and any(self.microsoft_id):
TypeError: 'bool' object is not iterable
 
The above server error caused the following client error:
RPC_ERROR: Odoo Server Error
```

Issue: 3468190

Task-id: 3473180

Forward-Port-Of: odoo/odoo#133507
Forward-Port-Of: odoo/odoo#132519

[FIX] web_editor: backspace should keep current node Before this commit: On backspace current node is removed and it's content were moved to it's preceding node. After this commit: Now keeping the current node it removes preceding node if empty and if not empty then merge current node to previous node. ----------------------------------------------- [FIX] web_editor: delete behavior in LI Before this commit: * A backspace at the beggining of a List Item (LI), the

[FIX] web_editor: backspace should keep current node

Before this commit:

On backspace current node is removed and it's content were moved to it's
preceding node.

After this commit:

Now keeping the current node it removes preceding node if empty and if not empty
then merge current node to previous node.


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


[FIX] web_editor: delete behavior in LI


Before this commit:

* A backspace at the beggining of a List Item (LI), the indentation of the list item was reduced by 1 unit.
If not possible, the current LI was merge with the previous LI.
* A delete at the end of a LI, first we remove one unit of indentation from the next LI, 
only when not possible anymore we merge next LI in the current LI.

After this commit:

* A backspace at the begening toggle off the current LI ( the LI tag is remove and popped out of the List )
The parrent List is splitted if needed.
* A delete at the end of a LI directly merge next element inside the current LI.


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


Co-authored-by: Sanjay Sharma <shsa@odoo.com> 
Co-authored-by: Aashish Thakur <aath@odoo.com>


Task-2909314
task-3186679


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

Forward-Port-Of: odoo/odoo#133587
Forward-Port-Of: odoo/odoo#125211

Steps to reproduce: - Create a PO (fifo automated product) - Recieve product - Create the bill and add the landed cost product to it - Create the landed cost before posting the bill - Post the bill Bug: when creating the landed costs if the bill is already posted the created amls are reconciled otherwise they aren't Fix: reconcile the landed costs amls after posting the bill opw-3377088 Forward-Port-Of: odoo/odoo#134235 Forward-Port-Of: odoo/odoo#131395

Steps to reproduce:
- Create a PO (fifo automated product)
- Recieve product
- Create the bill and add the landed cost product to it
- Create the landed cost before posting the bill
- Post the bill

Bug:
when creating the landed costs if the bill is already posted the created amls are reconciled otherwise they aren't

Fix:
reconcile the landed costs amls after posting the bill

opw-3377088

Forward-Port-Of: odoo/odoo#134235
Forward-Port-Of: odoo/odoo#131395

This PR fixes two bugs related to groupbys with tasks in the portal: - The "project" groupby is not available when viewing the tasks of a project with shared documents - When viewing the task of a project, it's impossible to group by something different than "stage" Enterprise: https://github.com/odoo/enterprise/pull/44538 Task-3438490 Forward-Port-Of: odoo/odoo#134271 Forward-Port-Of: odoo/odoo#129520

This PR fixes two bugs related to groupbys with tasks in the portal:
- The "project" groupby is not available when viewing the tasks of a project with shared documents
- When viewing the task of a project, it's impossible to group by something different than "stage"

Enterprise: https://github.com/odoo/enterprise/pull/44538
Task-3438490

Forward-Port-Of: odoo/odoo#134271
Forward-Port-Of: odoo/odoo#129520

This PR makes the necessary changes to the: - CoA - Taxes - Fiscal Positions - Account Tags for supporting the up-to-date reports in the linked Enterprise PR Based on https://github.com/odoo/odoo/pull/106502 by Baskhuu Lodoikhuu (@cubicsoft) Enterprise PR: https://github.com/odoo/enterprise/pull/45047 taskid: 2394909 Forward-Port-Of: odoo/odoo#134288 Forward-Port-Of: odoo/odoo#130511

This PR makes the necessary changes to the:
- CoA
- Taxes
- Fiscal Positions
- Account Tags

for supporting the up-to-date reports in the linked Enterprise PR

Based on https://github.com/odoo/odoo/pull/106502 by Baskhuu Lodoikhuu (@cubicsoft)

Enterprise PR: https://github.com/odoo/enterprise/pull/45047

taskid: 2394909

Forward-Port-Of: odoo/odoo#134288
Forward-Port-Of: odoo/odoo#130511

- Add the registration answers of the attendee in the registration summary. - Add a mobile kanban view for answers on the attendee form to make them more visible. task-3491881 Forward-Port-Of: odoo/odoo#134341 Forward-Port-Of: odoo/odoo#134159

- Add the registration answers of the attendee in the registration summary.
- Add a mobile kanban view for answers on the attendee form to make them more visible.

task-3491881

Forward-Port-Of: odoo/odoo#134341
Forward-Port-Of: odoo/odoo#134159

Steps to reproduce: - set a tax lock date - create a new move - set the accounting date prior to the tax lock date - set an invoice_line with a tax Issue: The banner teeling you information about the tax lock date won't appear unless the move is created. opw-3370727 Forward-Port-Of: odoo/odoo#134259

Steps to reproduce:
- set a tax lock date
- create a new move
- set the accounting date prior to the tax lock date
- set an invoice_line with a tax

Issue:
The banner teeling you information about the tax lock date won't appear unless the move is created.

opw-3370727

Forward-Port-Of: odoo/odoo#134259

Example of issue: `useAutoScroll` scrolls to bottom from `mounted`, user changes scroll value manually, then `useAutoScroll` could reset scroll to bottom from `ResizeObserver`, which could come before `onScroll` registered the new value from the user. Back-port of https://github.com/odoo/odoo/pull/133333 Forward-Port-Of: odoo/odoo#134315

Example of issue: `useAutoScroll` scrolls to bottom from `mounted`, user changes scroll value manually, then `useAutoScroll` could reset scroll to bottom from `ResizeObserver`, which could come before `onScroll` registered the new value from the user.

Back-port of https://github.com/odoo/odoo/pull/133333

Forward-Port-Of: odoo/odoo#134315

To reproduce ============ - on Sign app try to send a contract to a customer to sign - in options the validity date will be 6 months in future - pick a date in past, a user error will be raised the datetime_field won't render back the previous value, which is the one on the record as the update failed Solution ======== put back previous value when the update fails opw-3473467 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of

To reproduce
============
- on Sign app try to send a contract to a customer to sign
- in options the validity date will be 6 months in future
- pick a date in past, a user error will be raised the datetime_field won't render back the previous value, which is the one on the record as the update failed

Solution
========
put back previous value when the update fails

opw-3473467

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

Forward-Port-Of: odoo/odoo#134287
Forward-Port-Of: odoo/odoo#133613

When having an attachment to the qr-bill report, an error is raised when printing the report: "the report's template does not contains the attributes 'data-oe-model' and 'data-oe-id' on the div with 'article' classname." Steps: - With a Swiss company - Activate QR code on customer invoices - Go to Settings>Technical>Reports and select QR-bill - In Advanced Properties tab, set an attachment - Create an invoice for a swiss customer, confirm and print the QR-bill -> Error We this commit, we s

When having an attachment to the qr-bill report,
an error is raised when printing the report:
"the report's template does not contains the
 attributes 'data-oe-model' and 'data-oe-id' on
the div with 'article' classname."

Steps:

- With a Swiss company
- Activate QR code on customer invoices
- Go to Settings>Technical>Reports and select QR-bill
- In Advanced Properties tab, set an attachment
- Create an invoice for a swiss customer, confirm
  and print the QR-bill
-> Error

We this commit, we simply add oe-data-model and
oe-data-id to the div with the article class
in the template, as indicated in the error message.

opw-3480179

Forward-Port-Of: odoo/odoo#133703

When having a payment terms with several lines, the payment term lines are not displayed when printing the invoice if this one has been partially paid. opw-3482256 Forward-Port-Of: odoo/odoo#133934

When having a payment terms with several lines,
the payment term lines are not displayed when
printing the invoice if this one has been
partially paid.

opw-3482256

Forward-Port-Of: odoo/odoo#133934

A recent PR removed some lines in the pos_restaurant tour ( #124157 ). This commit put them back to avoid runbot error. This is a backport of this PR: #129155 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#134267

A recent PR removed some lines in the pos_restaurant tour ( #124157 ). This commit put them back to avoid runbot error.
This is a backport of this PR: #129155

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

Forward-Port-Of: odoo/odoo#134267

[FIX] project: include web_editor.assets_wysiwyg in project.webclient Since [#118966](vscode-file://vscode-app/Applications/Visual%20Studio%20Code.app/Contents/Resources/app/out/vs/code/electron-sandbox/workbench/workbench.html), the `web_editor.assets_wysiwyg` assets are not lazy loaded anymore and therefore need to be included in `project.webclient`. Additionally, `website/static/src/js/utils.js` must be in `web_editor.assets_wysiwyg` for the `project.webclient` to work. The move o

[FIX] project: include web_editor.assets_wysiwyg in project.webclient

Since [#118966](vscode-file://vscode-app/Applications/Visual%20Studio%20Code.app/Contents/Resources/app/out/vs/code/electron-sandbox/workbench/workbench.html), the `web_editor.assets_wysiwyg` assets are not lazy
loaded anymore and therefore need to be included in
`project.webclient`.

Additionally, `website/static/src/js/utils.js` must be in
`web_editor.assets_wysiwyg` for the `project.webclient` to work.

The move of `utils.js` in `web_editor.assets_wysiwyg` required the
adaptation of some assets:

1) Methods that required legacy were move outside of utils.js in
order to prevent introducing legacy method in the
`web_editor.assets_wysiwyg`.

2) A new bundle `website.web_editor_assets_wysiwyg` has been created
to prevent double loading of `utils.js` when clicking on edit and when
calling `loadWysiwygFromTextarea`.

task-3434068

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

Forward-Port-Of: odoo/odoo#129785

https://github.com/odoo/enterprise/pull/46143 Before this commit, messages of type email were not rendered properly in the chatter. For example, the email may display text with dark color even when in dark theme or the layout of bootstrap elements like `btn` might not look correct. These style issues are caused by combining the style in content of the email (e.g. inline styles) with the style of the webclient, giving the impression that the original visual of the email is buggy. This co

https://github.com/odoo/enterprise/pull/46143

Before this commit, messages of type email were not rendered properly in the chatter. For example, the email may display text with dark color even when in dark theme or the layout of bootstrap elements like `btn` might not look correct.

These style issues are caused by combining the style in content of the email (e.g. inline styles) with the style of the webclient, giving the impression that the original visual of the email is buggy.

This commit fixes the issue by showing a slightly transformed style of email messages in chatter that is readable and looks nice with the Odoo theme at hand. In particular with dark theme, the background color matches the bubble color and the text is white.

Sometimes the exact visual of the original email is desired. A button "Show Original Email" in the top-right corner of the message bubble allows seeing the visual of email in its original intention.

Task-3437069

Forward-Port-Of: odoo/odoo#133545
Forward-Port-Of: odoo/odoo#131202

This commit allows you to change the icons of custom links of the social media block after the first save. Thanks to [this other commit], there is now a class that permits to inform the editor that a media is editable even if it is a non-editable parent. This commit permits to use this new class to fix the issue. Steps to reproduce the bug: - Drop a social media block on a page - Add a custom social media - Save - Edit - Try to change the icon of the custom social media with a double

This commit allows you to change the icons of custom links of the social
media block after the first save. Thanks to [this other commit], there
is now a class that permits to inform the editor that a media is
editable even if it is a non-editable parent. This commit permits to use
this new class to fix the issue.

Steps to reproduce the bug:
- Drop a social media block on a page
- Add a custom social media
- Save
- Edit
- Try to change the icon of the custom social media with a double-click

=> The icon cannot be changed.

Note that [another commit] had already been made and fixed the problem
halfway (the icon change didn't work on double-click). This commit
reverts it and fixes the problem correctly with the new system.

[this other commit]: https://github.com/odoo/odoo/commit/6ead397f33512c918f51feb2b32fb3e15ffedf34
[another commit]: https://github.com/odoo/odoo/commit/bb291b35e46e42ca098aa3e04ac0b473f72be423

Fixes https://github.com/odoo/odoo/issues/104048

---

This commit allows you to change the title of the social media block
after the first save. If an element is in a parent that has the class
`o_not_editable` then it is only editable if it has the contenteditable
attribute set to true. We rightfully remove this attribute at saving but
without putting it back when we return to edit mode. This commit allows
to fix this case. Note that we have to improve this system in the future
(so we can get rid of this patch).

This part of the fix is very similar to [this other fix] for the team
block.

[this other fix]: https://github.com/odoo/odoo/commit/b7d53d2fcb20a447fd3098adf94ffb33bc49dda9

---

task-3073171

Forward-Port-Of: odoo/odoo#133989
Forward-Port-Of: odoo/odoo#105964

Steps to reproduce the issue: - Go to the To-do app - Open a task and try to convert it to a task - Look for P Bug: P was not suggested opw:3478943 Forward-Port-Of: odoo/odoo#133473

Steps to reproduce the issue:
    
    - Go to the To-do app
    - Open a task and try to convert it to a task
    - Look for P
    
    Bug:
    
    P was not suggested
    
opw:3478943

Forward-Port-Of: odoo/odoo#133473

Split Payment originally from: odoo/odoo#117989 originally from: odoo/odoo#129524 When an Italian company bills a PA business (for example they're selling cleaning services for a public building) the PA business will send the VAT to the Tax Agency themselves, while generally the VAT is collected and sent to the Tax Agency by the buyer (the PA business). This is done to avoid VAT fraud as the PA doesn't trust the business will actually pay the VAT. That's very common in Italy. A new modul

Split Payment

originally from: odoo/odoo#117989
originally from: odoo/odoo#129524

When an Italian company bills a PA business (for example they're selling cleaning services for a public building) the PA business will send the VAT to the Tax Agency themselves, while generally the VAT is collected and sent to the Tax Agency by the buyer (the PA business). This is done to avoid VAT fraud as the PA doesn't trust the business will actually pay the VAT. That's very common in Italy.
A new module will be created (`l10n_it_edi_pa`) in the next commit to add fields that are required to handle Split Payment, and it will be merged in master.

- New Split Payment related accounts are created: 2607, 2608
- New tax report data to target the VE tax chart grid
- Split Payment account.taxes are Groups of Taxes whose children target VE38 tax grid
- account_tax's l10n_it_vat_due_date is no more, we base ourselves on the VE38 tax grid
- The Group of Taxes includes normal VAT and a reversed VAT entry (both for sale and purchase)
- Tax checks on the invoice now also check group of taxes with flatten_taxes_hierarchy()
- New Split Payment tax group has been added to build the correct totals in the move form view
- account.taxes and account.fiscal.position has been added to change from VAT to VAT Split Payment automatically when you select a res.partner that features the fiscal position.
- The Fiscal Position also has the law-required note that has to be featured on invoices that use Split Payment
- A PA business demo partner is added to showcase the new fiscal position
- `l10n_it_stock_ddt` tests are minimally modified because the Form component didn't let you use 'like' in the move form view

Task link: https://www.odoo.com/web#id=2823645&model=project.task
task-2823645

Forward-Port-Of: odoo/odoo#134215
Forward-Port-Of: odoo/odoo#132026

When sending an bill to sii services, the registration date is set as today, instead of the accounting date. This is because the registration date is automatically set to today when sending the bill. With this commit, we add registration_date field to teh account_move view in other infos tab, to allow the user to manually set it. Steps: - Install l10n_es_edi_sii - Set a tax agency in Accounting > Configuration > Settings - Create a bill, with date and accounting date in the past - Confirm and

When sending an bill to sii services, the registration
date is set as today, instead of the accounting date.
This is because the registration date is automatically
set to today when sending the bill.

With this commit, we add registration_date field
to teh account_move view in other infos tab, to allow
the user to manually set it.

Steps:

- Install l10n_es_edi_sii
- Set a tax agency in Accounting > Configuration > Settings
- Create a bill, with date and accounting date in the past
- Confirm and send to sii services
-> In the file, 'FechaRegContable' is set to today

opw-3478079

Forward-Port-Of: odoo/odoo#134173

…meter Before this commit, the useragent was harcoded and if it was blacklisted by the [osm foundation policy](https://operations.osmfoundation.org/policies/nominatim/) all Odoo instances were forbidden to access the service. This parameter allows to override the user agent with a system parameter. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#134131

…meter

Before this commit, the useragent was harcoded and if it was blacklisted by the [osm foundation policy](https://operations.osmfoundation.org/policies/nominatim/) all Odoo instances were forbidden to access the service.

This parameter allows to override the user agent with a system parameter.





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

Forward-Port-Of: odoo/odoo#134131

Commit 80f8281 introduced an unwanted padding on the right in `o_list_selection_box` on large screen. This commit adapts the spacing of this element to maintain the same rendering whatever the screen size. [1]: 80f82880f82816b17d32efbf4cbe4a1956b2457eac8ad916b17d task-3454841 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#134252

Commit 80f8281 introduced an unwanted padding on the right in `o_list_selection_box` on large screen.
This commit adapts the spacing of this element to maintain the same rendering whatever the screen size.

[1]: 80f82880f82816b17d32efbf4cbe4a1956b2457eac8ad916b17d

task-3454841


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

Forward-Port-Of: odoo/odoo#134252

This error occurs when ```recurrence_id``` has no records when the user tries to delete the sync calendar which has ```recurrent``` events. Error: 'Expected singleton: calendar.recurrence()' Traceback- ``` ValueError: not enough values to unpack (expected 1, got 0) File "odoo/models.py", line 5384, in ensure_one _id, = self._ids ValueError: Expected singleton: calendar.recurrence() File "odoo/http.py", line 2123, in __call__ response = request._serve_db() File "odoo/h

This error occurs when ```recurrence_id``` has no records when the user tries to delete the sync calendar which has ```recurrent``` events.

Error: 'Expected singleton: calendar.recurrence()'

Traceback-
```
ValueError: not enough values to unpack (expected 1, got 0)
  File "odoo/models.py", line 5384, in ensure_one
    _id, = self._ids
ValueError: Expected singleton: calendar.recurrence()
  File "odoo/http.py", line 2123, in __call__
    response = request._serve_db()
  File "odoo/http.py", line 1699, 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 1726, in _serve_ir_http
    response = self.dispatcher.dispatch(rule.endpoint, args)
  File "odoo/http.py", line 1927, in dispatch
    result = self.request.registry['ir.http']._dispatch(endpoint)
  File "addons/website/models/ir_http.py", line 234, in _dispatch
    response = super()._dispatch(endpoint)
  File "odoo/addons/base/models/ir_http.py", line 190, in _dispatch
    result = endpoint(**request.params)
  File "odoo/http.py", line 716, in route_wrapper
    result = endpoint(self, *args, **params_ok)
  File "addons/web/controllers/dataset.py", line 30, in call_kw
    return self._call_kw(model, method, args, kwargs)
  File "addons/web/controllers/dataset.py", line 26, in _call_kw
    return call_kw(request.env[model], method, args, kwargs)
  File "odoo/api.py", line 461, in call_kw
    result = _call_kw_multi(method, model, args, kwargs)
  File "odoo/api.py", line 448, in _call_kw_multi
    result = method(recs, *args, **kwargs)
  File "addons/calendar/models/calendar_event.py", line 871, in action_mass_archive
    detached_events = self.recurrence_id._stop_at(self)
  File "addons/calendar/models/calendar_recurrence.py", line 278, in _stop_at
    self.ensure_one()
  File "odoo/models.py", line 5387, in ensure_one
    raise ValueError("Expected singleton: %s" % self)
```

See-
https://github.com/odoo/odoo/blob/95fccaba4555f2be6712154a84a143f589a3f54c/addons/calendar/models/calendar_event.py#L714-L715
sentry-4367276387

Forward-Port-Of: odoo/odoo#131155

Current behavior: If you set a specific sale_order_item for an employee on a project, and create a timesheet line from the "My Timesheets" menu, the sale_order_item will not be the one you selected for this employee. This happens because when you create a timesheet line from the "My Timesheets" menu, the employee is not set on the timesheet line. To fix this we fallback on the user's employee when creating a timesheet line from the "My Timesheets" menu. Steps to reproduce

Current behavior:
  If you set a specific sale_order_item for an employee on a project, and
  create a timesheet line from the "My Timesheets" menu,
  the sale_order_item will not be the one you selected for this employee.
  This happens because when you create a timesheet line from the "My
  Timesheets" menu, the employee is not set on the timesheet line.
  To fix this we fallback on the user's employee when creating a timesheet
  line from the "My Timesheets" menu.

Steps to reproduce:
  - Make sure you'r logged in as Mitchel Admin
  - Create a service product that create project and tasks
  - Create a sale order with this product
  - Go to the project and set a sale order item for Mitchel Admin in the invoicing tab
  - Go to the "My Timesheets" menu and click "Add Line"
  - Select the project you created
  - The sale order item will not be autofilled with the one set on the invoicing tab of the project.

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

Forward-Port-Of: odoo/odoo#133478

Current behaviour before commit: When pasting copied content from editor inside link inserts text with HTML content, in result the pasted content seems isolated from the link. e.g. ``` <a href="#">te[]st</a> + pasting <h1>123</h1> <=> <a href="#">te<h1>123</h1>st</a> ``` Desired behaviour after commit: Now only text content is pasted which makes pasted content as a part of the link. e.g. ``` <a href="#">te[]st</a> + pasting <h1>123</h1> <=> <a href="#">te123st</a> `

Current behaviour before commit:

When pasting copied content from editor inside
link inserts text with HTML content, in result
the pasted content seems isolated from the link.
e.g.
```
<a href="#">te[]st</a>
	+ pasting <h1>123</h1> <=>
<a href="#">te<h1>123</h1>st</a>

```

Desired behaviour after commit:

Now only text content is pasted which makes
pasted content as a part of the link.
e.g.
```
<a href="#">te[]st</a>
	+ pasting <h1>123</h1> <=>
<a href="#">te123st</a>

```

task-3304907


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

Forward-Port-Of: odoo/odoo#134294
Forward-Port-Of: odoo/odoo#125776

Follow-up of https://github.com/odoo/odoo/pull/130821 `name_get` has been deprecated for `display_name`. In old `name_get`, when the record had no display_name (`convert(rec._rec_name)` returns `False`) then the fallback was empty string `""`. This has been changed with default `_compute_display_name`, to instead show `<rec._name>,<rec.id>`. Discuss channel `display_name` was relying on this "" fallback somehow: even though `rec._rec_name == ""`, `convert("") == False`, thus fallback "" ca

Follow-up of https://github.com/odoo/odoo/pull/130821

`name_get` has been deprecated for `display_name`. In old `name_get`, when the record had no display_name (`convert(rec._rec_name)` returns `False`) then the fallback was empty string `""`. This has been changed with default `_compute_display_name`, to instead show `<rec._name>,<rec.id>`.

Discuss channel `display_name` was relying on this "" fallback somehow: even though `rec._rec_name == ""`, `convert("") == False`, thus fallback "" cancels out to "". The value "" for name is intentional and necessary in discuss channels for the good working of some other fallbacks UI, e.g. group chat concats member names. With the recent changes of `_compute_display_name` default fallback, it showed `discuss.channel,10` instead of "".

Steps to reproduce:
- Log in as Mitchell Admin
- Open Discuss app
- Click "Start a meeting"
=> expected: shows group chat name "Mitchell Admin"
=> result: shows group chat name "discuss.channel,10"

This commit fixes the issue by removing reliance on `display_name` for discuss channels: it always uses `name`, thus showing taking into account `""` as it needs for fallbacks like in group chat when it has no name.

Task-3493629

Before / After
![before](https://github.com/odoo/odoo/assets/6569390/001b5bf1-518b-4496-a00b-97cf989bc9eb) ![after](https://github.com/odoo/odoo/assets/6569390/c3948e19-2ca9-4460-8104-7e4e4bad0d00)

Forward-Port-Of: odoo/odoo#134398

Task: #3469914 Current behavior before PR: The name field was previously optional when adding a new instance from the tree view, which in the absence of a name, 'false' is indicated in the calendar view. Desired behavior after PR is merged: The field is now set as mandatory. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#132772

Task: #3469914

Current behavior before PR:
The name field was previously optional when adding a new instance from the tree view, which in the absence of a name, 'false' is indicated in the calendar view.

Desired behavior after PR is merged:
 The field is now set as mandatory.




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

Forward-Port-Of: odoo/odoo#132772

Prior to this commit, ever since [1], it was no longer possible to refresh the page and stay in the backend at the same time. This was known at the time and was an accepted downside. However, with this commit, a compromise has been found, if the keyboard shortcut is used while the Website Preview is shown (mounted), then the website preview will do its best to keep the user inside the backend. This will make developing features for the website modules easier, as before, every refresh would

Prior to this commit, ever since [1], it was no longer possible to refresh the page and stay in the backend at the same time. This was known at the time and was an accepted downside.

However, with this commit, a compromise has been found, if the keyboard shortcut is used while the Website Preview is shown (mounted), then the website preview will do its best to keep the user inside the backend.

This will make developing features for the website modules easier, as before, every refresh would necessitate an extra click to get back in the backend.

To note: the debug=[mode] param would also be lost on refreshing a website page. Starting 16.4, since [2], this would make tracebacks harder to read as for every refresh, they would no longer point to the source, rather just the minified file. Therefore, with this commit, every refresh also keeps the debug mode in the URL.

[1]: https://github.com/odoo/odoo/commit/1c18b79972c3b0a97197b98390e0ba9fda703585
[2]: https://github.com/odoo/odoo/commit/59f49d6a8c856a5d8ca28dcfd7840baaa1c7672f

task-3458691

Forward-Port-Of: odoo/odoo#131236

**Description of the issue/feature this PR addresses:** Before this commit when you copy a chatbot script, the triggering answer are mixing. - Create a chatbot - Create a line A - question ligne with one response 1 - Create a line B - type text - Create a line C - type text - Save - Invert line B and C - on ligne C add response 1 in triggering answer - Save - Copy the script --> Issue the response 1 in triggering answer is now in line B https://github.com/odoo/odoo/assets/167169

**Description of the issue/feature this PR addresses:**
Before this commit when you copy a chatbot script, the triggering answer are mixing.

- Create a chatbot
- Create a line A - question ligne with one response 1
- Create a line B - type text
- Create a line C - type text
- Save
- Invert line B and C
- on ligne C add response 1 in triggering answer
- Save
- Copy the script --> Issue the response 1 in triggering answer is now in line B


https://github.com/odoo/odoo/assets/16716992/fab4d1ef-6aaf-4232-bc90-c232e6186054


@tde-banana-odoo 



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

Forward-Port-Of: odoo/odoo#133924

Before this commit, a test in `timesheet_grid` to check the grid view used in `My Timesheets` fails before it does not find the overtime displayed in the total column. This commit patches the setTimeout function before the mouseover event is debounced and so we have to wait the timeout is done before checking if the overtime is displayed. With the patch, we no longer have to wait in the test to have the overtime displayed when the mouseover is triggered on total cell on the grid view. runb

Before this commit, a test in `timesheet_grid` to check the grid view used in `My Timesheets` fails before it does not find the overtime displayed in the total column.

This commit patches the setTimeout function before the mouseover event is debounced and so we have to wait the timeout is done before checking if the overtime is displayed. With the patch, we no longer have to wait in the test to have the overtime displayed when the mouseover is triggered on total cell on the grid view.

runbot-22358

Forward-Port-Of: odoo/enterprise#46991

Issue: When using the field service module, running the manual tour may encounter an issue where it gets stuck on the 'company_id' and only releases the trigger when specific input is provided. fix: Implement a run function to activate the company_id trigger when selecting any record task-3457171 Forward-Port-Of: odoo/enterprise#45407

Issue:
When using the field service module, running the manual tour may encounter an issue where it gets stuck on the 'company_id' and only releases the trigger when specific input is provided.

fix:
Implement a run function to activate the company_id trigger when selecting any record

task-3457171

Forward-Port-Of: odoo/enterprise#45407

From the POS, one can ask for a refund for an order. If this order was invoiced with CFDI enabled, it has been sent to the government and has a `Fiscal Folio` (an ID for this invoice with the government). Mexico requires to fill the `Fiscal Folio` of the refunded invoice (as the `CFDI Origin`) when creating a credit note. task-3491567 Forward-Port-Of: odoo/enterprise#47014

From the POS, one can ask for a refund for an order. If this order was invoiced with CFDI enabled, it has been sent to the government and has a `Fiscal Folio` (an ID for this invoice with the government).

Mexico requires to fill the `Fiscal Folio` of the refunded invoice (as the `CFDI Origin`) when creating a credit note.

task-3491567

Forward-Port-Of: odoo/enterprise#47014

When viewing the task of a project with shared documents in the portal, they are automatically grouped by projects by default. However, selecting any other value for the groupby doesn't work, and they stay grouped by project. This PR fixes the groupby for other values. Task-3438490 Forward-Port-Of: odoo/enterprise#46939 Forward-Port-Of: odoo/enterprise#44543

When viewing the task of a project with shared documents in the portal, they are automatically grouped by projects by default. However, selecting any other value for the groupby doesn't work, and they stay grouped by project.

This PR fixes the groupby for other values.

Task-3438490

Forward-Port-Of: odoo/enterprise#46939
Forward-Port-Of: odoo/enterprise#44543

1. Fix typo 2. Adapt the code since `_get_options` was renamed to `get_options` 3. Do not show the state "rejected" on the widget of the export 4. Translate the error messages returned by IAP Forward-Port-Of: odoo/enterprise#44404

1. Fix typo
2. Adapt the code since `_get_options` was renamed to `get_options`
3. Do not show the state "rejected" on the widget of the export
4. Translate the error messages returned by IAP

Forward-Port-Of: odoo/enterprise#44404

Steps to reproduce: - Install Accounting, Sales, eCommerce and Contacts - Go to Accounting settings and configure AvaTax - Go to Sales settings and activate Delivery Methods - Go to Contacts and configure complete address (in US) and Fiscal Position to "AvaTax" for a contact (e.g. Mitchell Admin) - Create 2 shipping methods with different fixed price (e.g. $10 and $20) - Configure the corresponding delivery products with a customer tax (e.g. Tax 15%) and an AvaTax category (e.g. [FR20100]

Steps to reproduce:
- Install Accounting, Sales, eCommerce and Contacts
- Go to Accounting settings and configure AvaTax
- Go to Sales settings and activate Delivery Methods
- Go to Contacts and configure complete address (in US) and Fiscal Position to "AvaTax" for a contact (e.g. Mitchell Admin)
- Create 2 shipping methods with different fixed price (e.g. $10 and $20)
- Configure the corresponding delivery products with a customer tax (e.g. Tax 15%) and an AvaTax category (e.g. [FR20100] Shipping only common carrier - fob destination)
- Create a product (e.g. Product X) with an AvaTax category (e.g. [D0000000] Digital goods)
- Go to eCommerce with Mitchell Admin
- Add Product X to cart
- Process checkout. On the payment page, a delivery method is selected by default. The taxes (for the product and the delivery) are computed with AvaTax correctly.
- Select another delivery method. The taxes for the delivery are not recomputed by AvaTax, but are based on the customer tax configured on the delivery product. If you pay the order, a draft SO will be created with the same amount. But when this SO will be confirmed, the taxes will be recomputed with AvaTax and the amount of the SO will be different from the one paid by customer.

Solution:
Recompute the taxes on the delivery with AvaTax when the delivery method is updated as it is done for TaxCloud.

opw-3375354

Forward-Port-Of: odoo/enterprise#46923
Forward-Port-Of: odoo/enterprise#46491

Issue: ------------------- On the website shopping when we go to a product page and there is a subscription product in the recommended product list, the unit of subscription (month, year, etc) is not being translated Steps to reproduce: ------------------- 1. Create two products, where one of them is recurrent 2. Inside the product form -> Sales 3. Make each product a optional/accessory product of the other 4. Publish both products 5. Go to the website shop and choose the non-recurren

Issue:
-------------------
On the website shopping when we go to a product page and there is a subscription product in the recommended product list, the unit of subscription (month, year, etc) is not being translated

Steps to reproduce:
-------------------
1. Create two products, where one of them is recurrent
2. Inside the product form -> Sales
3. Make each product a optional/accessory product of the other
4. Publish both products
5. Go to the website shop and choose the non-recurrent product and change the language to French
6. Note that the recurrent product is displayed "par year"

Cause:
-------------------
The issue is happening because in the respective view, the unit is shown by <span>per</span> and the unit is displayed by data.get('subscription_unit') which is not translated.

This makes the string “Per” be correctly translated while the unit not. To fix this issue we can use data.get('subscription_unit_display') and it correctly displays the unit using the correct translation.

OPW-3294222

Forward-Port-Of: odoo/enterprise#45809

When importing a FEC file, we set the xmlid of the accounts with the original code given in the file. Therefore we can't retrieve the xmlid if an other line have the same code with extra 0s. Let's assume a line with account code 5120010, then the xmlid will be set as `l10n_fr_fec_import.account_5120010` as the account itself is saved with code 512001. Now if another line has an account code 512001, then we don't recreate an xmlid because account has already been created, but when saving the mov

When importing a FEC file, we set the xmlid of the
accounts with the original code given in the file.
Therefore we can't retrieve the xmlid if an other
line have the same code with extra 0s.

Let's assume a line with account code 5120010, then
the xmlid will be set as `l10n_fr_fec_import.account_5120010`
as the account itself is saved with code 512001.
Now if another line has an account code 512001, then
we don't recreate an xmlid because account has already been
created, but when saving the moves related to 512001, we're
looking for xmlid `l10n_fr_fec_import.account_512001` which
doesn't exist.

With this commit, we adapt the way we set the xmlid by
setting it with the account code truncated at 6 digits,
and we do the same when looking for a xmlid in the partner
and move generator. We've also adjusted the tests to ensure
consistent behavior in line with expectations.

opw-3455682

Forward-Port-Of: odoo/enterprise#46564

When asking a Worldline terminal for a payment currently PoS gets stuck and never receives a response This PR fixes this issue Forward-Port-Of: odoo/enterprise#46822

When asking a Worldline terminal for a payment currently PoS gets stuck and never receives a response
This PR fixes this issue

Forward-Port-Of: odoo/enterprise#46822

…iation When reconciling lines with amount_residual_currency = 0 an error was thrown. We need to reconcile in company currency in those cases, and not in foreign currency as previously. opw-3411600 Forward-Port-Of: odoo/enterprise#46892 Forward-Port-Of: odoo/enterprise#45721

…iation

When reconciling lines with amount_residual_currency = 0 an error was thrown. We need to reconcile in company currency in those cases, and not in foreign currency as previously.

opw-3411600

Forward-Port-Of: odoo/enterprise#46892
Forward-Port-Of: odoo/enterprise#45721

Steps to reproduce: 1. install l10n_de_pos_cert and set up fiskaly 2. set up PoS in German company 3. set the language to German 4. open PoS and validate an order User Error: ```An unknown error occured! Please, contact Odoo.``` Error from Fiskaly: ```error parsing request body: amounts_per_vat_rate.0.amount: Does not match pattern '^-?\d+(.\d{2,5})$' amounts_per_payment_type.0.amount: Does not match pattern '^-?\d+(.\d{2,5})$'``` The error comes from the fact that `formatCurren

Steps to reproduce:

1. install l10n_de_pos_cert and set up fiskaly
2. set up PoS in German company
3. set the language to German
4. open PoS and validate an order

User Error:
```An unknown error occured! Please, contact Odoo.```

Error from Fiskaly:
```error parsing request body: amounts_per_vat_rate.0.amount: Does not match pattern '^-?\d+(.\d{2,5})$' amounts_per_payment_type.0.amount: Does not match pattern '^-?\d+(.\d{2,5})$'```

The error comes from the fact that `formatCurrency` method is used to convert the amounts to string. However it adds language specific formatting. In this case Fiskaly expects `12.50` but `12,50` is sent.

opw-3484169

Forward-Port-Of: odoo/enterprise#46717
Forward-Port-Of: odoo/enterprise#46682

https://github.com/odoo/odoo/pull/131202 Before this commit, messages of type email were not rendered properly in the chatter. For example, the email may display text with dark color even when in dark theme or the layout of bootstrap elements like btn might not look correct. These style issues are caused by combining the style in content of the email (e.g. inline styles) with the style of the webclient, giving the impression that the original visual of the email is buggy. This commit fi

https://github.com/odoo/odoo/pull/131202

Before this commit, messages of type email were not rendered properly in the chatter. For example, the email may display text with dark color even when in dark theme or the layout of bootstrap elements like btn might not look correct.

These style issues are caused by combining the style in content of the email (e.g. inline styles) with the style of the webclient, giving the impression that the original visual of the email is buggy.

This commit fixes the issue by showing a slightly transformed style of email messages in chatter that is readable and looks nice with the Odoo theme at hand. In particular with dark theme, the background color matches the bubble color and the text is white.

Sometimes the exact visual of the original email is desired. A button "Show Original Email" in the top-right corner of the message bubble allows seeing the visual of email in its original intention.

Task-3437069

Forward-Port-Of: odoo/enterprise#46522
Forward-Port-Of: odoo/enterprise#46143

For fixing the issue odoo/odoo#129785, we add the assets `web_editor.assets_wysiwyg` in `project.webclient`. Before this commit, some wysiwyg assets required for knowledge were added to `web_editor.assets_wysiwyg`. Because `project.webclient` does not include all the dependency required by the knowledge assets, the bundle `web_editor.assets_wysiwyg` could not load. As the knowledge assets that were added in `web_editor.assets_wysiwyg` are only needed in the backend, this commit move them to `web

For fixing the issue odoo/odoo#129785, we add the assets `web_editor.assets_wysiwyg` in `project.webclient`. Before this commit, some wysiwyg assets required for knowledge were added to `web_editor.assets_wysiwyg`. Because `project.webclient` does not include all the dependency required by the knowledge assets, the bundle `web_editor.assets_wysiwyg` could not load. As the knowledge assets that were added in `web_editor.assets_wysiwyg` are only needed in the backend, this commit move them to `web.assets_backend`.

Note: In the past, the assets were necessary to be added in `web_editor.assets_wysiwyg` before odoo/odoo#118966 because `web_editor.assets_wysiwyg` was lazy loaded. Because in that PR `web_editor.assets_wysiwyg` is included in `web.assets_backend`, the assets for knowledge can now be added in `web.assets_backend`.

task-3434068

Forward-Port-Of: odoo/enterprise#46451

### Current behaviour In the Manufacturing module, we get inconsistant values depending on the expected date and time of purchase orders ### Steps to reproduce - Set 'Time range' of Master production Schedule to 'Daily' in Manufacturing's settings - Create a product and his BOM. - Create a purchase order on that product with an expected date of '2023-08-04 00:30:00', quantity: 10 and confirm. - Create another purchase order on the same product with an expected date of '2023-08-04 11:30:0

### Current behaviour
In the Manufacturing module, we get inconsistant values depending on the expected date and time of purchase orders

### Steps to reproduce
- Set 'Time range' of Master production Schedule to 'Daily' in Manufacturing's settings
- Create a product and his BOM.
- Create a purchase order on that product with an expected date of '2023-08-04 00:30:00', quantity: 10 and confirm.
- Create another purchase order on the same product with an expected date of '2023-08-04 11:30:00', quantity: 20 and confirm.
- Go to Master Production Schedule in Manufacturing
- Add the created product to be displayed.

### Issue
On the 'Suggested Replenishment' we have quantity 10 on 'Aug 3' and 20 on 'Aug 4'.
![Screenshot from 2023-08-03 15-48-08](https://github.com/odoo/enterprise/assets/97248555/9bce7d3a-7e47-4b1c-bbf9-45b26f3e968a)


### Expected
We must have 30 on 'Aug 04'
![Screenshot from 2023-08-03 15-49-14](https://github.com/odoo/enterprise/assets/97248555/b52d9c6e-c219-48a4-a527-d45e5a85af18)


### Reason of the problem
We call search on ``StockMove`` and ``PurchaseOrderLine`` in a range date which doesn't consider the time, and the timezone of the user.

### Solution
Create a range date in utc timezone specially for search, retrieve the records and map the quantities to dates with the timezone.

opw-3299645

Forward-Port-Of: odoo/enterprise#45174

### Steps 1. Access the Sequences menu 2. Access the sequence with the Sequence Code helpdesk.ticket 3. Change the next number to a an arbitrarily different number 4. Go to the Website app and click "GO TO WEBSITE" 5. Click on "Pages" and then click on "Edit Menu" 6. Click on "Add Menu Item" and enter in the Menu Label text box "Help" and enter in the URL or Email text box "/helpdesk" 7. Save your changes 8. Go to your help desk form by clicking on "Help" in the menu and create your help

### Steps
1. Access the Sequences menu
2. Access the sequence with the Sequence Code helpdesk.ticket
3. Change the next number to a an arbitrarily different number
4. Go to the Website app and click "GO TO WEBSITE"
5. Click on "Pages" and then click on "Edit Menu"
6. Click on "Add Menu Item" and enter in the Menu Label text box "Help" and enter in the URL or Email text box "/helpdesk"
7. Save your changes
8. Go to your help desk form by clicking on "Help" in the menu and create your helpdesk ticket

### Issue
The id displayed in the message of confirmation is different from the ticket reference which results in inconsistancy

### Reason
The Message of confirmation shows ``id`` instead of ``ticket_ref``

opw-3452762

Forward-Port-Of: odoo/enterprise#46528

We can now see the simple choice answer of an attendee after scanning a barcode from the registration desk. task-3491881 Forward-Port-Of: odoo/enterprise#46925 Forward-Port-Of: odoo/enterprise#46819

We can now see the simple choice answer of an attendee after scanning a barcode from the registration desk.

task-3491881

Forward-Port-Of: odoo/enterprise#46925
Forward-Port-Of: odoo/enterprise#46819

Steps to reproduce: 1) While being in company A, go to tax report and generate the xml file 2) Duplicate the tab from step 1 and change to company to B 3) Go back to tab from step 1 and generate the xml file Bug: XML file generated in step 3 (company A) is for the company from step 2 (company B) Fix: send current company as an argument (similar to previous versions) and only default to cookies opw-3424627 Forward-Port-Of: odoo/enterprise#45375

Steps to reproduce:
1) While being in company A, go to tax report and generate the xml file 
2) Duplicate the tab from step 1 and change to company to B 
3) Go back to tab from step 1 and generate the xml file

Bug:
XML file generated in step 3 (company A)
is for the company from step 2 (company B)

Fix:
send current company as an argument (similar to previous versions) and only default to cookies

opw-3424627

Forward-Port-Of: odoo/enterprise#45375

This PR brings improvements to the following Mongolian reports: - Balance Sheet - Profit and Loss - Cash Flow Statement - Corporate Tax Report - VAT repayment Report Based on https://github.com/odoo/enterprise/pull/34374 by Baskhuu Lodoikhuu (@cubicsoft) Corporate Tax Report reference: [corporate_tax_form_tt02_.pdf](https://github.com/odoo/enterprise/files/12395751/corporate_tax_form_tt02_.pdf) VAT report reference: https://legalinfo.mn/mn/detail?lawId=210783&showType=1 Communit

This PR brings improvements to the following Mongolian reports:
- Balance Sheet
- Profit and Loss
- Cash Flow Statement
- Corporate Tax Report
- VAT repayment Report

Based on https://github.com/odoo/enterprise/pull/34374 by Baskhuu Lodoikhuu (@cubicsoft)

Corporate Tax Report reference: [corporate_tax_form_tt02_.pdf](https://github.com/odoo/enterprise/files/12395751/corporate_tax_form_tt02_.pdf)

VAT report reference: https://legalinfo.mn/mn/detail?lawId=210783&showType=1

Community PR: https://github.com/odoo/odoo/pull/130511
 
taskid: 2394909

Forward-Port-Of: odoo/enterprise#46893
Forward-Port-Of: odoo/enterprise#45047

When viewing an individual project in the portal, despite there being a single project, we still want to group by project when that project has shared documents, so that the "Documents" button is displayed. This PR readds this behavior for projects that have shared documents. Community: https://github.com/odoo/odoo/pull/129520 Task-3438490 Forward-Port-Of: odoo/enterprise#46880 Forward-Port-Of: odoo/enterprise#44538

When viewing an individual project in the portal, despite there being a single project, we still want to group by project when that project has shared documents, so that the "Documents" button is displayed.

This PR readds this behavior for projects that have shared documents.

Community: https://github.com/odoo/odoo/pull/129520
Task-3438490

Forward-Port-Of: odoo/enterprise#46880
Forward-Port-Of: odoo/enterprise#44538

When the message is short, the copy button is in the middle of the popup instead of being aligned on the right. Forward-Port-Of: odoo/enterprise#46878

When the message is short, the copy button is in the middle of the popup instead of being aligned on the right.

Forward-Port-Of: odoo/enterprise#46878

Since the reportalypse, the grouped report needs to be referenced differently. This commit changes the tax report referenced to the grouped tax report, so that we can retrieve amounts by account. These are then used to pre-compute the repartition fields. Forward-Port-Of: odoo/enterprise#46835 Forward-Port-Of: odoo/enterprise#46679

Since the reportalypse, the grouped report needs to be referenced differently. This commit changes the tax report referenced to the grouped tax report, so that we can retrieve amounts by account. These are then used to pre-compute the repartition fields.

Forward-Port-Of: odoo/enterprise#46835
Forward-Port-Of: odoo/enterprise#46679

Currently, When the user changes the company currency with deactivating the default currency and try to install sale_ebay module he receives an exception at the backend. To reproduce the issue: 1. Create a database without demo data. 2. Install invoicing module. 3. In Settings > Open Companies from Users&Companies menu. 4. Open My Company and change its currency from default to any other currency. 5. Go to Invoicing Settings > click on the currencies button and deactivate the default cur

Currently, When the user changes the company currency with deactivating the default currency and try to install sale_ebay module he receives an exception at the backend.

To reproduce the issue:
1. Create a database without demo data.
2. Install invoicing module.
3. In Settings > Open Companies from Users&Companies menu.
4. Open My Company and change its currency from default to any other currency.
5. Go to Invoicing Settings > click on the currencies button and deactivate the default currency.
6. Now install sale_ebay module and the exception will occur at the backend side

See this exception:
```
Table "res_config_settings": unable to set NOT NULL on column "ebay_currency"
```

The above exception is occurring from -
https://github.com/odoo/odoo/blob/cf1004fdde71e55e06e6360489dadb0eb915377a/odoo/tools/sql.py#L207

To solve this issue the 'ebay_currency' field is set as a required field from XML side.


sentry-3933754992

Forward-Port-Of: odoo/enterprise#46831
Forward-Port-Of: odoo/enterprise#43820

This commit is a backport of https://github.com/odoo/enterprise/commit/191fd7ed65c0214dfe483dad8eb5be947961e0b9 A few internal systems are still running ubuntu 20.04 (focal) which ships with cryptography 2.8. The backend parameter was made optional (automatically falling back to the default backend) in 3.1. Provide a backend explicitly so the module can be updated without needing to upgrade the system (or install a non-distro package). Forward-Port-Of: odoo/enterprise#46816

This commit is a backport of https://github.com/odoo/enterprise/commit/191fd7ed65c0214dfe483dad8eb5be947961e0b9

A few internal systems are still running ubuntu 20.04 (focal) which ships with cryptography 2.8. The backend parameter was made optional (automatically falling back to the default backend) in 3.1.

Provide a backend explicitly so the module can be updated without needing to upgrade the system (or install a non-distro package).

Forward-Port-Of: odoo/enterprise#46816

This commit reduces the HTTP requests' overhead when passing through the fetch event in the ServiceWorker. In a nutshell, before this commit every request is attempted by the SW and only filtered out when the network request fails (to allow the fallback to the "offline" page). Now, it will first filter out the "navigation" request (cf. navigating from one url to another one) and handle the "offline" case for them, like before. But all other requests will just pass through the SW wi

This commit reduces the HTTP requests' overhead when passing through the
fetch event in the ServiceWorker.

In a nutshell, before this commit every request is attempted by the SW
and only filtered out when the network request fails (to allow the
fallback to the "offline" page).

Now, it will first filter out the "navigation" request (cf. navigating
from one url to another one) and handle the "offline" case for them,
like before.

But all other requests will just pass through the SW without being
touched.

Doing so, it avoids the overhead (around 2-6ms) of being handled and
forwarded instead just passing through.

Note: the /web/offline is now self-contained and avoids requesting an
additional resource (aka. the logo).

Forward-Port-Of: odoo/enterprise#46801