Unecessary info is fetched with the route hr_attendance/attendance_user_data such as employee avatar and other kiosk related data which is not necessary for the systray. task-4036988 Forward-Port-Of: odoo/odoo#172069

Unecessary info is fetched with the route hr_attendance/attendance_user_data such as employee avatar and other kiosk related data which is not necessary for the systray.

task-4036988

Forward-Port-Of: odoo/odoo#172069

Before this commit, the session report was displaying a useless line "Number of discount". It was useless as it was a duplicate. This commit removes it. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#172054

Before this commit, the session report was displaying a useless line "Number of discount". It was useless as it was a duplicate. This commit removes it.

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

Forward-Port-Of: odoo/odoo#172054

### [FIX] calendar: public user no attachment When public user will create an appointment, the attachments attached to the related mail template will filtered out by a `_process_attachments_for_post` method (ref.1) I happens because attachment's `res_model` is not set to `mail.compose.message`. Instead it's set to `mail.template` also `create_uid` isn't set to public user, but to the user creating the template). With this commit attachments will get copied on send with corrected `res_mode

### [FIX] calendar: public user no attachment
When public user will create an appointment, the attachments
attached to the related mail template will filtered out by
a `_process_attachments_for_post` method (ref.1)
I happens because attachment's `res_model` is not set to `mail.compose.message`.
Instead it's set to `mail.template` also `create_uid` isn't set to public user,
but to the user creating the template). With this commit attachments will
get copied on send with corrected `res_model`.

### [Reproduce]
- Install modules: appointment,website
- Add an attachment A to email templates: (in Settings/Email_Templates):
	- "Appointment Booked"
- On Website/Appointment: book an appointment (from an incognito window)
- BUG: no attachments are added to the emails (Settings/ Technical/ Email/ Emails)
	- no .ics attachment
	- no A attachment

(ref.1)
https://github.com/odoo/odoo/blob/312b0365e26e1578c5995d55f357b8aec14e5a5b/addons/mail/models/mail_thread.py#L2207C1-L2210

