Before this commit, when a partner linked to a specific pricelist was searched and loaded in the PoS, the associated pricelist and its products could be unintentionally loaded, even if they were not available in the PoS. opw-4615603 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#200716 Forward-Port-Of: odoo/odoo#200401

Before this commit, when a partner linked to a specific pricelist was searched and loaded in the PoS, the associated pricelist and its products could be unintentionally loaded, even if they were not available in the PoS.

opw-4615603

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

Forward-Port-Of: odoo/odoo#200716
Forward-Port-Of: odoo/odoo#200401

[FIX] web_editor: translate paragraph links as a whole. Steps to reproduce: 1. Enable a second language in the website (e.g., French). 2. Add a "Text" block (in edit mode) > Save the page. 3. Translate a text paragraph to french > Save. 4. In edit mode again, add a link to a word in the paragraph > Save. 5. The translation in French is lost, and sometimes the whole French translation is used for the text before or after the link. This is actually a limitation in the tran

[FIX] web_editor: translate paragraph links as a whole.

Steps to reproduce:

1. Enable a second language in the website (e.g., French).

2. Add a "Text" block (in edit mode) > Save the page.

3. Translate a text paragraph to french > Save.

4. In edit mode again, add a link to a word in the paragraph > Save.

5. The translation in French is lost, and sometimes the whole French
   translation is used for the text before or after the link.

This is actually a limitation in the translation implementation. If we
initially have `text_1_en text_2_en text_3_en` translated to French this
way:

terms en_US: `["text_1_en text_2_en text_3_en"]`
terms fr_BE: `["text_1_fr text_2_fr text_3_fr"]`

After adding a link: `text_1_en<a...>text_2_en</a>text_3_en`, and since
the links are not translated as a whole, we should get:

terms en_US: `["text_1_en", "text_2_en", "text_3_en"]`
terms fr_BE: `["text_1_fr text_2_fr text_3_fr"]`

Which means the current translation will be lost, and the result will
depend on the outcome of `get_close_matches()`. Which explains why when
the link is added to the first words of the paragraph, the system still
maps the rest of the paragraph to its "full old translation".

The goal of this commit is to make this behavior less aggressive by
forcing the links added in paragraphs [1] to be translated as a whole.
This way, the `get_close_matches()` will map the new content with a link
to its old translation (without a link), and then, the user can set the
link in the "the most meaningful part of the translation" in the
translate mode.

[1]: We should use the "translate as a whole" feature carefully with
links, since there are already some situations where it's causing
issues (see the fix in [2]). So we only force them inside paragraphs.

[2]: https://github.com/odoo/odoo/commit/9bd60ca93510e410a0136b8b433f596330900593

opw-3984439

Forward-Port-Of: odoo/odoo#204207
Forward-Port-Of: odoo/odoo#179167

Currently a `ParseError` arises when the user installs the `hr_work_entry_holidays` module after deleting all `Time Off Types` in the `Time Off` Configuration. Steps to reproduce: --- - Install `hr_holidays` module (without demo data) - Time Off > Configuration > `Time Off Types` > Delete all - Now install `hr_work_entry_holidays` module Traceback: --- ``` Exception: Cannot update missing record 'hr_holidays.holiday_status_comp' ParseError: while parsing /home/odoo/src/odoo/saas-

Currently a `ParseError` arises when the user installs the `hr_work_entry_holidays` module after deleting all `Time Off Types` in the `Time Off` Configuration.

Steps to reproduce:
---
- Install `hr_holidays` module (without demo data)
- Time Off > Configuration > `Time Off Types` > Delete all
- Now install `hr_work_entry_holidays` module

Traceback:
---
```
Exception: Cannot update missing record 'hr_holidays.holiday_status_comp'

ParseError: while parsing /home/odoo/src/odoo/saas-18.1/addons/hr_work_entry_holidays/data/hr_payroll_holidays_data.xml:5, somewhere inside <record id="hr_holidays.holiday_status_comp" model="hr.leave.type">
            <field name="work_entry_type_id" ref="hr_work_entry_contract.work_entry_type_compensatory"/>
        </record>
