Server-side form handling has been improved and related accounting, field service, manufacturing, and test flows were updated to work correctly with the change. This reduces the risk of errors in automated business processes and helps keep key workflows stable.

Companion of https://github.com/odoo/odoo/pull/116779.

Activity information now stays synchronized when users work with Odoo in multiple browser tabs. This helps teams avoid seeing outdated activity data and reduces confusion when switching between open tabs.

Community: https://github.com/odoo/odoo/pull/115986

Task-2714099.

Project budget items now open directly in their detailed form view from the budget section. This makes it easier for users to review and update budget information without extra navigation steps.

Purpose of this commit is to improve the generic usage of the project app

So in this commit done the following changes:
- project updates -> budget section -> budget items restrict to open form view.

tas-3073860

Helpdesk rating emails are now only sent when there is a valid customer contact, avoiding inappropriate or unnecessary survey requests. Project budget panels now show how budgetary positions are distributed across multiple linked budgets, and planning views better surface relevant assigned users.

- Helpdesk rating:

\- the rating email template should not be sent if:
	> there is no partner set on the task
	> or if the current user is set as the partner of the task

- Group Expands (Gantt)

\- project.task gantt view:
display an empty line for each user who has an open task assigned in the project
(only applicable when viewing the tasks of a specific project)
\- project.task gantt view:
add the group_expand for the user_ids field -> display an empty line
for the users that were planned a task in the past 7 days

- Budget (Right Side Panel)

\- project.update right side panel > budgets section >
if a budgetary position is linked to multiple budgets
(that are linked to the AA of the project), indicate the distribution by budget

task-2924559
related: https://github.com/odoo/odoo/pull/96452

Planning-related product settings are now clearer by hiding or disabling options that do not apply to milestone or manual invoicing. When creating planning slots, role choices are ordered more helpfully so users see the resource’s own role first, followed by general roles.

In this commit improve the following generic UX

- in the product hide the plan services field when invoicing policy is on
   milestone or manual
- in the product disabled the plan services field when invoicing policy is on
   milestone or manual
- In planning while creating a slot when the resource is set and the user opens the
  dropdown to select a role for that resource shows roles in a sorted manner where
  the role set on the resource shows first and then all roles where no resource is set

task-3077554

Project-related screens are easier to use with better button ordering, cleaner timer controls, and less clutter in task planning views. Documents uploaded from projects or tasks can now automatically apply the relevant default tags, reducing manual tagging work.

** = timesheet_grid, helpdesk_timesheet, project_account_asset,
documents, documents_project. 

Purpose:
- Improve some generic UX of project app.

Specification:
- order stat buttons of project update right side panel according
  to user usage.
- hide project field for gantt view of 
  `act_project_project_2_project_task_all` action.
- remove title on hover of timer buttons from task and ticket form
  view.
- pass default tags from project and task document action and
   add that tags in selected tags.

task-3083855

Digest tip content was adjusted so it works correctly with the updated digest email templates. This keeps demonstration and guidance content consistent across accounting, documents, planning, and enterprise digest features.

In related community PR, the `digest_data` template has been changed
so the `digest_tips` is not compatible with the new changes.

This commit changes the `digest_tips` data template to be compatible
with the new changes.

Below are the modules affected:
 - account_accountant
 - digest_enterprise
 - documents
 - planning

task-2717426

Add the Estonian localization for accounting: * Balance Sheet * Income Statement Scheme 1 (Profit and Loss) * VAT Report Annex (KMD INF) * XML export for VAT Report (KMD), including KMD INF * EC Sales / IC Supply Report (VD) + XML export References: * BS and P/L: https://www.riigiteataja.ee/aktilisa/1281/2201/9017/RM_m65_lisa1.pdf# from https://www.riigiteataja.ee/akt/128122019017 * VAT Forms: https://www.emta.ee/ariklient/maksud-ja-tasumine/maksudeklaratsioonid-teabevahetus/kaibed

Add the Estonian localization for accounting:

