[IMP] Accounting: Set send by Peppol default instead of Send by email & Send by Peppol Set send by Peppol default instead of Send by email & Send by Peppol in sending the invoice Reason: To avoid sending the email twice unless the client wants that, He will still have the option to do so Task-3829627 Forward-Port-Of: odoo/odoo#160183

[IMP] Accounting: Set send by Peppol default instead of Send by email & Send by Peppol

Set send by Peppol default instead of Send by email & Send by Peppol in sending the invoice

Reason: To avoid sending the email twice unless the client wants that, He will still have the option to do so

Task-3829627

Forward-Port-Of: odoo/odoo#160183

Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#164610

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




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

Forward-Port-Of: odoo/odoo#164610

Have a numeric field in a form view. The displayed value is formatted, according to the thousands and decimal separators. Say the value is 1,240.00. If the user edits the input and types the same value, i.e. 1240, and then press "Enter", "Tab" or "Shift- Tab", the value won't be formatted as it should be, because we detect no change of value (which is true, but the value should be formatted anyway). With this commit, the value is always formatted on "Enter", "Tab" and "Shift-Tab". Issue sp

Have a numeric field in a form view. The displayed value is formatted, according to the thousands and decimal separators. Say the value is 1,240.00. If the user edits the input and types the same value, i.e. 1240, and then press "Enter", "Tab" or "Shift- Tab", the value won't be formatted as it should be, because we detect no change of value (which is true, but the value should be formatted anyway).

With this commit, the value is always formatted on "Enter", "Tab" and "Shift-Tab".

Issue spotted by fp

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




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

Forward-Port-Of: odoo/odoo#165112
Forward-Port-Of: odoo/odoo#164953

Currently when using _phone_format on any model without any country (on record or on company) the phone format calls is skipped. However if input is already a formatted number it works even without the country information. In this commit we now always call the format tool even when no country is found. It means the returned value might change in some cases (i.e. no country -> was returning original number). However the method spec is that it should return the formatted number or False when no

Currently when using _phone_format on any model without any country (on record or on company) the phone format calls is skipped. However if input is already a formatted number it works even without the country information.

In this commit we now always call the format tool even when no country is found. It means the returned value might change in some cases (i.e. no country -> was returning original number). However the method spec is that it should return the formatted number or False when no formatting is possible.

Calls of _phone_format has been checked and they effectively generally do sanitized or original_number, meaning they expect the returned number to be False when the formatting is not possible. So there should not be any unwanted side effect.

Task-3918417
Runbot-64570

Forward-Port-Of: odoo/odoo#164884

__Current behavior before commit:__ If the `badge_image` field of the event isn't set, the badge div's style defaults to `background-image: url();`. When `wkhtmltopdf` interprets this, it attempts to fetch the background image from the website's base URL. Consequently, each time the badge PDF is generated, `wkhtmltopdf` accesses the website's homepage, inadvertently altering the `website_visitor` table. If the badge PDF creation is triggered by a request from the website, it will lead to a dead

__Current behavior before commit:__
If the `badge_image` field of the event isn't set, the badge div's style defaults to `background-image: url();`. When `wkhtmltopdf` interprets this, it attempts to fetch the background image from the website's base URL. Consequently, each time the badge PDF is generated, `wkhtmltopdf` accesses the website's homepage, inadvertently altering the `website_visitor` table. If the badge PDF creation is triggered by a request from the website, it will lead to a deadlock due to simultaneous transactions on the same `website_visitor` row.

__Description of the fix:__
Do not write the `background-image` instruction at all when `badge_image` is not set.

__Steps to reproduce the issue on runbot:__
- Install `website_event`
- Go to Email Templates > **Event: Registration Confirmation** > Settings
- Put `Badge` in **Dynamic Reports**
- Create a new Event and register to it on its website page

-> The registration loads forever and it's impossible to go on any other page on the website

opw-3884132

Forward-Port-Of: odoo/odoo#164566