```

The error occurs because the user deleted all `Time Off Types` and then installed the `hr_work_entry_holidays` module. which requires particular records.

This commit solves the above issue by using `noupdate="1"` and `forcecreate="False"` to bypass record creation if it violates checks.

https://github.com/odoo/odoo/blob/b794f0f332f473deb2c04eba60baf4761db3b508/odoo/tools/convert.py#L364-L366

sentry-5731062091

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

Forward-Port-Of: odoo/odoo#198069

### Steps to reproduce: - Accounting > Customers > Invoices - Select all - Actions > Resequence - Add a month in the sequence: INV/2025/03/001 - Create a new invoice and select a date in a future month - The name in the placeholder does not respect the new sequencing format ### Cause: `_compute_name_placeholder` uses `_get_starting_sequence` which always return the same format for invoices. ### Solution: Change `_compute_name_placeholder`, mimicking the way the sequence number is c

### Steps to reproduce:
- Accounting > Customers > Invoices
- Select all
- Actions > Resequence
- Add a month in the sequence: INV/2025/03/001
- Create a new invoice and select a date in a future month
- The name in the placeholder does not respect the new sequencing format

### Cause:
`_compute_name_placeholder` uses `_get_starting_sequence` which always return the same format for invoices.

### Solution:
Change `_compute_name_placeholder`, mimicking the way the sequence number is computed in `_set_next_sequence`.

opw-4612328

Forward-Port-Of: odoo/odoo#202333

Scenario: - install website, event - add a form in website with action "Create Event Registration" - add a field Event in that form - send the form with an event that would accept registration Result: the registration is saved but you see "An error has occured, the form has not been sent." and server side you see this traceback: File "addons/website/controllers/form.py", line 45, in website_form with request.env.cr.savepoint(): … File "/Users/odoo/src/odoo/18.0/odoo/sql_db.py", line

Scenario:

- install website, event
- add a form in website with action "Create Event Registration"
- add a field Event in that form
- send the form with an event that would accept registration

Result: the registration is saved but you see "An error has occured, the
form has not been sent." and server side you see this traceback:

  File "addons/website/controllers/form.py", line 45, in website_form
    with request.env.cr.savepoint():
  …
  File "/Users/odoo/src/odoo/18.0/odoo/sql_db.py", line 119, in _close
    self._cr.execute('RELEASE SAVEPOINT "%s"' % self.name)
  …
  psycopg2.errors.InvalidSavepointSpecification: savepoint "…" does not
  exist

Cause: creating an event.registration calls
event.registration()._update_mail_schedulers which depending on
configurations might end up sending mail after which we commit the
transaction (probably to avoid sending an email two times) but this
deletes all the current savepoints. So even if everything is commited,
successfully, the __exit__ method of the savepoint will raise an error
when trying to close a savepoint that is already deleted.

Fix: ignore cases where there has not been any error, but the savepoint
has been deleted before being released.

opw-4599918

Forward-Port-Of: odoo/odoo#203851
Forward-Port-Of: odoo/odoo#200362

### Description of the issue/feature this PR addresses: There is no need to print the tax detail information when the invoice's currency is not the same as the company's currency. This change removes that part of the report, and it only affects the AR Invoice Legal report. This functionality was added to the account module and affects all the invoice reports, but we do not want them to be in the AR legal report. For more information about the extra tax detail in the company's currency, you

### Description of the issue/feature this PR addresses:

There is no need to print the tax detail information when the invoice's currency is not the same as the company's currency. This change removes that part of the report, and it only affects the AR Invoice Legal report.

This functionality was added to the account module and affects all the invoice reports, but we do not want them to be in the AR legal report. For more information about the extra tax detail in the company's currency, you can check this commit https://github.com/odoo/odoo/commit/8823e01040f9522947e5d11c7312d09c50867cc4

### Current behavior before PR:

![before](https://github.com/user-attachments/assets/7d0fcb9a-1cbc-4e66-8904-98e8b2010478)

### Desired behavior after PR is merged:

![after](https://github.com/user-attachments/assets/156c8771-e87e-495a-9633-136063bab5d3)

LATAM task 1329 / Adhoc ticket 88609

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

Forward-Port-Of: odoo/odoo#201084

Currently, a return for exchange made on an incoming transfer (receipt) creates a procurement, which usually ends up with a purchase of the exchanged products. After the "Return" popup is closed, the exchange transfer is not created; instead, Odoo creates a PO that needs to be approved first in order to create the exchange transfer. That is a bit confusing for the users, who might expect the exchange to be created immediately. Also, the procurement process requires the product to have a "Bu

Currently, a return for exchange made on an incoming transfer (receipt) creates a procurement, which usually ends up with a purchase of the exchanged products.
After the "Return" popup is closed, the exchange transfer is not created; instead, Odoo creates a PO that needs to be approved first in order to create the exchange transfer.

That is a bit confusing for the users, who might expect the exchange to be created immediately.
Also, the procurement process requires the product to have a "Buy" route enabled (in "Inventory" tab) and at least one vendor configured in the "Purchase" tab. Without this configuration, the return for exchange process shows an error message.

After this commit, a return for exchange made on a receipt will ignore the procurement process, and instead it will create the exchange picking immediately.
That way users will see the exchange transfer immediately after closing the "Return" popup. Also, all 3 transfers (original, return, exchange) will be linked to the initial PO (if a PO was created).
Additionally, the exchange picking will be shown as a return of the return picking.

Task: 4453571

Forward-Port-Of: odoo/odoo#201270

When importing statements the creation of the `account_move_lines` in `account_bank_statement_line.create` takes a lot of time. One of the reasons for that is that the amls are created for each st_line via the one2many field assignation. This commit speeds up this process by creating all the amls at once after looping through `st_lines`. Batching the amls creation like that leads to a noticeable speedup when importing a lot of statements. speedup Importing bank_statement file in Odoo 18

When importing statements the creation of the `account_move_lines` in `account_bank_statement_line.create` takes a lot of time. One of the reasons for that is that the amls are created for each st_line via the one2many field assignation.

This commit speeds up this process by creating all the amls at once after looping through `st_lines`. Batching the amls creation like that leads to a noticeable speedup when importing a lot of statements.

speedup

Importing bank_statement file in Odoo 18.0.

| Number of lines_to_create | Before PR  | After PR |
|:-------------------------:|:----------:|:--------:|
|           100             |    5.24s   |  2.78s   |
|           500             |    22.72s  |  11.47s  |
|           1000            |    44.66s  |  21.73s  |
|           3000            |    2min15s |  1min05s |


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

Forward-Port-Of: odoo/odoo#203681

In the Wayland upgrade PR (#202722), the base Raspberry Pi OS image was updated to the November 2024 version. A side effect of this is that Wi-fi is now being blocked by default, with the following message appearing in the shell: > Wi-Fi is currently blocked by rfkill. > Use raspi-config to set the country before use. IoT boxes are deployed in multiple countries and need to work by default without any configuration, so there is no sensible default we can provide. Instead, we fix the issue

In the Wayland upgrade PR (#202722), the base Raspberry Pi OS image was updated to the November 2024 version. A side effect of this is that Wi-fi is now being blocked by default, with the following message appearing in the shell:

> Wi-Fi is currently blocked by rfkill.
> Use raspi-config to set the country before use.

IoT boxes are deployed in multiple countries and need to work by default without any configuration, so there is no sensible default we can provide. Instead, we fix the issue by simply uninstalling the `rfkill` package at build time.

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

Forward-Port-Of: odoo/odoo#204331

This commit partially reverts commit a635539, as its behaviour was deemed too risky to the stability of the IoT box. The latest code is still checked out on boot, but it no longer happens automatically every Monday. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#204291

This commit partially reverts commit a635539, as its behaviour was deemed too risky to the stability of the IoT box. The latest code is still checked out on boot, but it no longer happens automatically every Monday.

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

Forward-Port-Of: odoo/odoo#204291

**Current behavior before PR:** - The opacity slider in the color picker did not apply the selected opacity to the text. **Desired behavior after PR is merged:** - Now, adjusting the opacity using the slider in the color picker correctly applies the selected opacity to the text. task:4419805 Forward-Port-Of: odoo/odoo#203694 Forward-Port-Of: odoo/odoo#191579

**Current behavior before PR:**

- The opacity slider in the color picker did not apply the selected opacity to the text.

**Desired behavior after PR is merged:**

- Now, adjusting the opacity using the slider in the color picker correctly applies the selected opacity to the text.

task:4419805

Forward-Port-Of: odoo/odoo#203694
Forward-Port-Of: odoo/odoo#191579

Upgrade scripts are run only when there is an update of the module version. This is not flexible enough. After a major upgrade developers need to upgrade their custom modules. Unfortunately the tools in `upgrade-util` repo that modify modules (`merge_module`, `rename_module`, ...) should be done before loading base module. The latter is already upgraded after a major upgrade thus no upgrade scripts are run for it. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com

Upgrade scripts are run only when there is an update of the module version. This is not flexible enough. After a major upgrade developers need to upgrade their custom modules. Unfortunately the tools in `upgrade-util` repo that modify modules (`merge_module`, `rename_module`, ...) should be done before loading base module. The latter is already upgraded after a major upgrade thus no upgrade scripts are run for it.

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

Forward-Port-Of: odoo/odoo#204202
Forward-Port-Of: odoo/odoo#202014

### Steps to reproduce: - Create a flexible working schedule - Assign this working schedule to one of the employees - Create a public holiday for the flexible calendar - Create a leave for the flexible employee where the public holiday will be during his leave - Notice the duration of the leave ### Cause: This is happening because when calculating the leave duration for a flexible resource we are counting each day between 'leave.date_from' and 'leave.date_to' as the flexible emp

### Steps to reproduce:
	- Create a flexible working schedule
	- Assign this working schedule to one of the employees
	- Create a public holiday for the flexible calendar
	- Create a leave for the flexible employee where the public holiday will be during his leave
	- Notice the duration of the leave
	
### Cause:
This is happening because when calculating the leave duration for a
flexible resource we are counting each day between 'leave.date_from'
and 'leave.date_to' as the flexible employee should be available everyday.

### Fix:
We are now checking if there is a public holiday in the middle of the
leave and if so we exclude these days from the leave duration.

opw-4568569

Forward-Port-Of: odoo/odoo#202111

LITRE is used instead of LITER in the uom definition, it causes a NAV validation error and the invoice cannot be submitted. task-4661729 Forward-Port-Of: odoo/odoo#203950

LITRE is used instead of LITER in the uom definition, it causes a NAV validation error and the invoice cannot be submitted.

task-4661729

Forward-Port-Of: odoo/odoo#203950

Before this commit, when the screen size was small and there were a high number of payment methods, the numpad would become invisible, making it impossible to edit the payment amount. opw-4666090 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#203265

Before this commit, when the screen size was small and there were a high number of payment methods, the numpad would become invisible, making it impossible to edit the payment amount.

opw-4666090

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

Forward-Port-Of: odoo/odoo#203265

Before this commit, there was no test to ensure that orders could be validated correctly when using a currency with zero decimal places. This commit adds a test to validate an order with a zero decimal places currency, ensuring that the system handles such cases without errors. opw-4595028 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#198754

Before this commit, there was no test to ensure that orders could be validated correctly when using a currency with zero decimal places. This commit adds a test to validate an order with a zero decimal places currency, ensuring that the system handles such cases without errors.

opw-4595028

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

Forward-Port-Of: odoo/odoo#198754

When multiple pricelist rules with different minimum quantities existed (global or category-based), the incorrect rule was being selected. This was caused by an unnecessary search on already filtered and priority-sorted pricelist rules. Now we simply select the first matching rule, respecting the priority. opw-4609371 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#202574

When multiple pricelist rules with different minimum quantities existed (global or category-based), the incorrect rule was being selected. This was caused by an unnecessary search on already filtered and priority-sorted pricelist rules.

Now we simply select the first matching rule, respecting the priority.

opw-4609371

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

Forward-Port-Of: odoo/odoo#202574

Currently, An error occurs when quick create an hr leave (Time Off Request). Step to produce: - Install the `hr_holidays` module. - Enable debug mode. - Open Settings / Technical / Resource / Resource Time Off, Create a new record, and attempt to quick create a 'Time Off Request'. Traceback: ``` File "/home/odoo/odoo/community/odoo/http.py", line 1788, in _serve_db return service_model.retrying(self._serve_ir_http, self.env) File "/home/odoo/odoo/community/odoo/service/m