* Balance Sheet
* Income Statement Scheme 1 (Profit and Loss)
* VAT Report Annex (KMD INF)
* XML export for VAT Report (KMD), including KMD INF
* EC Sales / IC Supply Report (VD) + XML export

References:

* BS and P/L: https://www.riigiteataja.ee/aktilisa/1281/2201/9017/RM_m65_lisa1.pdf# from https://www.riigiteataja.ee/akt/128122019017
* VAT Forms: https://www.emta.ee/ariklient/maksud-ja-tasumine/maksudeklaratsioonid-teabevahetus/kaibedeklaratsioon-vd-ja-vdp
* KMD INF: https://www.emta.ee/media/2206/download
* VD: https://www.emta.ee/media/791/download
* XML formats: https://www.emta.ee/ariklient/e-teenused-koolitused/e-teenuste-kasutamine/teenuste-tehniline-info#kaibedeklaratsioon

[task-2985062](https://www.odoo.com/web#id=2985062&cids=1&menu_id=4720&action=333&active_id=967&model=project.task&view_type=form)

Related to https://github.com/odoo/odoo/pull/106767

Forward-Port-Of: odoo/enterprise#38927
Forward-Port-Of: odoo/enterprise#34487

Fixes an issue with the reports when opening them on mobile (more specifically, ipad air). The report width isn't correct at this time. By adding a computed width in the class, we keep the current behaviour in desktop/wide screen but also allow the report to take the whole width in smaller screen. Task id # 3249004 Forward-Port-Of: odoo/enterprise#38856

Fixes an issue with the reports when opening them
on mobile (more specifically, ipad air).
The report width isn't correct at this time.

By adding a computed width in the class, we keep
the current behaviour in desktop/wide screen but
also allow the report to take the whole width in
smaller screen.

Task id # 3249004

Forward-Port-Of: odoo/enterprise#38856

[FIX] account_reports: Generic tax report and its variants: compute archived tag warning more efficiently The option key 'contains_archived_tag' is used to display a warning banner on top of the report in case some move line in the period is using an archived tag. Its computation was done with a search on account.move.line with limit=1. Though it worked, the query generated for this case by the ORM was very inefficient, and slowed down the opening of the report a lot. This was especially t

[FIX] account_reports: Generic tax report and its variants: compute archived tag warning more efficiently

The option key 'contains_archived_tag' is used to display a warning banner on top of the report in case some move line in the period is using an archived tag. Its computation was done with a search on account.move.line with limit=1. Though it worked, the query generated for this case by the ORM was very inefficient, and slowed down the opening of the report a lot.

This was especially true when opening a variant automatically, since the menu item called _get_report_informations on the root report, which called _get_options (which ran the search a first time), then re-called _get_report_informations on the variant, which did a final call to _get_options (running the search a second time). The computation of warnings will be optimized in the future, so that we don't run it twice anymore. For now, we make sure this one runs fast.


[FIX] account_reports: wrong action when trying to audit the move lines with an archived tag from warning message

Forward-Port-Of: odoo/enterprise#38984
Forward-Port-Of: odoo/enterprise#38504

This commit fixes a styling bug that was corrected in https://github.com/odoo/enterprise/commit/24aad7b666a398ea9e78f4dbf26eba9715f47332 where readonly articles would have more padding than editable ones. Since the OWLification of the knowledge icon to a field widget, when the field is empty the class `o_field_empty` is added to the element and this class some height to it. This style would be taken into account when the article would be readonly. To fix this we added a css rule that set

This commit fixes a styling bug that was corrected in https://github.com/odoo/enterprise/commit/24aad7b666a398ea9e78f4dbf26eba9715f47332
where readonly articles would have more padding than editable ones.

Since the OWLification of the knowledge icon to a field widget, when the field
is empty the class `o_field_empty` is added to the element and this class some
height to it.
This style would be taken into account when the article would be readonly.
To fix this we added a css rule that sets a min-height of 0px when the icon
field is empty, removing the unnecessary paddding inside knowledge.

task-3245853

Forward-Port-Of: odoo/enterprise#38633

Automated actions allows to trigger an action based on date, e.g. "2 days after sale order creation". To make it more useful, Odoo allows to count work days only. And we could even use work days of specific user, e.g. Salesperson of the sale order. It turns out, such use case didn't work last 5 years since renamings in `resource` module [1]. STEPS: 1. Make an Automated Action with the following configuration: * Trigger Condition: Based on Timed Condition * Delay after trigger date: 1

Automated actions allows to trigger an action based on date, e.g. "2 days after sale order creation". To make it more useful, Odoo allows to count work days only. And we could even use work days of specific user, e.g. Salesperson of the sale order.

It turns out, such use case didn't work last 5 years since renamings in `resource` module [1].

STEPS:

1. Make an Automated Action with the following configuration:
* Trigger Condition: Based on Timed Condition
* Delay after trigger date: 1 Days
* Set values for `trg_date_resource_field_id` (Use employee work schedule) and `trg_date_calendar_id` (Use Calendar)
2. Be sure that there are sale orders that have employee with active contract
3. Run Scheduled action *Base Action Rule: check and execute*

BEFORE the patch you see the following error:

> "'resource.calendar' object has no attribute 'schedule_days_get_date'"

Fix it by using correct method name.

Also, this patch deletes a check for `action.trg_date_calendar_id`, which looks as copy-paste from original `_check_delay` method, while it's not used in the inherited implementation.

Note. This patch doesn't restore original behavior completly, because support for `resource_id` parameter (i.e. filtering days by employee's leaves) was dropped 4 years ago [2]. We may restore this feature in master if needed. As for now, the features seems unused anyway (nobody noticed the error for 5 years).