Steps ----- 1. Have inventory installed. 2. Have a product belonging to a company with a branch. 3. Create a SO with this branch and add the product to it. 4. Confirm the SO. ** Invalid Operation : incompatible companies on records ** Issue ----- While it is possible to add a product from a parent company to a SO, we get an error when confirming the SO and creating the move because of https://github.com/odoo/odoo/blob/1b0dbb3645ad8b52c5260f1cbbc4f6bdee48461e/addons/stock/models/sto

Steps
-----
1. Have inventory installed.
2. Have a product belonging to a company with a branch.
3. Create a SO with this branch and add the product to it.
4. Confirm the SO.
** Invalid Operation : incompatible companies on records **

Issue
-----
While it is possible to add a product from a parent company to
a SO, we get an error when confirming the SO and creating the move because
of
https://github.com/odoo/odoo/blob/1b0dbb3645ad8b52c5260f1cbbc4f6bdee48461e/addons/stock/models/stock_move.py#L1358
As the product_id field of stock.move has check_company=True, we have
an inconsistency because we are using the default domain of
_check_company_domain which is just the company itself.
https://github.com/odoo/odoo/blob/3c7db87ade7e99eafb44228bd038fa39429fdabc/odoo/models.py#L3999-L4007

Fix
-----
We provide a new _check_company_domain to product.product.
https://github.com/odoo/odoo/commit/0479b2b59466ae1d6d74165345aa3a7dc5de24ed made changes to allow products
to be used by branches, in particular this security rule:
https://github.com/odoo/odoo/blob/5a801bc60209713a3ba5313debb4daa05c4e2405/addons/product/security/product_security.xml#L34-L38

**opw-3815736**

Forward-Port-Of: odoo/odoo#160899

Allow pos users to have the "internal note" button available even in non-restaurant shops. Task-ID: 3878947 **Before:** Internal note button is only for restaurant. <img width="1800" alt="Screenshot 2024-04-22 at 15 56 44" src="https://github.com/odoo/odoo/assets/3245568/b923a1f5-e7fe-4a8a-b624-c0c31135c4fb"> **After:** <img width="1800" alt="Screenshot 2024-04-22 at 15 55 28" src="https://github.com/odoo/odoo/assets/3245568/fc82f296-7598-46b7-bbe0-0eb199872515"> Forward-Port-Of:

Allow pos users to have the "internal note" button available even in non-restaurant shops.

Task-ID: 3878947

**Before:** Internal note button is only for restaurant.

<img width="1800" alt="Screenshot 2024-04-22 at 15 56 44" src="https://github.com/odoo/odoo/assets/3245568/b923a1f5-e7fe-4a8a-b624-c0c31135c4fb">

**After:**

<img width="1800" alt="Screenshot 2024-04-22 at 15 55 28" src="https://github.com/odoo/odoo/assets/3245568/fc82f296-7598-46b7-bbe0-0eb199872515">

Forward-Port-Of: odoo/odoo#162863

In the case of a generic page and its specific page: When the specific page change its URL, its view will still have the sam key as the generic page despite not being served on the same URL anymore and not really being the same ressource anymore. This is a bit weird conceptually. Indeed, the generic page is not shadowed by the specific one anymore. This is an issue because when going on the generic page and editing it, the save will actually "bug": it will not write on the generic view that

In the case of a generic page and its specific page: When the specific page change its URL, its view will still have the sam key as the generic page despite not being served on the same URL anymore and not really being the same ressource anymore. This is a bit weird conceptually.
Indeed, the generic page is not shadowed by the specific one anymore.

This is an issue because when going on the generic page and editing it, the save will actually "bug": it will not write on the generic view that you edited but the save will instead be "redirected" (through the COW mechanism) to the specific view.
The editor will look like it did not save your change, while in fact it actually erased, behind the scene, the specific page content and replaced it by the one you tried to save on the generic page. You really just lost your specific page content without knowing it.