Currently, An error occurs when quick create an hr leave (Time Off Request).

Step to produce:

- Install the `hr_holidays` module.
- Enable debug mode.
- Open Settings / Technical / Resource / Resource Time Off, Create a new record, and attempt to quick create a 'Time Off Request'.

Traceback:

```
  File "/home/odoo/odoo/community/odoo/http.py", line 1788, in _serve_db
    return service_model.retrying(self._serve_ir_http, self.env)
  File "/home/odoo/odoo/community/odoo/service/model.py", line 133, in retrying
    result = func()
  File "/home/odoo/odoo/community/odoo/http.py", line 1816, in _serve_ir_http
    response = self.dispatcher.dispatch(rule.endpoint, args)
  File "/home/odoo/odoo/community/odoo/http.py", line 2020, in dispatch
    result = self.request.registry['ir.http']._dispatch(endpoint)
  File "/home/odoo/odoo/community/odoo/addons/base/models/ir_http.py", line 221, in _dispatch
    result = endpoint(**request.params)
  File "/home/odoo/odoo/community/odoo/http.py", line 757, in route_wrapper
    result = endpoint(self, *args, **params_ok)
  File "/home/odoo/odoo/community/addons/web/controllers/dataset.py", line 24, in call_kw
    return self._call_kw(model, method, args, kwargs)
  File "/home/odoo/odoo/community/addons/web/controllers/dataset.py", line 20, in _call_kw
    return call_kw(request.env[model], method, args, kwargs)
  File "/home/odoo/odoo/community/odoo/api.py", line 464, in call_kw
    result = _call_kw_model(method, model, args, kwargs)
  File "/home/odoo/odoo/community/odoo/api.py", line 435, in _call_kw_model
    result = method(recs, *args, **kwargs)
  File "/home/odoo/odoo/community/odoo/models.py", line 1708, in name_create
    record = self.create({self._rec_name: name})
  File "<decorator-gen-165>", line 2, in create
  File "/home/odoo/odoo/community/odoo/api.py", line 414, in _model_create_multi
    return create(self, [arg])
  File "/home/odoo/odoo/community/addons/hr_holidays/models/hr_leave.py", line 937, in create
    if mapped_validation_type[leave_type_id] == 'no_validation':
KeyError: None

```