[1]: https://github.com/odoo/odoo/commit/be01aaa99ff3ad32b757dd0a61a437dac19fc2c9 [2]: https://github.com/odoo/odoo/commit/975c6c8639b3e62d8f63022e94f7ddb006bd9e2f

opw-2856817

Forward-Port-Of: odoo/enterprise#36669

Steps to reproduce ------------------ 1. Install and open the Timesheets app. 2. Click on the "Start" button on the top left. 3. Click on "Select a Task" and then on "Search More..." to open the list view. 4. The associated search view is not the same as in the Project app. Explanation ----------- This occurs because the selected search view will be the one related to the model with the lowest priority. Since we didn't define a priority for any of the views, the view `view_task_search_

Steps to reproduce
------------------
1. Install and open the Timesheets app.
2. Click on the "Start" button on the top left.
3. Click on "Select a Task" and then on "Search More..." to open the list view.
4. The associated search view is not the same as in the Project app.

Explanation
-----------
This occurs because the selected search view will be the one related to the model with the lowest priority. Since we didn't define a priority for any of the views, the view `view_task_search_form_base` is the one with the lowest default priority. However, this is a base view created for inheritance purposes and not intended to actually be used anywhere.

To solve this issue, this commit adds a very high priority to the base views, and a low priority to the concrete views we want to be used in such cases.

Note that this unintended behavior is also present in versions below 16.1, but in a non problematic way (only the project related filters are missing).

---

Community: https://github.com/odoo/odoo/pull/114422

Task-3217905

Forward-Port-Of: odoo/enterprise#37812

Steps: - Apply filter Shifts In Conflict - Open a shift that has conflicted shifts - Click on the link in the warning - Resource is filtered by default twice. Fix: Resource is already entered in parent view so removed here Issue arrived from this commit-https://github.com/odoo/enterprise/commit/5dfa9b88b763de5700a4a34f68b0ce582b413ae4 task-3198515 Forward-Port-Of: odoo/enterprise#37527

Steps:
- Apply filter Shifts In Conflict
- Open a shift that has conflicted shifts
- Click on the link in the warning 
- Resource is filtered by default twice.

Fix:
Resource is already entered in parent view so removed here

Issue arrived from this commit-https://github.com/odoo/enterprise/commit/5dfa9b88b763de5700a4a34f68b0ce582b413ae4
task-3198515

Forward-Port-Of: odoo/enterprise#37527