This is a corner case of the COW mechanism and the holy grail rule of multi website (editing a website should only impact itself and not other websites): we serve both the generic content and its specific content on the website, which should never be possible except for this particular case of a view being linked to a page and the specific view's page having its URL changed.

Note that an apparently good solution would be to adapt the view key to reflect its new page URL (as when you create a new page), but it's not possible. We don't do that for a simple reason: the page view's key could be xpath'd. And it is even the case for the contactus page. Even if it is not a very legit flow to xpath a page view, because it makes (most of the time) that page not possible to edit, we have to support it.

Also note that a generic page is not something supposed to exist, even if we support it (and use it for /contactus), it's best to avoid it:
1. You can't do that through the UI unless going into debug mode
2. It does not make a lot of sense to share a whole page content on multiple websites, as it would duplicated content (bad for SEO).

Steps to reproduce:
- Go to /contactus and enter edit mode
- Change something like add "WEBSITE1" somewhere in the page
- Open the page properties and change the url from /contactus to /contactuswebsite1
- Go to /contactus, which will still be available and now show the generic page
- You will not see the "WEBSITE1" you added, which is what is expected as this is the generic page, the "WEBSITE1" is on the /contactuswebsite1 page
- Enter edit mode and add something, like "GENERIC", save
- The page will reload (as you saved) but your "GENERIC" will disappear, looking like it did not save your change
- Now go to /contactuswebsite1, you will see that the "WEBSITE1" word is gone, and the "GENERIC" word is there

On top of the following OPWs, the bug was also reported internally on discord.
opw-3760257
opw-3473923
task-3476840

Forward-Port-Of: odoo/odoo#163038
Forward-Port-Of: odoo/odoo#159297

Description of the issue/feature this PR addresses: After removing the text from a tag with data-oe-type 'text' or 'char', and then saving, you can no longer edit it. It is because when the text is removed and and field is saved it becomes empty and its not possible to put the cursor inside an empty tag. This PR fills such empty tags when loading the document. task-3858711 Forward-Port-Of: odoo/odoo#162426

Description of the issue/feature this PR addresses:

After removing the text from a tag with data-oe-type 'text' or 'char', and then saving, you can no longer edit it. It is because when the text is removed and and field is saved it becomes empty and its not possible to put the cursor inside an empty tag. This PR fills such empty tags when loading the document.

task-3858711

Forward-Port-Of: odoo/odoo#162426

Before this commit, when a user had many discuss chats pinned on the UI (i.e. in Discuss app Sidebar or in Messaging Menu), then the initial loading of Discuss could be very slow. This initial loading happens at page load in version 17.0. This happens because when inserting the pinned thread data, the inner-working of computed fields related to Thread models was taking a lot of time. This comes from poor coding in ensuring computed fields are registered once in a single `Record.insert()` t

Before this commit, when a user had many discuss chats pinned on the UI (i.e. in Discuss app Sidebar or in Messaging Menu), then the initial loading of Discuss could be very slow.

This initial loading happens at page load in version 17.0.

This happens because when inserting the pinned thread data, the inner-working of computed fields related to Thread models was taking a lot of time. This comes from poor coding in ensuring computed fields are registered once in a single `Record.insert()` transaction: this uses an array, so it had to be fully parse to check whether it was present.

This commit fixes the issue by using a `Set` instead of an array for the FC_QUEUE (the inner-queue of registered fields to compute), so that checking presence of field is an O(1) time rather than O(n). Note that arrays are fast so it needs a lot of threads and a lot of computed fields to see a big performance problem.

In version 17.0:

200 pinned threads: 600ms => 400ms (50% faster)
1k6 pinned threads: 8.85s => 5.25s (70% faster)

Forward-Port-Of: odoo/odoo#164977

### Before this commit: The fileViewer toolbar buttons displayed incorrect colors for portal users. ### Reason for this behaviour The mail module's public assets loaded all components and their SCSS files. However, the file viewer had a separate SCSS file for dark mode button colors, which was unnecessary for portal users. Removing it would help fix the bug. ### After this commit: FileViewer toolbar button colors now display correctly for portal users. **task-3872205** For