The error occurs because the system attempts to access 'leave_type_id'  from the `vals_list` at [1], But vals_list has no data.

Link [1]: https://github.com/odoo/odoo/blob/a1969de6e6a292b14ad1d19c256ead04dc202528/addons/hr_holidays/models/hr_leave.py#L945C17-L945C68

To resolve this issue, remove the `quick_create` option for `Time Off Request` field from the 'Resource Time Off' form view.

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

Forward-Port-Of: odoo/odoo#199163

The cron logic in the malaysian edi is very wrong; and will lead to a large amount of calls to be done to our API constantly as it can never really finish if you have quite a few valid invoices in the last 72h. We update the logic to better delay the api calls and retrigger, as well as logic avoiding to re-check valid invoices if they have been checked less than one hour ago. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/od

The cron logic in the malaysian edi is very wrong; and will lead to a large amount of calls to be done to our API constantly as it can never really finish if you have quite a few valid invoices in the last 72h.

We update the logic to better delay the api calls and retrigger, as well as logic avoiding to re-check valid invoices if they have been checked less than one hour ago.

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

Forward-Port-Of: odoo/odoo#204233
Forward-Port-Of: odoo/odoo#202817

LazyTranslate objects cannot be used directly in the `Markup.format()` function as it won't be able to find the lang to use. We have to explicitly use `self.env._()`. Runbot build error: https://runbot.odoo.com/odoo/runbot.build.error/98431 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#