This commit fix issues that disallow the client to renew and set a payment token when the subscription is marked as 'To renew'. It also fix an issue with the chatter message in case of manual payment throught the portal. task-id : 3129353 Forward-Port-Of: odoo/enterprise#38646 Forward-Port-Of: odoo/enterprise#36346

This commit fix issues that disallow the client to renew and set a payment token when the subscription is marked as 'To renew'.

It also fix an issue with the chatter message in case of manual payment throught the portal.

task-id : 3129353

Forward-Port-Of: odoo/enterprise#38646
Forward-Port-Of: odoo/enterprise#36346

Invoice in subscription are mostly generated by OdooBot, this thus doesn't add the salesperson as a follower on the invoice. We don't want the salesperson to be a follower on every invoice as he would just be spammed by notification if everything goes according to plan. However if the client post on the chatter we still want the salesperson to be notified. This PR add the salesperson as recipient of any non notification written on the chatter, meaning that the salesperson receive a notific

Invoice in subscription are mostly generated by OdooBot, this thus doesn't add the salesperson as a follower on the invoice.

We don't want the salesperson to be a follower on every invoice as he would just be spammed by notification if everything goes according to plan. However if the client post on the chatter we still want the salesperson to be notified.

This PR add the salesperson as recipient of any non notification written on the chatter, meaning that the salesperson receive a notification or mail depending on it's notification preference set in Odoo.

task-id : 3084135

Forward-Port-Of: odoo/enterprise#38889
Forward-Port-Of: odoo/enterprise#37390

`lb` translation file is created manually. Some terms are obsolete and lead to an error. For example field `acquirer_id` is renamed to `provider_id` ``` -" % set company = object.acquirer_id.company_id\n" -" <span style=\"font-size: 10px;\">Your SEPA Direct Debit Transaction</span><br/>\n" -" <span style=\"font-size: 20px; font-weight: bold;\">${object.reference}</span>\n" +" <t t-set=\"company\" t-value=\"objec

`lb` translation file is created manually.
Some terms are obsolete and lead to an error. For example field `acquirer_id` is
renamed to `provider_id`

```
-"                    % set company = object.acquirer_id.company_id\n"
-"                    <span style=\"font-size: 10px;\">Your SEPA Direct Debit Transaction</span><br/>\n"
-"                    <span style=\"font-size: 20px; font-weight: bold;\">${object.reference}</span>\n"
+"                    <t t-set=\"company\" t-value=\"object.company_id\"/>\n"
+"                    <span style=\"font-size: 10px;\">Your SEPA Direct Debit "
+"Transaction</span><br/>\n"
+"                    <span style=\"font-size: 20px; font-weight: bold;\" t-"
```

Fix it by removing the file, because it has no translation anyway

https://online.sentry.io/issues/4021453801

Forward-Port-Of: odoo/enterprise#38806

Before this PR, sale_susbcription would crash if the groupby subscription_state was called on so with no subscription_state. ``` File "/data/build/enterprise/sale_subscription/models/sale_order.py", line 854, in read_group res = sorted(res, key=lambda r: r['subscription_state']) TypeError: '<' not supported between instances of 'bool' and 'str' ``` task id: 3244835 Forward-Port-Of: odoo/enterprise#38949

Before this PR, sale_susbcription would crash if the groupby subscription_state was called on so with no subscription_state.

```
  File "/data/build/enterprise/sale_subscription/models/sale_order.py", line 854, in read_group
    res = sorted(res, key=lambda r: r['subscription_state'])