### Before this commit:
The fileViewer toolbar buttons displayed incorrect colors for 
portal users.

### Reason for this behaviour
The mail module's public assets loaded all components and 
their SCSS files. However, the file viewer had a separate SCSS 
file for dark mode button colors, which was unnecessary for 
portal users. Removing it would help fix the bug.

### After this commit:
FileViewer toolbar button colors now display correctly for portal 
users.

**task-3872205**

Forward-Port-Of: odoo/odoo#163933

Steps to reproduce: - Install purchase, project and accounting - Setup an analytic distribution for the projec - Add a new item from the catalogue Issues: The analytic distribution is not added automatically as it would when adding an item without using the catalogue. Solution: The compute that add the analytic distribution requires the `project_id` to be in the context. https://github.com/odoo/odoo/blob/ed0bf10ad89ee78acc65f4e7be70c7ffb2a864bb/addons/project_purchase/models/purc

Steps to reproduce:
- Install purchase, project and accounting
- Setup an analytic distribution for the projec
- Add a new item from the catalogue

Issues:
The analytic distribution is not added automatically as it would when
adding an item without using the catalogue.

Solution:
The compute that add the analytic distribution requires the `project_id`
to be in the context.

https://github.com/odoo/odoo/blob/ed0bf10ad89ee78acc65f4e7be70c7ffb2a864bb/addons/project_purchase/models/purchase_order_line.py#L13

However if we go to the catalogue and add the items our context will be
flushed, but this flush will be done with the old env.
By passing the context and using `_recompute_recordset` we are
forcing the compute with the env that has the correct context.

As a side note `_recompute_recordset` is used instead of
`flush_recordset` in order to prevent write operations that will be done
later on.

opw-3794948

Forward-Port-Of: odoo/odoo#158924