LazyTranslate objects cannot be used directly in the `Markup.format()` function as it won't be able to find the lang to use.

We have to explicitly use `self.env._()`.

Runbot build error: https://runbot.odoo.com/odoo/runbot.build.error/98431

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#200930

After the refactor by https://github.com/odoo/enterprise/commit/84cc09959d82dbceb4fe673b85464ef3d8630606 the noCertificado field in the COA (Chart of Accounts) report became invalid. - On a Mexican company, generate the COA report from the Trial Balance. - In the generated XML, the noCertificado tag exceeds 20 characters. This tag should contain exactly 20 characters and match the noCertificado from the CFDI report. This commit applies the same string manipulation for the COA repoart a

After the refactor by https://github.com/odoo/enterprise/commit/84cc09959d82dbceb4fe673b85464ef3d8630606 the noCertificado field in the COA (Chart of Accounts) report became invalid.

- On a Mexican company, generate the COA report from the Trial Balance.
- In the generated XML, the noCertificado tag exceeds 20 characters.

This tag should contain exactly 20 characters and match the noCertificado from the CFDI report.

This commit applies the same string manipulation for the COA repoart as the cfdi report  (in the _add_certificate_cfdi_values method in the l10n_mx_edi module)

source:
http://www.sat.gob.mx/esquemas/ContabilidadE/1_1/BalanzaComprobacion/BalanzaComprobacion_1_1.xsd