TypeError: '<' not supported between instances of 'bool' and 'str'
```

task id: 3244835

Forward-Port-Of: odoo/enterprise#38949

Before this commit: Assuming we have a "Shipping Labels Printer" set on an operation type. Assuming we also have a delivery carrier which send Label through the chatter of this picking type (like DHL or BPost). If we have several sessions connected with the same user (author of the chatter message), for examples, on different devices. Each session will send the same IoT request to print the label (as the code rely on the bus). In consequences, the same label will be printed multiple times

Before this commit:
Assuming we have a "Shipping Labels Printer" set on an operation type. Assuming we also have a delivery carrier which send Label through the chatter of this picking type (like DHL or BPost). If we have several sessions connected with the same user (author of the chatter message), for examples, on different devices. Each session will send the same IoT request to print the label (as the code rely on the bus).

In consequences, the same label will be printed multiple times

After this commit:
The label is print only once

Associated community PR: https://github.com/odoo/odoo/pull/112355

opw-3081423

Forward-Port-Of: odoo/enterprise#38975
Forward-Port-Of: odoo/enterprise#36904

Steps: - create a shift for 2 days today and tomorrow - assign it to resource A - Now archive employee A - time zone issue split shifts Issue: time zone issue with the start/end hours in the split open shifts. Cause: The assigned departure date has been incorrectly allotted to the start/end dates without taking into account the time zone Fix: The start/end hours of the split shifts have been updated to take into consideration the working calendar. task-3168371 Forward-Port-O

Steps:
- create a shift for 2 days today and tomorrow
- assign it to resource A
- Now archive employee A
- time zone issue split shifts

Issue:
 time zone issue with the start/end hours in the split open shifts.

Cause:
The assigned departure date has been incorrectly allotted to the start/end dates without taking into account the time zone

Fix:
The start/end hours of the split shifts have been updated to take into consideration the working calendar.

task-3168371

Forward-Port-Of: odoo/enterprise#36659

Forward-Port-Of: odoo/enterprise#36990 Forward-Port-Of: odoo/enterprise#33834

Forward-Port-Of: odoo/enterprise#36990
Forward-Port-Of: odoo/enterprise#33834

If applied, this commit will solve the singleton error of the sign template when there are multiple responsible roles. Steps to produce: - Open any sign template where the multiple responsible roles are the same and the 'Share' button is visible. e.g. https://tinyurl.com/2mwy575q - Now change any of the responsible and click on the 'Share' button. e.g. https://tinyurl.com/2eodsvmu sentry - 4027176107 Forward-Port-Of: odoo/enterprise#38961

If applied, this commit will solve the singleton error of the sign template when there are multiple responsible roles.

Steps to produce:
- Open any sign template where the multiple responsible roles are the same and the 'Share' button is visible. e.g. https://tinyurl.com/2mwy575q
- Now change any of the responsible and click on the 'Share' button. e.g. https://tinyurl.com/2eodsvmu

sentry - 4027176107

Forward-Port-Of: odoo/enterprise#38961

## Current behaviour The COD (Cash on Delivery) payment method is used only for UPS normally, but you are able to checkout an order with another delivery method. ## Expected behaviour You shouldn't be able to checkout with COD if the delivery method is not UPS. ## Steps to reproduce - Install Ecommerce, UPS Delivery - Activate/Publish the COD payment provider and UPS delivery - Add a product on the e-shop and checkout - Select COD and another delivery method than UPS, you can checkou

## Current behaviour
The COD (Cash on Delivery) payment method is used only for UPS normally, but you are able to checkout an order with another delivery method.

## Expected behaviour
You shouldn't be able to checkout with COD if the delivery method is not UPS.

## Steps to reproduce
- Install Ecommerce, UPS Delivery
- Activate/Publish the COD payment provider and UPS delivery
- Add a product on the e-shop and checkout
- Select COD and another delivery method than UPS, you can checkout, when you shouldn't be able to.

## Reason for the problem
We don't handle the case in general.

## Fix
In the front-end, remove the COD payment option if we haven't selected
an UPS delivery method with `cash_on_delivery` activated.

## Affected versions
- 16.0
- saas-16.1
- master
---
opw-3130192

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

Forward-Port-Of: odoo/enterprise#38845
Forward-Port-Of: odoo/enterprise#37218

Unfolding all the lines by default when printing the report was a behavior shared by all reports in 16.0, but it slowed down the generation of the pdf a lot when the database became too big(because of the way the report engines unfolds all the line). This behavior is actually only really interesting when exporting the general ledger or depreciation schedule, as someone printing those generally wants a detailed view of their content (for audit, for example). We now only apply it for those repo

Unfolding all the lines by default when printing the report was a behavior shared by all reports in 16.0, but it slowed down the generation of the pdf a lot when the database became too big(because of the way the report engines unfolds all the line).

This behavior is actually only really interesting when exporting the general ledger or depreciation schedule, as someone printing those generally wants a detailed view of their content (for audit, for example). We now only apply it for those reports.

Other reports wanting to unfold all their lines when printing still are able to do so by simply enabling the "Unfold All" filter from the UI before clicking the print button. The only thing impacted by this commit is the default behavior.

OPW 3217603

Forward-Port-Of: odoo/enterprise#39019

We get logs as `error` on sentry if something does not go as expected in `_execute_followup_partner` This commit change exception type from `error` to `warning` while keeping exception info with `exc_info=True` to make debugging easier sentry-4025932035 Forward-Port-Of: odoo/enterprise#39042

We get logs as `error` on sentry if something does not go as expected in `_execute_followup_partner`

This commit change exception type from `error` to `warning` while keeping exception info with `exc_info=True` to make debugging easier

sentry-4025932035

Forward-Port-Of: odoo/enterprise#39042

**Steps to reproduce the bug:** - Install sale_temporal - Create and connect as a user with only administrator access to inventory - Try to create a product **Problem:** An access error is triggered: “You are not allowed to access 'Fields' (ir.model.fields) records.” **Solution:** An inventory admin should be able to create or duplicate a product without administrator access rights opw-3217945 Forward-Port-Of: odoo/enterprise#39045

**Steps to reproduce the bug:**
- Install sale_temporal
- Create and connect as a user with only administrator access to inventory
- Try to create a product

**Problem:**
An access error is triggered: “You are not allowed to access 'Fields' (ir.model.fields) records.”

**Solution:**
An inventory admin should be able to create or duplicate a product without administrator access rights

opw-3217945

Forward-Port-Of: odoo/enterprise#39045

Reading a QCP may trigger a useless write request on it. To reproduce the issue: (Use demo data) 1. Install `quality_mrp_workorder` 2. Enable debug mode 3. Open an existing Quality Control Point 4. Debug > View Metadata Error: the _Latest Modification Date_ is defined to now, but nothing did modify the QCP When opening the QCP, it leads to the compute method of `component_ids`. Here is the issue: in this method, we also write on the field `component_id`, which is a stored one. O

Reading a QCP may trigger a useless write request on it.

To reproduce the issue:
(Use demo data)
1. Install `quality_mrp_workorder`
2. Enable debug mode
3. Open an existing Quality Control Point
4. Debug > View Metadata

Error: the _Latest Modification Date_ is defined to now, but nothing
did modify the QCP

When opening the QCP, it leads to the compute method of
`component_ids`. Here is the issue: in this method, we also write on
the field `component_id`, which is a stored one. On ORM-side, it
will realize that the value is already defined to `False` and will
not write it again, but the writing process will already be started,
so an update of the last user and last modification date will still
be sent to the database. This point could be improved on ORM side
but, still, we should avoid writing something to a field while
computing another one (especially during a read request).

Initially, the reset of `component_id` has been added to an onchange,
so that we remove its value if the user changes the test type (see [1])

[1] https://github.com/odoo/enterprise/commit/ed37271dac04fe0d532e2888ced1f457fd35a2a0

OPW-3147450

Forward-Port-Of: odoo/enterprise#38992
Forward-Port-Of: odoo/enterprise#38720

# Current behaviour A portal user can change the date and time of the URL before posting the form to take an appointment, forcing the site to book an appointment outside of the specified time slots of the employee who's booked. # Expected behaviour Even if a user act smarts and changes the URLs parameters, the backend shouldn't validate such invalid appointment. # Steps to reproduce - Install Website and Appointments - Go to the front-end of an appointment of your choice - Click on a

# Current behaviour
A portal user can change the date and time of the URL before posting the form to take an appointment, forcing the site to book an appointment outside of the specified time slots of the employee who's booked.

# Expected behaviour
Even if a user act smarts and changes the URLs parameters, the backend shouldn't validate such invalid appointment.

# Steps to reproduce
- Install Website and Appointments
- Go to the front-end of an appointment of your choice
- Click on a slot, edit the hour in the URL for example to 23h00
- Press Enter to load the page with the new URL
- Post the form
- Observe that we've booked an appointment for 23h00, shouldn't be possible

# Reason for the problem
There is not backend validation in the controller that the start and end date of an appointment are actual valid slots. We were supposing they were correct because the date intervals comes from the previous page whose dates were generated with the available slots in mind.

# Fix
Add a validation in the controller to check if the dates are indeed viable slots. Cons is that the slots need to be regenerated once more, which may have a small impact on performance. An eventual future improvement maybe to cache the slots on the session to keep them between page loads if the performance becomes a problem.

# Affected versions
- 14.0
- 15.0
- saas-15.2
- saas-15.3
- 16.0
- master
---
opw-3080297

Forward-Port-Of: odoo/enterprise#38962
Forward-Port-Of: odoo/enterprise#34704

Forward-Port-Of: odoo/enterprise#38380

Forward-Port-Of: odoo/enterprise#38380

Before this commit, when a renewal was done in a currency different than the parent order, the transfer MRR was wrong. The transfered amount was: ``` self.subscription_id.recurring_monthly - self.recurring_monthly ``` As a result, the MRR transfer of the renewal was wrong. taskid: 3251199 Forward-Port-Of: odoo/enterprise#39026 Forward-Port-Of: odoo/enterprise#38894

Before this commit, when a renewal was done in a currency different than the parent order, the transfer MRR was wrong. The transfered amount was:
```
self.subscription_id.recurring_monthly - self.recurring_monthly