opw-[3685871](https://www.odoo.com/web#id=3685871&view_type=form&model=project.task)

Forward-Port-Of: odoo/odoo#160518

Before this commit, loading the POS took a long time when there were more than 1000 products and pricelists. The reason was that the `computeProductPricelistCache` function had a time complexity of O(n^2 * m) due to nested loops over products and pricelist items, and several calls to the raw function which is O(n) itself. This commit optimizes the `computeProductPricelistCache` function by performing a single loop over pricelist items and another over products. This change improves the loadin

Before this commit, loading the POS took a long time when there were more than 1000 products and pricelists. The reason was that the `computeProductPricelistCache` function had a time complexity of O(n^2 * m) due to nested loops over products and pricelist items, and several calls to the raw function which is O(n) itself.

This commit optimizes the `computeProductPricelistCache` function by performing a single loop over pricelist items and another over products. This change improves the loading speed from 10 minutes to 10 seconds with 1000 products and pricelist items.

opw-3978067

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

Forward-Port-Of: odoo/odoo#168466

Steps to reproduce the bug: - Create a storable product “P1” - Create a delivery for P1 - Click on “Detailed operation” smart button - select the move line - click on “put in pack” Problem: Nothing happens because the `put_in_pack` function of the 'stock.move.line' model always returns true after calling the same function of the 'stock.picking' model instead of returning the result. Note that this function cannot handle multiple move lines with different pickings. opw-4029393 For

Steps to reproduce the bug:
- Create a storable product “P1”
- Create a delivery for P1
- Click on “Detailed operation” smart button
- select the move line
- click on “put in pack”

Problem:
Nothing happens because the `put_in_pack` function of the 'stock.move.line' model always returns true after calling the same function of the 'stock.picking' model instead of returning the result.

Note that this function cannot handle multiple move lines with different pickings.

opw-4029393

Forward-Port-Of: odoo/odoo#172235
Forward-Port-Of: odoo/odoo#172068

With commit [1], we removed the method ``_get_bus_channel_name``, but at line [2], it's still referenced, which causes an error. AttributeError: ``'pos.session' object has no attribute '_get_bus_channel_name'`` This commit will fix the issue by using ``_notify`` for calling the notification bus. [1]-https://github.com/odoo/odoo/commit/3836aad466c6c111f0f0d33c357a1c7a5150f3fd [2]-https://github.com/odoo/odoo/blob/5633d590decc6e8989c0f454a355e965f072f967/addons/pos_viva_wallet/models/

With commit [1], we removed the method ``_get_bus_channel_name``, but at
line [2], it's still referenced, which causes an error.

AttributeError:
``'pos.session' object has no attribute '_get_bus_channel_name'``

This commit will fix the issue by using ``_notify`` for calling the notification
bus.

[1]-https://github.com/odoo/odoo/commit/3836aad466c6c111f0f0d33c357a1c7a5150f3fd
[2]-https://github.com/odoo/odoo/blob/5633d590decc6e8989c0f454a355e965f072f967/addons/pos_viva_wallet/models/pos_payment_method.py#L133

sentry-5562979975

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

Forward-Port-Of: odoo/odoo#171574

[FIX] l10n_es_edi_facutrae: fix TotalGrossAmount and new fields - The tag TotalGrossAmount should be the sum of the GrossAmount tag which is calculated as (price - discount + charge). Currently, the TotalGrossAmount is calculated as the sum of the price before subtracting the discount and adding the charge. - Add new fields to the XML. - Remove fields for total general discounts and charges as they were computed incorrectly. task-4001821 Forward-Port-Of: odoo/odoo#171435 For

[FIX] l10n_es_edi_facutrae: fix TotalGrossAmount and new fields

- The tag TotalGrossAmount should be the sum of the GrossAmount tag
  which is calculated as (price - discount + charge).
  Currently, the TotalGrossAmount is calculated as the sum of the price
  before subtracting the discount and adding the charge.
- Add new fields to the XML.
- Remove fields for total general discounts and charges as they were
  computed incorrectly.

task-4001821

Forward-Port-Of: odoo/odoo#171435
Forward-Port-Of: odoo/odoo#170176

Currently, when using the customer display feature with a display connected to an IoT box, the background image is not used. Instead the placeholder image is used. Steps to reproduce: ------------------- * Install and configure an IoT box * Go to **Point of Sale** * Select the Shop, edit it * Check `IoT Box` * Configure `Customer Display` * Now go to the settings of the Shop * Enable `Customer Display` if not already done previously * Upload a background image, save * Open the Shop

Currently, when using the customer display feature with a display connected to an IoT box, the background image is not used. Instead the placeholder image is used.

Steps to reproduce:
-------------------
* Install and configure an IoT box
* Go to **Point of Sale**
* Select the Shop, edit it
* Check `IoT Box`
* Configure `Customer Display`
* Now go to the settings of the Shop
* Enable `Customer Display` if not already done previously
* Upload a background image, save
* Open the Shop session
* Select the customer display

> Observation: The background image is not shown.

Why the fix:
------------
When using the customer display feature with the IoT box, the request is done with a Public User:
https://github.com/odoo/odoo/blob/f7e3ada5ed290a6f418e4e1a2abddfb9f242270c/addons/web/controllers/binary.py#L171-L176

Since Public Users don't have reading access on the `pos.config` model, access rights & rules are triggered:
https://github.com/odoo/odoo/blob/f7e3ada5ed290a6f418e4e1a2abddfb9f242270c/odoo/addons/base/models/ir_binary.py#L52-L58

Since we failed the try block, we end up loading the placehorder image by default:
https://github.com/odoo/odoo/blob/f7e3ada5ed290a6f418e4e1a2abddfb9f242270c/addons/web/controllers/binary.py#L185

We want the field `iface_customer_facing_display_background_image_1920` to be available to public user. In the case we are trying to access it with a public user, we make the request in sudo. Sudo environment stops existing once the request is made.

opw-3873765

Forward-Port-Of: odoo/odoo#171994
Forward-Port-Of: odoo/odoo#169808

In version 16.0, when a change is made to a record in an x2many field, saving it without saving the parent form and then accessing the record again and pressing discard will delete the changes previously made to the record. With these changes, the issue does not occur, and discarding returns the record to the state it was last saved in. Closing #171703 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: ---

In version 16.0, when a change is made to a record in an x2many field, saving it without saving the parent form and then accessing the record again and pressing discard will delete the changes previously made to the record.

With these changes, the issue does not occur, and discarding returns the record to the state it was last saved in.

Closing #171703

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#172289
Forward-Port-Of: odoo/odoo#172233

Serbian is a rare example of "synchronic digraphia", meaning that it has two writing systems that coexist and are used interchangeably by its speakers: Cyrillic and Latin. To handle this feature of Serbian in Odoo, we use a locale with a special modifier to specify the script to use: sr@latin. Problem: This locale is not recognized by the JavaScript APIs that implement the BCP 47 format, which leads to errors when trying to use them with the sr@latin locale. This PR provides a helper to

Serbian is a rare example of "synchronic digraphia", meaning that it has two writing systems that coexist and are used interchangeably by its speakers: Cyrillic and Latin.

To handle this feature of Serbian in Odoo, we use a locale with a special modifier to specify the script to use: sr@latin.

Problem: This locale is not recognized by the JavaScript APIs that implement the BCP 47 format, which leads to errors when trying to use them with the sr@latin locale.

This PR provides a helper to convert the locales from the Python side for use on the JavaScript side.

*: mail, payment_adyen, website

Enterprise: https://github.com/odoo/enterprise/pull/66287

Task-4014022

Forward-Port-Of: odoo/odoo#172261
Forward-Port-Of: odoo/odoo#171176

Romania requires its companies to send all invoices to a specific web service on their E-Factura platform. Now that we can generate the file (CIUS-RO XML), our next obvious step is to send them to their SPV (the ANAF platform). This commit implements 2 big part: - the full OAUTH/authentication process and its token generation - sending/fetching/downloading data to and from the SPV --- The Authentication To be able to generate the token needs a special USB key from Romania con

Romania requires its companies to send all invoices to a specific web
service on their E-Factura platform. Now that we can generate the file
(CIUS-RO XML), our next obvious step is to send them to their SPV (the
ANAF platform).

This commit implements 2 big part:

- the full OAUTH/authentication process and its token generation
- sending/fetching/downloading data to and from the SPV

---

The Authentication

To be able to generate the token needs a special USB key from Romania
connected with an ANAF account. The full process on what needs to be
done is explained in the settings view, in the "Romanian E-Factura"
block.

Once a token is generated, we'll be able to use it in all of our request
to send/fetch/download data to/from ANAF.

---

The Full Sending E-Factura Flow (requires access token)

- Upload invoice/credit note to SPV -> get "loading ID"
- The invoice gets processed by ANAF (State: "sending")
- After some time, fetch the invoice using the acquired loading ID.
- If processed, there will be 2 kind of answer: "OK" or "NOK" (not ok)
- Either way, we will get a "download ID", which we can then use to
  download the answer.
  - If "NOK" -> "Error". Read the zip file and display the error message
  - If "OK" -> "Sent". Save the zip file attachment

task-id: 3595436
related enterprise PR: https://github.com/odoo/enterprise/pull/65602

Forward-Port-Of: odoo/odoo#144061

Prior to this commit, the QR code size on some receipts was too small to be scanned effectively. opw-4008280 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#171503

Prior to this commit, the QR code size on some receipts was too small to be scanned effectively.

opw-4008280

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

Forward-Port-Of: odoo/odoo#171503

Issue: - when we have a shipping method that has a discount the shipping and the delivery prices are not displayed correctly (see attached screenshot). Steps To Reproduce: - configure the sale app to have the discount&loyalty and free shipping options enabled. - create a product that cost 100$. - create a new discount/loyalty where type is promotions and set rule to if minimum 300$ spent the reward is free shipping max to 75$. - create a shipping method based on rules where the deliv

Issue:

- when we have a shipping method that has a discount the shipping and the delivery prices are not displayed correctly (see attached screenshot).

Steps To Reproduce:

- configure the sale app to have the discount&loyalty and free shipping options enabled.
- create a product that cost 100$.
- create a new discount/loyalty where type is promotions and set rule to if minimum 300$ spent the reward is free shipping max to 75$.
- create a shipping method based on rules where the delivery product is a service that costs 100$.
- in your shipping mehtod pricing add a line with if quantity >= 3.0 then fixed price 100.0 and publish it.
- in your website shop select 3 items from the product you created. and select your delivery method.
- notice the prices not updating correctly.

Solution:
- Before the fix we always assumed that free_shipping_lines are
equal to 0.

- free_shipping_lines might be shipping discounts not actual free
shipping.so I adjusted update_eshop_carrier method to make it handle the
 case of discounted shipping.

opw-3718885


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

Forward-Port-Of: odoo/odoo#169138
Forward-Port-Of: odoo/odoo#154487

PR does 2 things: - First round of .po file cleaning for es_xx.po files. Since v17 started using es_419 instead of the es_xx.po files, these languages are no longer accessible on Transifex for the translators to change. These files were mostly out of date/incorrect anyways though, so we delete them. The one exception to this is the es_CL.po because Chile has some specific words that differ from the rest of LATAM. This cleanup will occur in a followup PR to give translators time to double chec

PR does 2 things:

- First round of .po file cleaning for es_xx.po files. Since v17 started using es_419 instead of the es_xx.po files, these languages are no longer accessible on Transifex for the translators to change. These files were mostly out of date/incorrect anyways though, so we delete them. The one exception to this is the es_CL.po because Chile has some specific words that differ from the rest of LATAM. This cleanup will occur in a followup PR to give translators time to double check if any of the translations in from these es_CL files should remain.
- Cleanup the en_AU/en_GB.po files. There were some non-sense "translations" in them and most of them didn't add much value. Some en_AU files had specific legitimate "translations" were left (e.g. tax "GST", check = cheque), so they were only modified to remove any erroneous translations

task: 3593077
ENT PR: https://github.com/odoo/enterprise/pull/65875
v17 PR: https://github.com/odoo/odoo/pull/170183

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

Forward-Port-Of: odoo/odoo#171979
Forward-Port-Of: odoo/odoo#171520

For some phone numbers, our SMS provider fails to send messages. In this case, manual verification can become necessary. This verification would be performed by support staff, and a change on the IAP side would allow for it (see https://github.com/odoo/iap-apps/pull/836). Considering this change, the client-side needs to be updated such that the participant state of unverified users is also checked and updated, by calling the participant status endpoint on the IAP. This is performed by upd

For some phone numbers, our SMS provider fails to send messages. In this case, manual verification can become necessary. This verification would be performed by support staff, and a change on the IAP side would allow for it (see https://github.com/odoo/iap-apps/pull/836).

Considering this change, the client-side needs to be updated such that the participant state of unverified users is also checked and updated, by calling the participant status endpoint on the IAP.

This is performed by updating the _cron_peppol_get_participant_status cron to include EDI users that are not yet verified.

When the user has been verified on the IAP side, the state 'verified' will be returned when making a call to the participant status endpoint, for which the most accurate mapping to a client state is 'pending'.

Note that when managing users from versions 17.0 to 17.2 (inclusive) the support staff responsible for verifying the user should also take the steps to ensure that they are registered on the SMP too (since users of these versions will otherwise remain in the 'pending' state indefinitely until they are manually registered on the SMP).

Forward-Port-Of: odoo/odoo#171823

To reproduce the bug, follow these instructions: - Change the company localization to France. - Install the Invoicing or Accounting app. - Check if the l10n_fr_account module is auto-installed. The module won't get installed because the auto-install dependencies are ['account', 'l10n_fr'], and l10n_fr does not have an auto-install dependency, so the l10n_fr_account module won't get installed. OPW-3898999 Forward-Port-Of: odoo/odoo#169087

To reproduce the bug, follow these instructions:
- Change the company localization to France.
- Install the Invoicing or Accounting app.
- Check if the l10n_fr_account module is auto-installed.

The module won't get installed because the auto-install dependencies are ['account', 'l10n_fr'], and l10n_fr does not have an auto-install dependency, so the l10n_fr_account module won't get installed.

OPW-3898999

Forward-Port-Of: odoo/odoo#169087

Following the changes introduced in https://github.com/odoo/odoo/commit/5a452e9baecb32d3a7de7b975841a1a981b20dcc, archived product template attribute values were not being loaded, leading to errors when loading paid orders. opw-4012873 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#171427

Following the changes introduced in https://github.com/odoo/odoo/commit/5a452e9baecb32d3a7de7b975841a1a981b20dcc, archived product template attribute values were not being loaded, leading to errors when loading paid orders.

opw-4012873

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

Forward-Port-Of: odoo/odoo#171427

Prior to this commit, orders loaded from other sessions did not load missing partners. opw-3981458 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#171128 Forward-Port-Of: odoo/odoo#169763

Prior to this commit, orders loaded from other sessions did not load missing partners.

opw-3981458

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

Forward-Port-Of: odoo/odoo#171128
Forward-Port-Of: odoo/odoo#169763

**Steps to reproduce the bug:** - Go to contact and select azure interior: - Sales & purchase tab: - Enable “Receipt Reminder” 1 day - Create a purchase order: - Select azure interior as vendor - add any storable product - Delivery date: Tomorrow - Confirm the PO - Go to the Scheduled Actions: Purchase reminder - Run it Manually - Come back to the Dashbord > Emails - Select the email for Azure interior: - Try to click on “YES” **Problem:** A tra

**Steps to reproduce the bug:**
- Go to contact and select azure interior:
    - Sales & purchase tab:
        - Enable “Receipt Reminder” 1 day

- Create a purchase order:
    - Select azure interior as vendor
    - add any storable product
    - Delivery date: Tomorrow

- Confirm the PO

- Go to the Scheduled Actions: Purchase reminder
- Run it Manually
- Come back to the Dashbord > Emails
- Select the email for Azure interior:
    - Try to click on “YES”

**Problem:**
A traceback is triggered: `AttributeError: type object 'datetime.datetime' has no attribute 'from_string'`

When the “YES” button is clicked, we retrieve the “confirmed_date” from the arguments as a string and then call the `confirm_reminder_mail` function https://github.com/odoo/odoo/blob/181c7d82e30d0848bbac7f7d0188e81aced0af07/addons/purchase/controllers/portal.py#L117

This date will be localized to the PO timezone using the `get_localized_date_planned` function: https://github.com/odoo/odoo/blob/a0be5ea52aeff3520f8f1a92206a5aad38fdaa82/addons/purchase/models/purchase.py#L823

We then get the timezone and use the `astimezone` function to transform this date, but since it is in string format, an error is triggered.

opw-4028362

Forward-Port-Of: odoo/odoo#172267

To reproduce the bug: - Go to Accounting app -> Customers -> Invoices - Click on an invoice or create a new one - Click on the Preview button - Chcek due in days. It has number after the decimal point. This was caused to a miss understanding of the toFixed function. The parameter of the function represent the numbers needed after the digit. And by default its value is 0. opw-3957112 Forward-Port-Of: odoo/odoo#169217

To reproduce the bug:
- Go to Accounting app -> Customers -> Invoices
- Click on an invoice or create a new one
- Click on the Preview button
- Chcek due in days. It has number after the decimal point.

This was caused to a miss understanding of the toFixed function. The parameter of the function represent the numbers needed after the digit. And by default its value is 0.

opw-3957112

Forward-Port-Of: odoo/odoo#169217

Version 17.0 steps to produce: - open 'hr_employees_view_kanban' in debug mode by searching in 'open view' - open hr attendance kanban view - click on kanban record - The method 'action_employee_kiosk_confirm' does not exist on the model 'hr.employee' issue: faced with a traceback cause: 'action_employee_kiosk_confirm' action was removed from hr.employee.public solution: remove 'action_employee_kiosk_confirm' action from 'hr_employees_view_kanban' view. task-4022620 Forwar

Version 17.0
steps to produce:

- open 'hr_employees_view_kanban' in debug mode by searching in 'open view'
- open hr attendance kanban view
- click on kanban record
- The method 'action_employee_kiosk_confirm' does not exist on the model 'hr.employee'

issue:
faced with a traceback

cause:
'action_employee_kiosk_confirm' action was removed from hr.employee.public

solution:
remove 'action_employee_kiosk_confirm' action from 'hr_employees_view_kanban' view.

task-4022620

Forward-Port-Of: odoo/odoo#171471

Improve some shortcomings of the comparison system applied on history revisions. * Better handling of diffs generated by changes in html parameters: > Previous system was generating unnecessary HTML opening tags in those cases. * Better handling of addition or deletion in previously empty HTML tags. > Previous system was generating unnecessary HTML opening tags in those cases. * Better handling of HTML tag replacement. > Previous system was generating invalid HTML in those cases.

Improve some shortcomings of the comparison system applied on history revisions.

* Better handling of diffs generated by changes in html parameters:
> Previous system was generating unnecessary HTML opening tags in those cases.

* Better handling of addition or deletion in previously empty HTML tags.
> Previous system was generating unnecessary HTML opening tags in those cases.

* Better handling of HTML tag replacement.
> Previous system was generating invalid HTML in those cases.

* Trade off the comparison generated on some complex changes to be able to display correct HTML
> When we have both an HTML parameter change on the container tag and a content
> change, we choose to display both `<added>` and `<removed>` in the same
> container.
> The current system is not smart enough to generate a better comparison and
> would require extensive refactoring to handle this better.

task-3761721


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

Forward-Port-Of: odoo/odoo#171951
Forward-Port-Of: odoo/odoo#160460

Now that lots can be set without company, we want them to have by default the company of their related product. The issue is that if there is a `default_company_id` set in the context at any point, it will prevent the computation of the right `company_id`, causing the wrong company (or a company where there shouldn't be one) to be set on the lot. To prevent this, we simply pop the `default_company_id` from the context if present when checking the default values, forcing the use of the comp

Now that lots can be set without company, we want them to have by default the company of their related product.

The issue is that if there is a `default_company_id` set in the context at any point, it will prevent the computation of the right `company_id`, causing the wrong company (or a company where there shouldn't be one) to be set on the lot.

To prevent this, we simply pop the `default_company_id` from the context if present when checking the default values, forcing the use of the compute instead.

Also restores the `default_company_id` in
`action_generate_lot_line_vals`, as this removes the default from move lines, and is no longer necessary for lots.

Description of the issue/feature this PR addresses:

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

Forward-Port-Of: odoo/odoo#171982

Steps to reproduce: -Go to analytic plans -> Projects -> Add a new line with a "Purchase Order" Domain and set Applicability to "Mandatory" -> Save -Go to Bills oF Materials -> create a new one w/ any product -> Save Issue: -There will be an error "One or more lines require a 100% analytic distribution." Cause: When saving the BoM, it leads to a constraint check https://github.com/odoo/odoo/blob/0217b88e481dc1d0d244b620ba527dec177edde1/addons/mrp_account/models/mrp_bom.py#L44-L50 I

Steps to reproduce:
-Go to analytic plans -> Projects -> Add a new line with a "Purchase Order" Domain and set Applicability to "Mandatory" -> Save
-Go to Bills oF Materials -> create a new one w/ any product -> Save

Issue:
-There will be an error "One or more lines require a 100% analytic distribution."

Cause:
When saving the BoM, it leads to a constraint check
https://github.com/odoo/odoo/blob/0217b88e481dc1d0d244b620ba527dec177edde1/addons/mrp_account/models/mrp_bom.py#L44-L50

In this method, we first try to find the relevant plans:
https://github.com/odoo/odoo/blob/d6bdb05771fd29a79f2e8087b92a438fec28afaa/addons/analytic/models/analytic_mixin.py#L103-L107

To do so, we take all existing plans, evaluate them with a score, and take the one with the higher score. Here is the issue: when evaluating *Projects*, since we didn't provide any business domain and since the plan has a company, we assign a 0.5 score to the plan instead of skipping it:
https://github.com/odoo/odoo/blob/f17b37b14cad8f353443586cc9c4ecaf86e476da/addons/analytic/models/analytic_plan.py#L310-L319
Which does not make sense as the business domain of *Project* is *Purchase Order* and here the user is dealing with a BoM...

As a result, back to `_validate_distribution`, we check the distribution for this plan and realize there isn't any, hence the error:
https://github.com/odoo/odoo/blob/d6bdb05771fd29a79f2e8087b92a438fec28afaa/addons/analytic/models/analytic_mixin.py#L115-L117

Solution:

BOM: We don't restrict anymore the creation of a BOM. Setting an analytic distribution is only a tool to facilitate the definition of the analytic distribution on the MO but the creation should not be constrained
Workcenter: we correct the flowing by specifying the business domain restricting the creation of a workcenter if any relevant rule is present

Forward-Port-Of: odoo/odoo#168688

When filling a relational field, suggestions are displayed using the AutoComplete component. Problem is, when choosing any suggestion, some ARIA attributes are missing for assistive technologies to know what is the currently-selected suggestion. That because the actual focus is always on the field's input, while the actually-selected suggestion is highlighted by toggling classes, which makes not possible anymore to know what is the selected suggestion for e.g. screen reader users. This commi

When filling a relational field, suggestions are displayed using the AutoComplete component. Problem is, when choosing any suggestion, some ARIA attributes are missing for assistive technologies to know what is the currently-selected suggestion. That because the actual focus is always on the  field's input, while the actually-selected suggestion is highlighted by toggling classes, which makes not possible anymore to know what is the selected suggestion for e.g. screen reader users.

This commit adds such attributes.

This is similar to what was done on 9764e6f7 for the command palette to handle search results on the home screen.


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

Forward-Port-Of: odoo/odoo#172192
Forward-Port-Of: odoo/odoo#165903

Before this commit: If 2 IoT box are set on different companies and both have a printer with the same identifier. On the completion request, the server can not be sure from which device the priting was completed and might choose the wrong IoT. As such the "fail to print" notification will appear while it is false opw-3965623 Forward-Port-Of: odoo/odoo#172083 Forward-Port-Of: odoo/odoo#171808

Before this commit:
If 2 IoT box are set on different companies and both have a printer with the same identifier.
On the completion request, the server can not be sure from which device the priting was completed and might choose the wrong IoT.

As such the "fail to print" notification will appear while it is false

opw-3965623

Forward-Port-Of: odoo/odoo#172083
Forward-Port-Of: odoo/odoo#171808

-fix and issue when adding a product to the cart (in debug mode only) an error pops up because freeze and refresh functions are missing from the props and the warning prop is not set as optional. opw-4016928 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#171912

-fix and issue when adding a product to the cart (in debug mode only)
 an error pops up because freeze and refresh functions are missing
 from the props and the warning prop is not set as optional.

opw-4016928


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

Forward-Port-Of: odoo/odoo#171912

task-3744319 Forward-Port-Of: odoo/odoo#171570 Forward-Port-Of: odoo/odoo#171021

task-3744319

Forward-Port-Of: odoo/odoo#171570
Forward-Port-Of: odoo/odoo#171021

Purpose ======= Fix the dynamic placeholder popup which wasn't closing when clicking on escape or on the "x" button in the field selection view. Instead of closing, the default value selection was displayed. Specification ============= The dynamic placeholder files have been cleaned recently and a mistake was made as the isPathSelected value was being set to true on popup closing no matter if the path was selected or not. Fixing the issue by checking if the path value is correctly set,

Purpose
=======
Fix the dynamic placeholder popup which wasn't closing when clicking on escape or on the "x" button in the field selection view. Instead of closing, the default value selection was displayed.

Specification
=============
The dynamic placeholder files have been cleaned recently and a mistake was made as the isPathSelected value was being set to true on popup closing no matter if the path was selected or not.

Fixing the issue by checking if the path value is correctly set, if it is, displaying the default value view, else closing the popover.

related PR: odoo/odoo#117951

Task-4001976

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

Forward-Port-Of: odoo/odoo#171697

This commit addresses an issue where searching for a product by name in the database led to the recreation of product records. The problem arose during the addition of products to indexedRecords, resulting in duplicates. Community PR: https://github.com/odoo/odoo/pull/171264 opw-4004765 Forward-Port-Of: odoo/enterprise#65952

This commit addresses an issue where searching for a product by name in the database led to the recreation of product records. The problem arose during the addition of products to indexedRecords, resulting in duplicates.

Community PR: https://github.com/odoo/odoo/pull/171264

opw-4004765

Forward-Port-Of: odoo/enterprise#65952

Steps: - Install social_demo, crm - Open social marketing app - Open instagram ost - Create a lead from comment Actual result: - issue due to the demo data with invalid date format - demo date is not ISO8601 compliant Expected result - Lead wizard is opened opw-3975423 opw-4019390 Caused-by: https://github.com/odoo/enterprise/commit/4fb0f854c57c1669eea8a383a55e16dd52894142 Forward-Port-Of: odoo/enterprise#64204

Steps:
- Install social_demo, crm
- Open social marketing app
- Open instagram ost
- Create a lead from comment

Actual result:
- issue due to the demo data with invalid date format
- demo date is not ISO8601 compliant

Expected result
- Lead wizard is opened

opw-3975423
opw-4019390

Caused-by: https://github.com/odoo/enterprise/commit/4fb0f854c57c1669eea8a383a55e16dd52894142

Forward-Port-Of: odoo/enterprise#64204

## Before this PR In WhatsApp Composer, the Sample Values do not update when changing the WhatsApp Template. Instead, it display the sample values from the initially selected template. ## After this PR The Sample Values will now update according to the selected WhatsApp Template. Task-3996935 Forward-Port-Of: odoo/enterprise#65198

## Before this PR
In WhatsApp Composer, the Sample Values do not update when changing the WhatsApp Template. Instead, it display the sample values from the initially selected template.

## After this PR
The Sample Values will now update according to the selected WhatsApp Template.

Task-3996935

Forward-Port-Of: odoo/enterprise#65198

Steps to reproduce ================== - Install website_studio - Open any app - Open studio - Click on the website tab - Create a new listing type and confirm - Click on the three dots - View in website => TypeError: Cannot read properties of undefined (reading 'action') Cause of the issue ================== Before https://github.com/odoo/enterprise/pull/49809/commits/7980155915f25128e7cb8d5a0af91ffe45bb44c7 ```xml <t t-set="onItemClicked" t-value="page.page_type === 'lis

Steps to reproduce
==================

- Install website_studio
- Open any app
- Open studio
- Click on the website tab
- Create a new listing type and confirm
- Click on the three dots
- View in website

=> TypeError: Cannot read properties of undefined (reading 'action')

Cause of the issue
==================

Before https://github.com/odoo/enterprise/pull/49809/commits/7980155915f25128e7cb8d5a0af91ffe45bb44c7

```xml
<t t-set="onItemClicked" t-value="page.page_type === 'listing' ? this.openPageUrl.bind(this, page) : this.onConfigurePage.bind(this, page)" />
<t t-set="openPageUrl" t-value="page.page_type === 'listing' ? onItemClicked : null" />
<DropdownItem t-if="openPageUrl" onSelected="openPageUrl" href="'#'">View in website</DropdownItem>
```

in the new version, `t-if="openPageUrl"` was always true because `openPageUrl` refers to the function and not the template variable.

The function was also not bound to `this`.

Solution
========

- The "View in Website" button should only be displayed for pages of listing type.
- We add the this to the function call

opw-3987521

Forward-Port-Of: odoo/enterprise#65988
Forward-Port-Of: odoo/enterprise#64691

### Steps to reproduce the issue: 1. Create a Product with "Service" as Product Type and "Based on Timesheets" as Invoicing Policy 2. Go to _Field Service > Configuration > Projects_ and choose a Project 3. In the _Invoicing_ section, add a line with an Employee and the Service Product you created 4. Create a Task for the Project 5. Add in the _Timesheets_ section a line with the Employee and a duration of one hour 6. Click on "Mark as done", then "Sales Order" 7. The Delivered Quantiti

### Steps to reproduce the issue:

1. Create a Product with "Service" as Product Type and "Based on Timesheets" as Invoicing Policy
2. Go to _Field Service > Configuration > Projects_ and choose a Project
3. In the _Invoicing_ section, add a line with an Employee and the Service Product you created
4. Create a Task for the Project
5. Add in the _Timesheets_ section a line with the Employee and a duration of one hour
6. Click on "Mark as done", then "Sales Order"
7. The Delivered Quantities have a correct value but the Ordered Quantities do not

### Explanation:

An uom conversion is performed in `_get_delivered_quantity_by_analytic` to compute `qty_delivered` but is missing in `_fsm_create_sale_order_line` for `product_uom_qty`.
https://github.com/odoo/odoo/blob/18e03c73691d9efa82cbf82b5e084172fe74665e/addons/sale/models/sale_order_line.py#L386-L392

### Suggested Fix:

To prevent unintended behaviours, any product that is currently used in a Field Service Project will have `invoice_policy`, `service_type` and `detailed_type` locked to match the domain of `timesheet_product_id` for every model using it.

opw-3858530

Forward-Port-Of: odoo/enterprise#66185
Forward-Port-Of: odoo/enterprise#63337

Serbian is a rare example of "synchronic digraphia", meaning that it has two writing systems that coexist and are used interchangeably by its speakers: Cyrillic and Latin. To handle this feature of Serbian in Odoo, we use a locale with a special modifier to specify the script to use: sr@latin. Problem: This locale is not recognized by the JavaScript APIs that implement the BCP 47 format, which leads to errors when trying to use them with the sr@latin locale. This PR provides a helper to

Serbian is a rare example of "synchronic digraphia", meaning that it has two writing systems that coexist and are used interchangeably by its speakers: Cyrillic and Latin.

To handle this feature of Serbian in Odoo, we use a locale with a special modifier to specify the script to use: sr@latin.

Problem: This locale is not recognized by the JavaScript APIs that implement the BCP 47 format, which leads to errors when trying to use them with the sr@latin locale.

This PR provides a helper to convert the locales from the Python side for use on the JavaScript side.

Task-4014022

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

Forward-Port-Of: odoo/enterprise#66240
Forward-Port-Of: odoo/enterprise#66061

This commit moves the generic `_with_locked_records` from `l10n_mx_edi.document` in `l10n_mx_edi` -> `res.company` in `account` This allows multiple EDIs to use the same generic method for locking their record before using them in requests. This prevents 2 (or more) users to send the same invoice at the same time. Affected EDIs: l10n_mx_edi, l10n_ro_edi task-id: 3595436 related community PR: https://github.com/odoo/odoo/pull/144061 Forward-Port-Of: odoo/enterprise#65602

This commit moves the generic `_with_locked_records` from `l10n_mx_edi.document` in `l10n_mx_edi` -> `res.company` in `account`

This allows multiple EDIs to use the same generic method for locking their record before using them in requests. This prevents 2 (or more) users to send the same invoice at the same time.

Affected EDIs: l10n_mx_edi, l10n_ro_edi

task-id: 3595436
related community PR: https://github.com/odoo/odoo/pull/144061

Forward-Port-Of: odoo/enterprise#65602

This PR makes the employees always appear in alphabetical order in the planning overlap warning. This fixes a test breaking when the order changes, and prevents potential problems caused by a nondeterministic order. Task-4037741 Forward-Port-Of: odoo/enterprise#66154

This PR makes the employees always appear in alphabetical order in the planning overlap warning. This fixes a test breaking when the order changes, and prevents potential problems caused by a nondeterministic order.

Task-4037741

Forward-Port-Of: odoo/enterprise#66154

Before this commit the timesheet_mail_employee_nextdate and timesheet_mail_manager_nextdate Were calculated only when a change was made on timesheet_mail_employee_delay, timesheet_mail_employee_interval or timesheet_mail_manager_delay, timesheet_mail_manager_interval fields, even tho those two have a default value Now the _timesheet_postprocess method will always call _calculate_timesheet_mail_employee_nextdate and _calculate_timesheet_mail_manager_nextdate method when called from the res.com

Before this commit the timesheet_mail_employee_nextdate and timesheet_mail_manager_nextdate Were calculated only when a change was made on timesheet_mail_employee_delay, timesheet_mail_employee_interval or timesheet_mail_manager_delay, timesheet_mail_manager_interval fields, even tho those two have a default value

Now the _timesheet_postprocess method will always call _calculate_timesheet_mail_employee_nextdate and _calculate_timesheet_mail_manager_nextdate method when called from the res.company.create method

Seems to work even if the delay and interval fields don't have default value

Following this PR > https://github.com/odoo/enterprise/pull/48096

15.0 > master

Task-3714293

Forward-Port-Of: odoo/enterprise#65564
Forward-Port-Of: odoo/enterprise#55546

30% Exemption field shows on all contracts although it should only show on dutch employees contracts. This change restricts the 30% Exemption to only show on dutch contracts. task-3946599 Forward-Port-Of: odoo/enterprise#65790

30% Exemption field shows on all contracts although it should only show on dutch employees contracts.

This change restricts the 30% Exemption to only show on dutch contracts.

task-3946599

Forward-Port-Of: odoo/enterprise#65790

PR does 2 things: - First round of .po file cleaning for es_xx.po files. Since v17 started using es_419 instead of the es_xx.po files, these languages are no longer accessible on Transifex for the translators to change. These files were mostly out of date/incorrect anyways though, so we delete them. The one exception to this is the es_CL.po because Chile has some specific words that differ from the rest of LATAM. This cleanup will occur in a followup PR to give translators time to double chec

PR does 2 things:

- First round of .po file cleaning for es_xx.po files. Since v17 started using es_419 instead of the es_xx.po files, these languages are no longer accessible on Transifex for the translators to change. These files were mostly out of date/incorrect anyways though, so we delete them. The one exception to this is the es_CL.po because Chile has some specific words that differ from the rest of LATAM. This cleanup will occur in a followup PR to give translators time to double check if any of the translations in from these es_CL files should remain.
- Cleanup the en_AU/en_GB.po files. There were some non-sense "translations" in them and most of them didn't add much value. Some en_AU files had specific legitimate "translations" were left (e.g. tax "GST", check = cheque), so they were only modified to remove any erroneous translations

task: 3593077
COM PR: https://github.com/odoo/odoo/pull/171520

Forward-Port-Of: odoo/enterprise#66078
Forward-Port-Of: odoo/enterprise#65875

### Steps to reproduce: - Install Sale Subscription module - Create a recurrent order and add Optional products and Start date under Other info tab - Click on Preview ### Current behavior before PR: You won't see the optional products in the portal view if for a recurrent order that has start date and in draft. This is happening because in sale_subscription we are checking if the start_date of the order is equal to the next_invoice_date https://github.com/odoo/enterprise/blob/17.0/sal

### Steps to reproduce:
	- Install Sale Subscription module
	- Create a recurrent order and add Optional products and Start date under Other info tab
	- Click on Preview

### Current behavior before PR:
You won't see the optional products in the portal view if for a recurrent order that has start date and in draft. This is happening because in sale_subscription we are checking if the start_date of the order is equal to the next_invoice_date
https://github.com/odoo/enterprise/blob/17.0/sale_subscription/models/sale_order.py#L1957:1959 and if the order is in draft it won't have a next_invoice date until it is either confirmed or sent.

### Desired behavior after PR is merged:
We are now checking if the next_inovice_date is not set we show the optional products.

opw-3980405

Forward-Port-Of: odoo/enterprise#66237
Forward-Port-Of: odoo/enterprise#64894

Currently the warning of the partner VAT listing is never shown. In 88b449b08e21700e9dd113250125b2c3daa65a0f (17.2) the warnings for custom report handlers were moved from `_custom_line_postprocessor` to a new function called `_customize_warnings`. Currently this is not the case for the partner VAT listing. This commit does the necessary change for the partner VAT listing. (This commit does not belong to any task) Forward-Port-Of: odoo/enterprise#64313

Currently the warning of the partner VAT listing is never shown.

In 88b449b08e21700e9dd113250125b2c3daa65a0f (17.2) the warnings for custom report handlers were moved from `_custom_line_postprocessor` to a new function called `_customize_warnings`.
Currently this is not the case for the partner VAT listing.

This commit does the necessary change for the partner VAT listing.

(This commit does not belong to any task)

Forward-Port-Of: odoo/enterprise#64313

Before this commit, avatax used the longitude and latitude in priority even if the partner has an address. The problem with this is that when you print the AvaTax report, the fields DestStreet, DestCity, and DestPostalCode are not populated because AvaTax was not sent any of that information. The customer needs those fields to be populated or else they may be charged more money. So now it will be the opposite, we will use the address in priority but if the customer has a delivery address wit

Before this commit, avatax used the longitude and latitude in priority even if the partner has an address.
The problem with this is that when you print the AvaTax report, the fields DestStreet, DestCity, and DestPostalCode are not populated because AvaTax was not sent any of that information. The customer needs those fields to be populated or else they may be charged more money.

So now it will be the opposite, we will use the address in priority but if the customer has a delivery address with no address information we will use the latitude and longitude of the delivery address partner.

Task: 4011481

Forward-Port-Of: odoo/enterprise#66106
Forward-Port-Of: odoo/enterprise#65726

Adapt history revision tour after the improvements done on the comparison feature. task-3761721 Forward-Port-Of: odoo/enterprise#66069 Forward-Port-Of: odoo/enterprise#60061

Adapt history revision tour after the improvements done on the comparison feature.

task-3761721

Forward-Port-Of: odoo/enterprise#66069
Forward-Port-Of: odoo/enterprise#60061

With an MX company setup Go to Accounting > Reports > Trial Balance. Click "SAT (XML)" to export the file. Issue: No certificate in the xml In Odoo 15, exporting the SAT XML would include the company's EDI certificate. In Odoo 16 and newer, this is no longer the case. opw-3891205 Forward-Port-Of: odoo/enterprise#62969

With an MX company setup
Go to Accounting > Reports > Trial Balance.
Click "SAT (XML)" to export the file.

Issue: No certificate in the xml

In Odoo 15, exporting the SAT XML would include the company's EDI certificate. In Odoo 16 and newer, this is no longer the case.

opw-3891205

Forward-Port-Of: odoo/enterprise#62969

Versions -------- - 16.0+ Steps ----- 1. Create an open slot in a planning; 2. publish & send an email to an employee who could fill it; 3. open the planning link sent via email; 4. open the same URL while logged out. Issue ----- The datetimes of the open slot are displayed in UTC. Cause ----- Commit cf256e94d333 modified the planning template to use the `datetime` widget to format the dates instead of the `format_datetime` function provided by the `ShiftController`. Doing so

Versions
--------
- 16.0+

Steps
-----
1. Create an open slot in a planning;
2. publish & send an email to an employee who could fill it;
3. open the planning link sent via email;
4. open the same URL while logged out.

Issue
-----
The datetimes of the open slot are displayed in UTC.

Cause
-----
Commit cf256e94d333 modified the planning template to use the `datetime` widget to format the dates instead of the `format_datetime` function provided by the `ShiftController`. Doing so, it lost access to the `employee_tz` value, derived from the email recipient, and hence defaulted to UTC.

Solution
--------
Format the dates using `format_datetime`.

opw-3967787

Forward-Port-Of: odoo/enterprise#66231
Forward-Port-Of: odoo/enterprise#66015

Before this commit: If an IoT is set on a company (other than the default one), when printing a report set to an IoT device. It would always show the "error to print" pop-up. This happened as the notification that the printing operation was successful was always send to the channel of the first company. After this commit: We force to use the company set on the device of the identifier (which is the iot box company). This heuristic is not perfect as different IoT might have devices wit

Before this commit:
If an IoT is set on a company (other than the default one), when printing a report set to an IoT device. It would always show the "error to print" pop-up.

This happened as the notification that the printing operation was successful was always send to the channel of the first company.

After this commit:
We force to use the company set on the device of the identifier (which is the iot box company).

This heuristic is not perfect as different IoT might have devices with the same identifier, in this case, it would accidentally send to the wrong IoT channel.
To solve this other issue, another PR in the IoT will force to send the IoT mac address in order to make sure to use the right IoT. As the code of the IoT might be outdated, we define it with a default value.

opw-3965623

Forward-Port-Of: odoo/enterprise#66132
Forward-Port-Of: odoo/enterprise#65996