opw-4644489

Forward-Port-Of: odoo/enterprise#82430

The committed amount was incorrect because the budget report query is comparing a `datetime` column (purchase_order.date_order) to a `date` column (budget_line.date_to). This is wrong because `'03-31-2025 21:00:00' <= '02-31-2025' == False` This made committed amounts under-reported whenever relevant activity happened on the final day of the budget. Steps to reproduce: - It’s easier to follow by watching this [video](https://drive.google.com/file/d/1SNTUJpiQpcET5pBcu-8PpD3Aw7UHALVD/view

The committed amount was incorrect because the budget report
query is comparing a `datetime` column (purchase_order.date_order)
to a `date` column (budget_line.date_to). This is wrong because
`'03-31-2025 21:00:00' <= '02-31-2025' == False`
This made committed amounts under-reported whenever
relevant activity happened on the final day of the budget.

Steps to reproduce:
- It’s easier to follow by watching this [video](https://drive.google.com/file/d/1SNTUJpiQpcET5pBcu-8PpD3Aw7UHALVD/view?usp=drive_link)
- Create an analytic account
- Create a new budget line with start and end dates set to today
- Assign the analytic account as internal and link it to a budget
- Go to Purchases > Create a new Request for Quotation
- Use the analytic account in the analytical distribution
- Confirm the order
- Go back to the budget line: the committed amount will incorrectly show 0

OPW-4624672

Forward-Port-Of: odoo/enterprise#82010

Description of the issue this commit addresses: When paying taxes via the "Pay tax: <period>" button on the miscellaneous journal of the accounting dashboard, a traceback can be encountered. --- Steps to reproduce: 1. Install l10n_nl_reports_vat_pay_wizard. 2. Remove the company vat number. 3. Create and post a closing entry for a period with some tax amount. 4. Go to the accounting dashboard. 5. Click the "Pay tax: <period> in the miscellaneous journal's box. 6. A traceback is

Description of the issue this commit addresses:

When paying taxes via the "Pay tax: <period>" button on the miscellaneous journal of the accounting dashboard, a traceback can be encountered.

---

Steps to reproduce:

1. Install l10n_nl_reports_vat_pay_wizard.
2. Remove the company vat number.
3. Create and post a closing entry for a period with some tax amount.
4. Go to the accounting dashboard.
5. Click the "Pay tax: <period> in the miscellaneous journal's box.
6. A traceback is raised.

---

Desired behavior after this commit is merged:

Instead of a traceback, a UserError explains why this is not possible to the user.

---

task-4677746

Forward-Port-Of: odoo/enterprise#82625

Issue: As Salary Rule Category could be updated by hand, it will viloate the constrain at upgrade Improve: remove constaint will marking dup rules So customers can cuztomize thier own rules with the same code - drop the tests where the constrain was tested closes odoo/enterprise#81978 Task: 4626756 Forward-Port-Of: odoo/enterprise#82723

Issue: As Salary Rule Category could be updated by hand, it will viloate the constrain at upgrade

Improve: remove constaint will marking dup rules So customers can cuztomize thier own rules with the same code

- drop the tests where the constrain was tested

closes odoo/enterprise#81978

Task: 4626756

Forward-Port-Of: odoo/enterprise#82723

Before this commit, attempting to sell a combo product resulted in an error due to a missing tax configuration. However, combo products are not supposed to have taxes assigned, leading to an unintended issue. opw-4555159 Forward-Port-Of: odoo/enterprise#82119 Forward-Port-Of: odoo/enterprise#80571

Before this commit, attempting to sell a combo product resulted in an error due to a missing tax configuration. However, combo products are not supposed to have taxes assigned, leading to an unintended issue.

opw-4555159

Forward-Port-Of: odoo/enterprise#82119
Forward-Port-Of: odoo/enterprise#80571

Bug: When creating a new payslip for a salesperson with work entries of code LEAVE1731, we would get a traceback. Reason: Since we were creating the record and did not yet save, the code was calling a method that did an SQL query on ids of self which is empty. Fix: We created a new method that uses the orm instead to handle this specific case. Forward-Port-Of: odoo/enterprise#78269

Bug:
When creating a new payslip for a salesperson with work entries of code LEAVE1731, we would get a traceback.

Reason:
Since we were creating the record and did not yet save, the code was calling a method that did an SQL query on ids of self which is empty.

Fix:
We created a new method that uses the orm instead to handle this specific case.

Forward-Port-Of: odoo/enterprise#78269

The `load templates` button was shown for portal users even though no template was accessible to them. This commit hides the button for portal users. Explanation: In the `knowledge.WysiwygArticleHelper` xml template, `isPortalUser` is used without having being instantiated in its related Component. Commit where `knowledge_article_html_field.js` was removed (previous scope for `isPortalUser` property for this feature): https://github.com/odoo/enterprise/commit/1e0f2950d613d6cd82d8889

The `load templates` button was shown for portal users even though no template
was accessible to them.

This commit hides the button for portal users.

Explanation:
In the `knowledge.WysiwygArticleHelper` xml template, `isPortalUser` is used
without having being instantiated in its related Component.

Commit where `knowledge_article_html_field.js` was removed (previous scope for
`isPortalUser` property for this feature): https://github.com/odoo/enterprise/commit/1e0f2950d613d6cd82d8889fb07bc04d6c91c466

Commit where `wysiwyg_article_helper.js` was introduced without the
`isPortalUser` property (oversight): https://github.com/odoo/enterprise/commit/e001efc750d25d5dfcc681e42adf7a46edc7f37b

task-4687833

Forward-Port-Of: odoo/enterprise#82689

To improve readability and performance, partners with a zero initial balance are now excluded from the partner ledger reports. task-4578612 Forward-Port-Of: odoo/enterprise#82647 Forward-Port-Of: odoo/enterprise#81642

To improve readability and performance, partners with a zero initial balance are now excluded from the partner ledger reports.

task-4578612

Forward-Port-Of: odoo/enterprise#82647
Forward-Port-Of: odoo/enterprise#81642

### Steps to reproduce: - Install "l10n_mx_edi" and switch to a Mexican company - In Accounting > Configuration > Taxes activate the tax "1.25 WH" - Create an invoice with one line with a price of $50 and the tax "1.25 WH" - Go to the customer of the invoice - Sale & Purchase > Fiscal information and activate "No Tax Breakdown" - Confirm the invoice and Send it to CFDI - Traceback ### Cause: This [commit](https://github.com/odoo/enterprise/pull/75381/commits/3f2e9437439fd6f987a1381647

### Steps to reproduce:
- Install "l10n_mx_edi" and switch to a Mexican company
- In Accounting > Configuration > Taxes activate the tax "1.25 WH"
- Create an invoice with one line with a price of $50 and the tax "1.25 WH"
- Go to the customer of the invoice
- Sale & Purchase > Fiscal information and activate "No Tax Breakdown"
- Confirm the invoice and Send it to CFDI
- Traceback

### Cause:
This [commit](https://github.com/odoo/enterprise/pull/75381/commits/3f2e9437439fd6f987a13816473da2bd5a26953d) added a part in the code to prevent rounding error when specific discounts are applied which makes the base have a 5 as third digit.

When having a withholding tax and selecting "No Tax Breakdown" on the partner, the base amount will be decreased by the amount of the tax. If this amount has a 5 as third digit, a difference is detected here: `delta_discount = currency.round(sum(x['importe'] for x in line_values_list)) - cfdi_values['subtotal']` because:
- `x['importe']` is 49.375 which rounds up to 49.38
- `cfdi_values['subtotal']` is 49.37 because the tax was rounded up from 0.625 to 0.63 The code will then try to find lines with discounts but there are none so it raises an error at the `max()` function which is given nothing.

### Solution:
Adding `default=None` to `max()` so it doesn't crash.

But the rounding issue still needs to be fixed.
The fix is to select a line with more than 2 digits and to remove the difference with its rounded value. This ensures that the resulting value stay in the same 2-digit range, preventing error CFDI40167, and that the sum of "importe" is rounded down.

opw-4528766

Forward-Port-Of: odoo/enterprise#81563

https://www.awesomescreenshot.com/image/53256805?key=71bd00e266f6b08236b3b490b3383b78 How to reproduce: - In the Social app, enable DEMO mode from the configuration settings. - Now click POSTS from the menuitems available. - Click any of the post which has been posted on about 4 accounts. - Scroll down to find the POSTS section, where in you will see that the posts are aligned vertically. Issue: - By default the `<group>` tag makes renders as grid view with 2 columns. Fix: - We us

https://www.awesomescreenshot.com/image/53256805?key=71bd00e266f6b08236b3b490b3383b78

How to reproduce:
- In the Social app, enable DEMO mode from the configuration settings.
- Now click POSTS from the menuitems available.
- Click any of the post which has been posted on about 4 accounts.
- Scroll down to find the POSTS section, where in you will see that the posts are aligned vertically.

Issue:
- By default the `<group>` tag makes renders as grid view with 2 columns.

Fix:
- We use `colspan` to merge the columns.

Task-4184968

Forward-Port-Of: odoo/enterprise#82413

There is a special case where users can make invoices "B" to foreign customers. However, we are not allowing to create credit or debit notes "B" to adjust those invoices. This PR adds the possibility to create "B" credit and debit notes (code "6" and "7" respectively) for foreign customers. _**Behavior before this PR:**_ An error message like the following was raised when validating the credit/debit note on AFIP: ``` Esto es lo que obtenemos: Observaciones de validación de la AFIP:   *

There is a special case where users can make invoices "B" to foreign customers. However, we are not allowing to create credit or debit notes "B" to adjust those invoices.
This PR adds the possibility to create "B" credit and debit notes (code "6" and "7" respectively) for foreign customers.

_**Behavior before this PR:**_
An error message like the following was raised when validating the credit/debit note on AFIP:

```
Esto es lo que obtenemos: Observaciones de validación de la AFIP: 
 * Code 10015: Para facturas B (CbteDesde igual a CbteHasta) mayor o igual a $417288, DocTipo debe ser uno de los valores devueltos por el método FEParamGetTiposDoc distinto a 99 y DocNro deberá ser mayor a 0. 
 * Code 10015: Factura B (CbteDesde igual a CbteHasta), DocTipo: 80, DocNro 0 no se encuentra registrado en los padrones de AFIP y no corresponde a una cuit pais. 
```
This happened because we have to send the "CUIT país" (vat number for the foreign country) as the customer vat so the document can be validated on AFIP. For invoices, we had the logic in the code to look for the country vat and set it in the XML we send to the organism, so I just added the related documents codes so they follow the same flow.

**_Behavior after this PR:_**
The credit/debit note should be validated on AFIP.

**_Steps to reproduce the error:_**
1) Install l10n_ar_edi
2) Set a testing enviroment 
3) Create an invoice "B" to a foreign customer. This customer won't have any VAT set. 
4) Validate the invoice
5) Create a credit note from the invoice that you created before.
6) Try to validate it, and check that an error message is raised.

Forward-Port-Of: odoo/enterprise#80169

In this commit, `position` has been replaced with `tooltipPosition`, as explained in the commit message. https://github.com/odoo/enterprise/commit/b7fc47fec39885ed1f9f99040ceaabefa539bc7b Forward-Port-Of: odoo/enterprise#82672

In this commit, `position` has been replaced with `tooltipPosition`, as explained in the commit message.

https://github.com/odoo/enterprise/commit/b7fc47fec39885ed1f9f99040ceaabefa539bc7b

Forward-Port-Of: odoo/enterprise#82672