```
As a result, the MRR transfer of the renewal was wrong.

taskid: 3251199

Forward-Port-Of: odoo/enterprise#39026
Forward-Port-Of: odoo/enterprise#38894

The appointment invitation links have two issues: First, before this fix, we used the latest meeting created and checked that it was not ending more than three months ago, which seems arbitrary and random. If it was, then we deleted the whole appointment invite record in the garbage collector. Now we make sure that we take the latest stop value of linked meetings. Also, (Internal need) 3 months is too little in practice as many salespeople see their link expire in signature. To keep the n

The appointment invitation links have two issues:
First, before this fix, we used the latest meeting created and checked that it was not ending more than three months ago, which seems arbitrary and random.

If it was, then we deleted the whole appointment invite record in the garbage collector. Now we make sure that we take the latest stop value of linked meetings.

Also, (Internal need) 3 months is too little in practice as many salespeople see their link expire in signature. To keep the number of links under control, we still keep a limit, but increase it to 6 months.

A test is added to ensure that we only remove invitations (older than 6 months old) having their latest meeting ending older than 6 months old.

Task-3241362

Forward-Port-Of: odoo/enterprise#38619

Impacted versions: 16.0+ How to reproduce: - set a language other than English in Odoo (i.e. French) - open an article in Knowledge - create a /template block (/modèle) - create a /table block (/tableau) - write the /template command inside the template content - write the /template command inside a cell of the table Current behavior: - the command is available Expected behavior: - the command should not be available Fix: Knowledge commands were filtered based on a translat

Impacted versions:
16.0+

How to reproduce:
- set a language other than English in Odoo (i.e. French)
- open an article in Knowledge
- create a /template block (/modèle)
- create a /table block (/tableau)
- write the /template command inside the template content
- write the /template command inside a cell of the table

Current behavior:
- the command is available

Expected behavior:
- the command should not be available

Fix:
Knowledge commands were filtered based on a translatable value
(`command.category`). This commit uses the `isDisabled` feature of PowerBox
commands to enable/disable commands based on the cursor position, without
needing to rely on the name or the category of the command.

Instead of filtering commands under `o_knowledge_content`, use the more generic
`o_knowledge_behavior_anchor` to cover more cases without forcing the usage of
the `o_knowledge_content` class on any editable content of a Behavior.

Task-3247197

Forward-Port-Of: odoo/enterprise#39022
Forward-Port-Of: odoo/enterprise#38701