Steps to reproduce: ------------------- - create a new time off type (with approval and allocation) - create an accrual plan with 1 day (monthly on the 1 day of the month) - create two allocations with the type, one regular (X days) and one accrual (Y days) - take a time off of Z days with the condition: Z < X + Y - run `Time Off: Cancel invalid leaves` scheduled action Issue: ------ The time off is canceled with the following message: ``` The time off has been canceled: the accruat

Steps to reproduce:
-------------------
- create a new time off type (with approval and allocation)
- create an accrual plan with 1 day (monthly on the 1 day of the month)
- create two allocations with the type, one regular (X days) and one accrual (Y days)
- take a time off of Z days with the condition: Z < X + Y
- run `Time Off: Cancel invalid leaves` scheduled action

Issue:
------
The time off is canceled with the following message:
```
The time off has been canceled: the accruated amount is
insufficient for that duration.
```

Cause:
------
To delete the leave with the cron `_cancel_invalid_leaves`:

[A] The leave must be:
- between today and today + 31 days
- have at least an allocation of type `accrual`.

[B] We need an `exceeding_duration`:
`additional_leaves_duration > latest_remaining`
<=> `additional_leaves_duration > latest_remaining`
<=> `additional_leaves_duration > virtual_remaining - date_accrual_bonus + latest_accrual_bonus`
<=> `leave.number_of_days > virtual_remaining - date_accrual_bonus + latest_accrual_bonus`
<=> `leave.number_of_days > SUM_ALLOC(virtual_remaining_leaves) - SUM_ALLOC(accrual_bonus) + SUM_ALLOC(_get_future_leaves_on(leave.date_from))`
<=> `leave.number_of_days > SUM_ALLOC(virtual_remaining_leaves)` (simplify the use case)

As we have a regular allocation, the following logic will be used:
```py
leave_type_data[allocation]['virtual_remaining_leaves'] -= allocated_time
```

The result is that the condition cancelling the leave will be respected when it should not.

Solution:
---------
Move the logical block which adds the leave to `to_recheck_leaves` if an `accrual` type allocation is detected,
so as not to make changes with regular allocations.

opw-3869889

Forward-Port-Of: odoo/odoo#164556

Description of the issue/feature this PR addresses: It is not necessary to put the UY- at the beginning because they only appear if the country is Uruguay Task: 88 Task in adhoc: 6022 Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#164352

Description of the issue/feature this PR addresses:
It is not necessary to put the UY- at the beginning because they only appear if the country is Uruguay
Task: 88
Task in adhoc: 6022

Current behavior before PR:

Desired behavior after PR is merged:




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

Forward-Port-Of: odoo/odoo#164352

Prior to this commit, enabling the multi-employee option without any employees in the database would result in no action upon selecting cashier. This could lead to confusion. With this commit, an error message is displayed in such scenarios, enhancing user feedback and preventing confusion. opw-3851823 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#160646

Prior to this commit, enabling the multi-employee option without any employees in the database would result in no action upon selecting cashier. This could lead to confusion. With this commit, an error message is displayed in such scenarios, enhancing user feedback and preventing confusion.

opw-3851823

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

Forward-Port-Of: odoo/odoo#160646

**Current behaviour before commit:** In website when cropper is open, pressing ESC key hides side panel. **Desired behaviour after commit:** Now, pressing ESC works same as discard button. It closes the cropper and prevents hiding side panel. task-3787411 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#158543

**Current behaviour before commit:**

In website when cropper is open, pressing ESC key
hides side panel.

**Desired behaviour after commit:**

Now, pressing ESC works same as discard button. It closes
the cropper and prevents hiding side panel.

task-3787411



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

Forward-Port-Of: odoo/odoo#158543

Versions: ------------ 16.0 Steps to reproduce: ------------------- 1)Update the email field of users with gmail id for admin and demo 2) Connect odoo with google calendar 3) Create a recurring event with admin as Organizer, demo as attendee and recurrence as "Daily" with "1" repeatation. 4) Then edit the event by changing the repeatation as "2" and save it in "This and following event" 5) Check the event duplication Issue: ------- Recurring events in the calendar are being duplic

Versions:
------------
16.0

Steps to reproduce:
-------------------
1)Update the email field of users with gmail id for admin and demo 2) Connect odoo with google calendar
3) Create a recurring event with admin as Organizer, demo as attendee and recurrence as "Daily" with "1" repeatation.
4) Then edit the event by changing the repeatation as "2" and save it in "This and following event"
5) Check the event duplication

Issue:
-------
Recurring events in the calendar are being duplicated.

Cause:
------
The `_apply_recurrence_values` method is being called twice, resulting in duplicate events.

Solution:
---------
Added a condition to prevent the method from being called multiple times.

task-3786429

Forward-Port-Of: odoo/odoo#160062

[IMP] account_online_synchronization: populate swift/bic in journals Swift_code/BIC is already being returned by bank connection with odoofin accounts api We already populate the rest of the journals' details. So, We populate the swift/bic and link it with the journals Reason: Improve the user-experience Task-3891695 odoofin-pr: https://github.com/odoo/odoofin/pull/273 Forward-Port-Of: odoo/enterprise#61639

[IMP] account_online_synchronization: populate swift/bic in journals

Swift_code/BIC is already being returned by bank connection with odoofin accounts api We already populate the rest of the journals' details. So, We populate the swift/bic and link it with the journals

Reason: Improve the user-experience

Task-3891695

odoofin-pr: https://github.com/odoo/odoofin/pull/273

Forward-Port-Of: odoo/enterprise#61639

That field is not required, so it is possible to make it empty. The behavior should then be equivalent to the 'disabled' option. Before this fix, it wasn't, and instead restrained the considered accounts to payable and receivable accounts. We'll make it required in master. Forward-Port-Of: odoo/enterprise#60847

That field is not required, so it is possible to make it empty. The behavior should then be equivalent to the 'disabled' option. Before this fix, it wasn't, and instead restrained the considered accounts to payable and receivable accounts.

We'll make it required in master.

Forward-Port-Of: odoo/enterprise#60847

When typing in the softphone's search bar, the search result doesn't appear immediately; the user has to press Enter to make it happen. This is because the input field uses the t-model directive with the trim modifier. The trim modifier silently switches the directive to lazy mode, meaning that the content of the field is updated whenever the onchange event is fired instead of oninput. This commit removes the trim modifier to fix the problem. opw-3890028 Forward-Port-Of: odoo/enterprise#6

When typing in the softphone's search bar, the search result doesn't appear immediately; the user has to press Enter to make it happen. This is because the input field uses the t-model directive with the trim modifier. The trim modifier silently switches the directive to lazy mode, meaning that the content of the field is updated whenever the onchange event is fired instead of oninput.

This commit removes the trim modifier to fix the problem.

opw-3890028

Forward-Port-Of: odoo/enterprise#62125

Before this PR, the sign_request record was browsed but we did not checked if the record was correct. Before this PR, when the sign_document_from_mail controller was called without timestamp parameter, it would redirect to the sign.sign_request_expired template because current_request_item._validate_expiry(post.get('timestamp'), post.get('exp')) would return False. For human triggered interaction, it is not an issue. Some customer complained of massive email sent. One of the signer

Before this PR, the sign_request record was browsed but we did not checked if the record was correct.

Before this PR, when the sign_document_from_mail controller was
called without timestamp parameter, it would redirect to the
sign.sign_request_expired template because
current_request_item._validate_expiry(post.get('timestamp'),
post.get('exp')) would return False.

For human triggered interaction, it is not an issue.

Some customer complained of massive email sent. One of the signer is
probably relying on MS Defender. This is system is known to click on
links in email and cleaning the GET parameters of the URL.

In that case, the bot will get the sign.sign_request_expired which has a
button that allows to resend the sign request. If the bot click on that
button, it will send an email, that will be analyzed by the bot. it will
clean the parameters, get the sign.sign_request_expired template etc
etc.

Forward-Port-Of: odoo/enterprise#61853

Before this commit, when having opposite tax grid the domain of the journal_report_tax_tag_template_open_aml function was wrong. In case of opposite tax grid we should have put a list of tax_grid in the tag_id key which wasn't the case. It was only taking the last one since it was overridden in the next iteration of the loop. task-3869482 Forward-Port-Of: odoo/enterprise#62327 Forward-Port-Of: odoo/enterprise#61302

Before this commit, when having opposite tax grid the domain of the journal_report_tax_tag_template_open_aml function was wrong.

In case of opposite tax grid we should have put a list of tax_grid in the tag_id key which wasn't the case. It was only taking the last one since it was overridden in the next iteration of the loop.

task-3869482

Forward-Port-Of: odoo/enterprise#62327
Forward-Port-Of: odoo/enterprise#61302

When sending a negative amount of stock, Amazon can't process the inventory update availibility feed. opw-3905455 Forward-Port-Of: odoo/enterprise#62185

When sending a negative amount of stock, Amazon can't process the inventory update availibility feed.

opw-3905455

Forward-Port-Of: odoo/enterprise#62185

Reproducing: 1. Use a folder with one `binary` and one `url`-type documents. 2. Add a tag on the `binary` one. 3. Check the tag in the search panel 4. Share the folder Problem: You are warned about having included a link in the share, but you had not. Note that this domain is not the one used to identify the records that will be included in the share (stored in `domain`). Task-3806121 Forward-Port-Of: odoo/enterprise#58650

Reproducing:
1. Use a folder with one `binary` and one `url`-type documents.
2. Add a tag on the `binary` one.
3. Check the tag in the search panel
4. Share the folder

Problem:
You are warned about having included a link in the share, but you had not.

Note that this domain is not the one used to identify the records that will be included in the share (stored in `domain`).

Task-3806121

Forward-Port-Of: odoo/enterprise#58650