Odoo Changelog — 2024-10-30

[FW][FIX] website: allow empty default value for model select fields

Core18.0website

When model selection field is used in a form, its default value is always one of the available values. Because of this, if the field is required, it does not force the user to pick a value, but it provides a possibly incorrect default value. This commit makes an empty value available for selection if no default value is chosen. The behavior is also made available on custom fields, if such an empty value had been manually created, it will be replaced by this implementation. Steps to

Original PR description

When model selection field is used in a form, its default value is
always one of the available values. Because of this, if the field is
required, it does not force the user to pick a value, but it provides a
possibly incorrect default value.

This commit makes an empty value available for selection if no default
value is chosen.
The behavior is also made available on custom fields, if such an empty
value had been manually created, it will be replaced by this
implementation.

Steps to reproduce:
- Install website_form_project
- Add a form in a page
- Select the "Create a Task" action
- Add the "Analytic Account" field to the form
- Make the field required

=> There was no way to have no default value by default.

opw-4268164

Forward-Port-Of: odoo/odoo#185532
Forward-Port-Of: odoo/odoo#184842

[FW][FIX] base: compare email_normalized for {email/smtp}_from

PR #185865

Core18.0

Use normalized emails for comparison to avoid issues linked to formatting. Task-4281171: [mail] {email/smtp}_from normalized comparison Forward-Port-Of: odoo/odoo#185766 Forward-Port-Of: odoo/odoo#185749

Original PR description

Use normalized emails for comparison to avoid issues linked to formatting.

Task-4281171: [mail] {email/smtp}_from normalized comparison

Forward-Port-Of: odoo/odoo#185766
Forward-Port-Of: odoo/odoo#185749

[FW][FIX] point_of_sale: fetch paid orders from database when searching

PR #185737

Core18.0point_of_sale

Before this commit, opening the paid orders and searching for an existing order would not fetch the orders from the database. opw-4276187 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#185528

Original PR description

Before this commit, opening the paid orders and searching for an existing order would not fetch the orders from the database.

opw-4276187

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

Forward-Port-Of: odoo/odoo#185528

[FW][FIX] stock: start SML from sub location

PR #185870

Core18.0stock

On a stock move, when using a lot from a sub-location, the created SML will still start from SM's source location instead of lot's location To reproduce the issue: 1. In Settings, enable "Storage Locations" 2. Create a tracked-by-sn product P 3. Update its qty: - SN01 at WH/Stock - SN02 at WH/Stock/Shelf 1 4. Confirm a delivery with 1 x P 5. Enable the column "Serial Number" - SN01 should be present 6. Remove SN01, set SN02 7. Validate the transfer 8. Open the detailed op

Original PR description

On a stock move, when using a lot from a sub-location, the created SML will still start from SM's source location instead of lot's location To reproduce the issue: 1. In Settings, enable "Storage…

On a stock move, when using a lot from a sub-location, the created
SML will still start from SM's source location instead of lot's location

To reproduce the issue:
1. In Settings, enable "Storage Locations"
2. Create a tracked-by-sn product P
3. Update its qty:
   - SN01 at WH/Stock
   - SN02 at WH/Stock/Shelf 1
4. Confirm a delivery with 1 x P
5. Enable the column "Serial Number"
   - SN01 should be present
6. Remove SN01, set SN02
7. Validate the transfer
8. Open the detailed operations

Result: SN02 has been taken from WH/Stock, but the user probably
wanted to use the existing one, in WH/Stock/Shelf 1.

An onchange already exists to make sure that the user is not using a
lot that already exists somewhere else. Before Odoo 17.2, we were
considering the sub locations as not expected:
https://github.com/odoo/odoo/blob/d5a7a3d02e3e2b4e47977abc8b9fc0d5d6135937/addons/stock/models/stock_move.py#L1167
But since Odoo 17.2 (via [1]), we now also accept the sub locations:
https://github.com/odoo/odoo/blob/60b0bafc8abd1893c9cdd9913617c234692369cf/addons/stock/models/stock_move.py#L1242

This is a bit confusing because we don't display any warning anymore,
but we don't select the correct source location neither. The commit
should help the user and avoid that confusion

[1] https://github.com/odoo/odoo/commit/99b39b72c7e65e85af6f06dcb6b02867623f3f69

OPW-4231749

Forward-Port-Of: odoo/odoo#185796

[FW][FIX] website_event_sale: check seats availability before payment

PR #185845

Core18.0website_event_sale

Steps to reproduce: - Install `website_event_sale` - Go to an event and for one ticket set maximum as 1 - Open event page and purchase a ticket, but don't complete the payment - Do the same in private navigation - Click on pay on the two page Issues: If you check with stripe payment is processed meaning that the two people are charged however one of them can't get a ticket as there isn't enough tickets available. Fix is to check before sending payment to provider and return error if the

Original PR description

Steps to reproduce:
- Install `website_event_sale`
- Go to an event and for one ticket set maximum as 1
- Open event page and purchase a ticket, but don't complete the payment
- Do the same in private navigation
- Click on pay on the two page

Issues:
If you check with stripe payment is processed meaning that the two people are charged however one of them can't get a ticket as there isn't enough tickets available. Fix is to check before sending payment to provider and return error if there's not enough seats. Concurrency issue is not fully solved but would require much more precise timing, and a proper solution wouldn't be stable.

opw-3772093

Forward-Port-Of: odoo/odoo#185698
Forward-Port-Of: odoo/odoo#173809

[FW][FIX] packaging: update windows installer logo

PR #185746

Core18.0

Update branding logo and icon in windows installer. Old forgotten task Task-2862802 Forward-Port-Of: odoo/odoo#185650

Original PR description

Update branding logo and icon in windows installer.

Old forgotten task

Task-2862802

Forward-Port-Of: odoo/odoo#185650

[FW][FIX] mail: public channel fetching and real-time messaging

PR #185832

Core18.0mail

**Current behavior before PR:** Public channels were not being fetched when users clicked channel mentions, causing chat window title to display "New message" instead of their actual names. Additionally, bus channels were not added every time when threads were opened, preventing real-time messaging in some cases. **Desired behavior after PR is merged:** Implemented channel fetching on mention clicks and added bus channel subscription when opening threads, enabling proper channel nam

Original PR description

**Current behavior before PR:**

Public channels were not being fetched when users clicked channel mentions,
causing chat window title to display "New message" instead of their actual names.
Additionally, bus channels were not added every time when
threads were opened, preventing real-time messaging in some cases.

**Desired behavior after PR is merged:**

Implemented channel fetching on mention clicks and added bus channel
subscription when opening threads, enabling proper channel name display
and real-time messaging functionality.



Task:[3899453](https://www.odoo.com/odoo/project/1519/tasks/3899453)

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

Forward-Port-Of: odoo/odoo#185697
Forward-Port-Of: odoo/odoo#174473

[FW][FIX] gamification: fix traceback when user deletes a module having gamification record

PR #185794

Core18.0gamification

Currently, a traceback occurs when the user deletes a module which is having a gamification goal record. To reproduce this issue: 1) Install `sale` and `gamification` 2) Create a new `gamification challenge` record 3) Create a new `goal` in the gamification challenge 4) Make sure the goal has the definition as `Automatic: sum on a field` 5) Select the model as `account` 6) Uninstall the invoicing module and start the `challenge` of that gamification. Error:- ``` KeyError: Fals

Original PR description

Currently, a traceback occurs when the user deletes a module which is having a gamification goal record. To reproduce this issue: 1) Install `sale` and `gamification` 2) Create a new `gamification…

Currently, a traceback occurs when the user deletes a module which is having a gamification goal record.

To reproduce this issue:

1) Install `sale` and `gamification`
2) Create a new `gamification challenge` record
3) Create a new `goal` in the gamification challenge 
4) Make sure the goal has the definition as `Automatic: sum on a field` 
5) Select the model as `account`
6) Uninstall the invoicing module and start the `challenge` of that gamification.

Error:- 
```
KeyError: False
```

The value of the model_id became `False` when the user deletes a module used in goal.

This leads to a traceback as model_id is used for the reference of obj 

https://github.com/odoo/odoo/blob/d9603e93d2ab5e0b9fd1948dfd3e3bee20ede599/addons/gamification/models/gamification_goal.py#L164-L165

We can resolve this issue by adding `ondelete='cascade'` in the field
definition. Where the record will be deleted if the corresponding model is 
uninstalled.  

sentry-4089991441

Forward-Port-Of: odoo/odoo#180307

[FW][FIX] mrp: unlink archived operations from byproducts

PR #185651

Core18.0mrp

When archiving an operation in a bom, currently it will unlink if from bom lines that had it set as their `Consumed in Operation`. However, it's not the case for byproducts, meaning that the byproducts lines will still display the now archived operation. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#185390 Forward-Port-Of: odoo/odoo#185093

Original PR description

When archiving an operation in a bom, currently it will unlink if from bom lines that had it set as their `Consumed in Operation`.

However, it's not the case for byproducts, meaning that the byproducts lines will still display the now archived operation.

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

Forward-Port-Of: odoo/odoo#185390
Forward-Port-Of: odoo/odoo#185093

[FW][FIX] stock: add default value to Selection fields

PR #185607

Core18.0stock

Adds default value to a few required selection fields as currently a value is apparently set in the form (as the select field will pick the first value) but without having the value really set in the field, meaning that on save, the field will appear as invalid. Also, to be able to select the "almost default" value, you'd need to select another value then pick the first value again to properly set it in the field and be able to save the form. To avoid those issue, we can add a default value t

Original PR description

Adds default value to a few required selection fields as currently a value is apparently set in the form (as the select field will pick the first value) but without having the value really set in the field, meaning that on save, the field will appear as invalid. Also, to be able to select the "almost default" value, you'd need to select another value then pick the first value again to properly set it in the field and be able to save the form.

To avoid those issue, we can add a default value to those fields corresponding to the current "default" value in the form.

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

Forward-Port-Of: odoo/odoo#185477
Forward-Port-Of: odoo/odoo#184939

[FW][FIX] web_editor, html_editor: remove ufeff characters when copying

PR #184519

Core18.0html_editorweb_editor

Issue: ====== clipboard data has ufeff characters in it. Steps to reproduce the issue: ============================= - Create a new note/todo - Add a link - Copy it - Visualise the data copied - It contains ufeff characters of the link Solution: ========= for web_editor: We remove the characters fron the text and html we put in the clipboard data. for html_editor: We dispatch a CLEAN command before selecting the content and we handle it by link_selection_plugin and we norm

Original PR description

Issue:
======
clipboard data has ufeff characters in it.

Steps to reproduce the issue:
=============================
- Create a new note/todo
- Add a link
- Copy it
- Visualise the data copied
- It contains ufeff characters of the link

Solution:
=========
for web_editor:
We remove the characters fron the text and html we put in the clipboard
data.

for html_editor:
We dispatch a CLEAN command before selecting the content and we handle
it by link_selection_plugin and we normalize after after cloning the
content

opw-4029722

Forward-Port-Of: odoo/odoo#184372
Forward-Port-Of: odoo/odoo#182596

[FW][PERF] stock: lower limit for report_stock_quantity

PR #185740

Core18.0stock

Currently the `report_stock_quantity` view third `UNION ALL` does a `generate_series` between the moves date and `now()` in case the move is not in done. This can lead to significant slowdowns when querying the view in case some databases have old moves not in done, cancel, draft. In that case, the report will generate a row for each day between the move.date and `now()`, leading to thousands of rows for 1 stock.move. To alleviate that, this commit uses the `report_period` as a lower bound

Original PR description

Currently the `report_stock_quantity` view third `UNION ALL` does a `generate_series` between the moves date and `now()` in case the move is not in done.

This can lead to significant slowdowns when querying the view in case some databases have old moves not in done, cancel, draft. In that case, the report will generate a row for each day between the move.date and `now()`, leading to thousands of rows for 1 stock.move.

To alleviate that, this commit uses the `report_period` as a lower bound. This greatly reduces the number of rows generated by the third `UNION ALL` without losing forecasted accuracy since the moves are not in done.

#### speedup

In a v17 database where `all_sm` returns 600 000 rows, querying the `report_stock_quantity` view goes from 20s -> 7s.


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

Forward-Port-Of: odoo/odoo#184998
Forward-Port-Of: odoo/odoo#179359

[FW][FIX] account: fix balance / amount_currency sync during write

PR #185775

Core18.0account

Currently it can happen that slightly changing the amount in (document) currency (field `amount_currency`) i.e. on a tax line can lead to an unbalanced move. (See example and "Reproduce" below.) The issue is the syncing (function `_sync_invoice`) between - amount in currency (document currency; field `amount_currency`) and - balance (company currency; field `balance`). There we update the amount in currency in case the balance is changed and the amount in currency is not changed. But

Original PR description

Currently it can happen that slightly changing the amount in (document) currency (field `amount_currency`) i.e. on a tax line can lead to an unbalanced move. (See example and "Reproduce" below.) The…

Currently it can happen that slightly changing the amount in (document)
currency (field `amount_currency`) i.e. on a tax line can lead to an
unbalanced move. (See example and "Reproduce" below.)

The issue is the syncing (function `_sync_invoice`) between
- amount in currency (document currency; field `amount_currency`) and
- balance (company currency; field `balance`).

There we update the amount in currency in case the balance is changed
and the amount in currency is not changed.
But this is problematic in case we want (in the same write) set
a different amount in currency but explicitly set the same balance
(and not just not write anything to the `balance` field).
Since we write the same balance it is not detected as a
change and we update the balance based on the amount in currency.
But this should not happen; the balance should be "protected"
from being updated (since it is the value we explicitly want).

This can i.e. cause the balance of the receivable line to receive the wrong value
I.e. consider the following case; with currency rate = 2 (also see "Reproduce" below)

Journal Items:
- product  1: amount in currency = -1000.00 €, balance = -500.00
- product  2: amount in currency =  -200.00 €, balance = -100.00
- tax line 1: amount in currency =  -180.03 €, balance =  -90.02
- tax line 2: amount in currency =   -30.00 €, balance =  -15.00
- Receivable: amount in currency = -1410.03 €, balance =  705.02

And we modify tax line 2: amount in currency = -29.99 €.
Then first we set the correct values because we basically compute the
receivable line by summing the other lines:

Journal Items:
- product  1: amount in currency = -1000.00 €, balance = -500.00
- product  2: amount in currency =  -200.00 €, balance = -100.00
- tax line 1: amount in currency =  -180.03 €, balance =  -90.02
- tax line 2: amount in currency =   -29.99 €, balance =  -15.00
- Receivable: amount in currency = -1410.02 €, balance =  705.02

So we have set the balance to the same as before but changed the
amount in currency. So then we recompute the balance on the receivable
line from the amount in currency due to the syncing (`_sync_invoice`)

Journal Items:
- product  1: amount in currency = -1000.00 €, balance = -500.00
- product  2: amount in currency =  -200.00 €, balance = -100.00
- tax line 1: amount in currency =  -180.03 €, balance =  -90.02
- tax line 2: amount in currency =   -29.99 €, balance =  -15.00
- Receivable: amount in currency = -1410.02 €, balance =  705.01

But now the move is not balanced (the sum of the balances should be 0)
  -500.00 + -100.00 + -90.02 + -15.00 = -705.02 (and not -705.01)

After this commit we "protect" the balance and amount in currency from
being updated by `_sync_invoice` in case the surrounding `write`
sets the balance (`balance`) or amount in currency (`amount_currency`)
respectively.

Reproduce: (c.f. example above)
  1. Select company "My Company (San Francisco)"
  2. Ensure EUR currency is activated and has value 2 unit per USD
     (at the time of the invoice that will be created further below)
  3. Copy the 15% tax
  4. Create a new invoice in EUR with 2 lines
     (1) qty = 1, unit price = 1000, taxes = 15%
     (2) qty = 1, unit price = 200, taxes = 15%, 15% (Copy)
  5. There should be 2 tax lines in the "Journal Items" tab
     (1) amount in currency = -180.00 €, credit = 90.00 USD
     (2) amount in currency = -30.00 €, credit = 90.00 USD
  6. Modify tax line (1); set amount in currency to -180.03 €
     and save.
     The credit will be updated to 90.02 USD.
  7. Modify tax line (2); set amount in currency to -29.99 €
     and try to save
  8. An "Invalid Operation" error is raised:
     The move (Draft Invoice ) is not balanced.
     The total of debits equals $ 705.01 and the total of credits equals $ 705.02.

Forward-Port-Of: odoo/odoo#185757
Forward-Port-Of: odoo/odoo#171705

**Note** 
Compared to previous versions the `amount_currency` is not updated
anymore in `_sync_invoice` (only the `balance`).

[FW][IMP] account: better error message when using inconsistent payment account on sale/purchase invoice

PR #185773

Core18.0account

Before this commit, when a payable account was used on a customer invoice, or a receivable account on a vendor bill, an error message was raised saying "Any journal item on a receivable/payable account must have a due date and vice versa.". This was unclear, and caused for example confusion when importing the accounting history. Therefore, we now handle this case with a new error message. opw-4196597 Forward-Port-Of: odoo/odoo#185696 Forward-Port-Of: odoo/odoo#182979

Original PR description

Before this commit, when a payable account was used on a customer invoice, or a receivable account on a vendor bill, an error message was raised saying "Any journal item on a receivable/payable account must have a due date and vice versa.". This was unclear, and caused for example confusion when importing the accounting history. Therefore, we now handle this case with a new error message.

opw-4196597

Forward-Port-Of: odoo/odoo#185696
Forward-Port-Of: odoo/odoo#182979

[FW][FIX] website: fix highlighted field update and synchronization conflict

PR #185427

Core18.0website

Steps to reproduce: 1. Go to a website page (in edit mode) > Switch the header template to `"Menu with Search Bar"`. 2. Set a highlight effect on the text element in the top section of the header. 3. The highlight keeps adapting itself infinitely. Technical details: After [1], two header navbars were added in the DOM (for the desktop view and mobile). Which means that the targeted text field is also duplicated and every change on it in Desktop will be reflected in the "invisib

Original PR description

Steps to reproduce: 1. Go to a website page (in edit mode) > Switch the header template to `"Menu with Search Bar"`. 2. Set a highlight effect on the text element in the top section of the header. 3.…

Steps to reproduce:

1. Go to a website page (in edit mode) > Switch the header template to
`"Menu with Search Bar"`.

2. Set a highlight effect on the text element in the top section of the header.

3. The highlight keeps adapting itself infinitely.

Technical details:

After [1], two header navbars were added in the DOM (for the desktop
view and mobile). Which means that the targeted text field is also
duplicated and every change on it in Desktop will be reflected in the
"invisible" mobile version.

When the text is highlighted, the highlight observers are also adapting
the content on both navbars... To understand the conflict, here is an
example of the behaviour causing the infinite loop:

**a.** DESKTOP TEMPLATE > Set a highlight on the text field:
```xml
   <span class="o_text_highlight">
    <span class="o_text_highlight_item">
        Text content.
        <svg.../> // SVG adapted to text dimensions.
    </span>
```

**b.** MOBILE TEMPLATE > The "field observer" will set the same content on
the "invisible" mobile version:
```xml
   <span class="o_text_highlight">
    <span class="o_text_highlight_item">
        Text content.
        <svg.../> // SVG adapted to the desktop text dimensions.
    </span>
```

**c.** MOBILE TEMPLATE > The "highlights adaptation system" detects the
changes on the hidden mobile field and adapts the highlight:
```xml
   <span class="o_text_highlight">
    <span class="o_text_highlight_item">
        Text content.
        <svg.../> // SVG adapted to the mobile text dimensions (0×0).
    </span>
```

**d.** DESKTOP TEMPLATE > The "field observer" will set the same content on
the desktop version, which automatically triggers the highlight size adaptations...

**e.** Same as [**b**].

Infinitely...

In this very specific case, the text content is the same, only the
highlight path is different (because one of the field duplicates is
visible, and the other is hidden).

The goal of this commit is to fix this behaviour by preventing the
highlight's mutation observer from adapting invisible content.

This way, the field synchronization mechanism will always set the same
highlight SVG on the hidden duplicate too (*).

[1]: https://github.com/odoo/odoo/pull/119650

(*): Remarks:

- This won't have an impact on the saved content: We remove all size
related DOM (SVG paths, line breaks,...) before the "save" and we
only keep minimal information needed to rebuild the highlights.

- Also, having a non-adapted effect on the hidden copy of the field is
not an issue here since the "highlight resize observer" will immediately
fix it once displayed (e.g. when switching to mobile preview).

opw-4183587
task-4270159

Forward-Port-Of: odoo/odoo#183414

[FW][FIX] payment_adyen: add idempotency key for customer-initiated payments

PR #185776

Core18.0payment_adyen

Payments initiated by the customer from the payment form could sometimes lead to multiple charges if a webhook notification would arrive at the same time as the payment request's response. This is due to the webhook acquiring a lock in the database when updating the transaction's state, followed by the processing of the payment request's response trying to do the same and thus encountering a concurrent access error. The payment request is thus retried and a new charge is created on Adyen side.

Original PR description

Payments initiated by the customer from the payment form could sometimes lead to multiple charges if a webhook notification would arrive at the same time as the payment request's response. This is due to the webhook acquiring a lock in the database when updating the transaction's state, followed by the processing of the payment request's response trying to do the same and thus encountering a concurrent access error. The payment request is thus retried and a new charge is created on Adyen side.

This commit fixes the issue by passing an idempotency key with the payment request. If a payment request is inadvertently retried, Adyen silently ignores it and returns the same response as for the initial request. The response is processed again in Odoo and the customer is smoothly redirected to the payment landing page.

Forward-Port-Of: odoo/odoo#185720
Forward-Port-Of: odoo/odoo#184919

[FW][FIX] event_crm: improve multi registrations grouping

PR #185285

Core18.0event_crmwebsite_event_crm

When being order-based, several registrations are used to create a new lead. In some cases we might end up with several possible langs due to multiple visitors. We should take the first found one, as lang is a m2o on lead model. When running on registrations without linked SO, registrations are grouped by "event" in case of group-based lead generation. We should also group by create_date, as same event - same create_date indicates tickets belong to the same "group". Task-3940853 C

Original PR description

When being order-based, several registrations are used to create a new
lead. In some cases we might end up with several possible langs due
to multiple visitors. We should take the first found one, as lang is
a m2o on lead model.

When running on registrations without linked SO, registrations are
grouped by "event" in case of group-based lead generation. We should
also group by create_date, as same event - same create_date indicates
tickets belong to the same "group".

Task-3940853

Co-Authored-By: Jeremy Hennecart <jeh@odoo.com>

Forward-Port-Of: odoo/odoo#185154
Forward-Port-Of: odoo/odoo#182138

[FW][FIX] web: keep nosheet style if a sheet is present in a nested form

PR #185734

Core18.0web

Steps to reproduce ================== - Install stock,mrp,web_studio - Go to Inventory > Delivery Orders - Open WH/OUT/00001 - Open studio - On the x2many field, click on "Edit form" -> Studio switches to that view, - Click on "Edit form" again for the new lines - Exit studio - Click on the hamburger button -> The styling is broken Cause of the issue ================== When clicking on "Edit form", studio inlines the selected form view. The nosheet form style is only applied if

Original PR description

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

- Install stock,mrp,web_studio
- Go to Inventory > Delivery Orders
- Open WH/OUT/00001
- Open studio
- On the x2many field, click on "Edit form" -> Studio switches to that view,
- Click on "Edit form" again for the new lines
- Exit studio
- Click on the hamburger button -> The styling is broken

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

When clicking on "Edit form", studio inlines the selected form view. The nosheet form style is only applied if the form contains no sheet element.

In this case, there is a sheet element, but inside a nested form.

Solution
========

Only consider sheets if they are part of the current form view.

opw-4130337

Forward-Port-Of: odoo/odoo#185616
Forward-Port-Of: odoo/odoo#185504

[FW][FIX] auth_signup: Password reset email template translation

PR #184999

Core18.0auth_signup

The password reset email was not being translated according to the receiver's language. This caused the template to render in the website language, leading to confusion for receivers with different language. The problem came form Convert the "Reset Password" template into QWeb view in https://github.com/odoo/odoo/pull/125874, Before, to sent the email `mail.send_mail()` function was used, and it has a check for the receiver language. and after https://github.com/odoo/odoo/pull/125874 th

Original PR description

The password reset email was not being translated according to the receiver's language. This caused the template to render in the website language, leading to confusion for receivers with different…

The password reset email was not being translated according to the receiver's language. This caused the template to render in the website language, leading to confusion for receivers with different language.

The problem came form Convert the "Reset Password" template into QWeb view in https://github.com/odoo/odoo/pull/125874,    Before, to sent the email  `mail.send_mail()`  function was used, and it has a check for the receiver language. and after  https://github.com/odoo/odoo/pull/125874 the function wasnt used any more. it replaces with `mail.send()` that send the rendered content directly.

To resolve this issue, the language of the receiver user is explicitly set in the context before rendering the email template. This ensures the email content is translated based on the user's preferred language then calling the function that send it. 

Now the template is rendered using the receiver's language (`user.lang`), or falls back to the website language `self.env.lang` if the receiver's language is not set. Or falls back to  'en_US' if the language is not set.

owp-4149894


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

Forward-Port-Of: odoo/odoo#182635

[FW][FIX] l10n_fr_facturx_chorus_pro: udpate PartyIdentification tag

PR #185721

Core18.0l10n_fr_facturx_chorus_pro

Currently, when sending a Bis 3 xml to Pagero, which in turn sends it to Chorus Pro, the invoice is rejected by Chorus. This is because the `PartyIdentification` tag for the `AccountingSupplierParty` should be filled with the siret of the supplier if it is located in France, or with the VAT if it is located in the EU. Surprisingly, the xml received by Chorus contains a `PartyIdentification` that has most probably be added by Pagero, but it is filled with a VAT, and causes a rejection from

Original PR description

Currently, when sending a Bis 3 xml to Pagero, which in turn sends it to Chorus Pro, the invoice is rejected by Chorus.

This is because the `PartyIdentification` tag for the `AccountingSupplierParty` should be filled with the siret of the supplier if it is located in France, or with the VAT if it is located in the EU.

Surprisingly, the xml received by Chorus contains a `PartyIdentification` that has most probably be added by Pagero, but it is filled with a VAT, and causes a rejection from Chorus since the supplier is french.

opw-4139689

Forward-Port-Of: odoo/odoo#184871

[FW][FIX] mrp_{subcontracting_dropshipping,account}: use comp qty in price unit calc

PR #185505

Core18.0mrp_accountmrp_subcontracting_dropshipping

**Current behavior:** Selling a kit bom product will result in inaccurate journal entries in the stock output and expense accounts, the amount_currency field will only reflect the price unit of the kit's components. **Expected behavior:** The price unit should reflect the total cost of the components on the BoM: e.g., if a kit product needs 4 of some component1, the price unit should be 4 * component1.standard_price. **Steps to reproduce:** 1. Create a kit product with 2 components, bot

Original PR description

**Current behavior:** Selling a kit bom product will result in inaccurate journal entries in the stock output and expense accounts, the amount_currency field will only reflect the price unit of the…

**Current behavior:**
Selling a kit bom product will result in inaccurate journal entries in the stock output and expense accounts, the amount_currency field will only reflect the price unit of the kit's components.

**Expected behavior:**
The price unit should reflect the total cost of the components on the BoM: e.g., if a kit product needs 4 of some component1, the price unit should be 4 * component1.standard_price.

**Steps to reproduce:**
1. Create a kit product with 2 components, both with qty > 1

2. Assign dropshipping to the kit

3. Create a sale order and confirm -> confirm the purchase order

4. Validate the dropship transfer, invoice the sale order and post it

5. See the 2 inaccurate journal entries, where the debit/credit respectively only total to one instance of each component's cost added together

**Cause of the issue:**
The price unit calculation didn't look at the bom line product qty, only using the price unit 1 time per component.

**Fix:**
Multiply the value by the quantity of it required on its line in the BoM.

opw-4253827

Forward-Port-Of: odoo/odoo#185247
Forward-Port-Of: odoo/odoo#183916

[FW][FIX] payment_adyen: set holder name required

PR #185732

Core18.0payment_adyen

As VISA added more mandatory fields to perform payments, the holder's name is required now for the customer to fill when paying with adyen. opw-4085163 Forward-Port-Of: odoo/odoo#185489 Forward-Port-Of: odoo/odoo#185253

Original PR description

As VISA added more mandatory fields to perform payments, the holder's name is required now for the customer to fill when paying with adyen.

opw-4085163

Forward-Port-Of: odoo/odoo#185489
Forward-Port-Of: odoo/odoo#185253

[FW][ADD] l10n_my_edi: Malaysian E-Invoicing

PR #185762

Core18.0account_edi_ubl_ciil10n_my_edil10n_my_ubl_pint

Add support for connecting to the MyInvois API, in order to send and receive E-Invoices. see https://github.com/odoo/iap-apps/pull/849 Task id # 3953659 Forward-Port-Of: odoo/odoo#174813

Original PR description

Add support for connecting to the MyInvois API, in order to send and receive E-Invoices.

see https://github.com/odoo/iap-apps/pull/849

Task id # 3953659

Forward-Port-Of: odoo/odoo#174813

[FW][FIX] l10n_in_edi_ewaybill: fix the ewaybill name log

PR #185778

Core18.0l10n_in_edi_ewaybill

Issue found at commit: https://github.com/odoo/odoo/commit/0e8f3d5c42b4f219e4e7db6915dd1dd7ec45e4b4 After the above mentioned commit when using eWaybill with e-Invoicing the log note of ewaybill i.e. ``` E-wayBill Sent Number -> 0 Validity -> None ``` ![image](https://github.com/user-attachments/assets/d1d3d58c-f54e-4a74-b803-3f6384a246eb) where as in the response attachment of eWaybill, the ewaybill number does exist In this commit, we resolve the above issue and the correct ewaybil

Original PR description

Issue found at commit: https://github.com/odoo/odoo/commit/0e8f3d5c42b4f219e4e7db6915dd1dd7ec45e4b4 After the above mentioned commit when using eWaybill with e-Invoicing the log note of ewaybill i.e.
```
E-wayBill Sent
Number -> 0
Validity -> None
```
![image](https://github.com/user-attachments/assets/d1d3d58c-f54e-4a74-b803-3f6384a246eb)

where as in the response attachment of eWaybill, the ewaybill number does exist

In this commit, we resolve the above issue and the correct ewaybill number gets logged

opw-4280093

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

[FW][FIX] account_accountant: Add period condition in Deferred Expense Report

PR #73099

Enterprise18.0

Version: 17.0+ Issue: In the Deferred Expense Report, there is a missing check for if the `period_end` is before the `period_start` for when the deferred method is 'day'. If the `period_end` is in the same month as selected month of the report, the later column will compute the amount to be negative of the `amount_per_day` times the difference of days. For example, if the end date is 2024-11-04 and we look at the month of November, the later column will display the negative amount of 26

Original PR description

Version: 17.0+

Issue:
In the Deferred Expense Report, there is a missing check for if the `period_end` is before the `period_start` for when the deferred method is 'day'. If the `period_end` is in the same month as selected month of the report, 
the later column will compute the amount to be negative of the `amount_per_day` times the difference of days. 
For example, if the end date is 2024-11-04 and we look at the month of November, the later column will display the negative amount of 26 days. In this example the amount is expected to be 0.

Purpose of this PR:
To add an additional condition, if the `period_end` is before the `period_start` then the amount should be 0.

opw-4231549

Forward-Port-Of: odoo/enterprise#72644

[FW][FIX] pos_restaurant_appointment: show today appointment on floor screen

PR #72784

Enterprise18.0

Before this commit, next appointment was shown on a table even if this appointment was not for today. We not only allow to show today's appointment on the floor screen. task-id: 4285487 Forward-Port-Of: odoo/enterprise#72762

Original PR description

Before this commit, next appointment was shown on a table even if this appointment was not for today. We not only allow to show today's appointment on the floor screen.

task-id: 4285487

Forward-Port-Of: odoo/enterprise#72762

[FW][IMP] l10n_ar_edi: manage 10016 afip error.

PR #73013

Enterprise18.0

This pr is created to help de user to know the origin of the afip error 10016. The error 10016 can be caused by different origins, so here we give the user more precision about the origin. The objective of this pr is to be able to differentiate what is the origin of error 10016 and to be able to give a more precise message to the client. 1) If the last afip invoice validated has a higher date than the date of the invoice that is being validated then the message shown to the user is '10016-

Original PR description

This pr is created to help de user to know the origin of the afip error 10016. The error 10016 can be caused by different origins, so here we give the user more precision about the origin. The…

This pr is created to help de user to know the origin of the afip error 10016.

The error 10016 can be caused by different origins, so here we give the user more precision about the origin. The objective of this pr is to be able to differentiate what is the origin of error 10016 and to be able to give a more precise message to the client.

1) If the last afip invoice validated has a higher date than the date of the invoice that is being validated then the message shown to the user is '10016-1': 'The invoice date cannot be after the last invoice validated in AFIP.'

2) If the last afip invoice number is higher than the current invoice number being validated in Odoo, then the message shown to the user is '10016-2': 'There may have been a mismatch in the numbering of this type of document between Odoo and AFIP.'

3) If any other reason cause the error '10016' then the message shown to the user is:
    * Please note that if you are trying to validate an invoice with a date other than today, you must verify if it falls within the date range according to the AFIP concept or document type:

    a) If it is Product: N+5 or N-5 with N being today's date.
    b) If it is Services or Products and services: N+10 or N-10 with N being today's date.
    c) If it is a MiPyme Invoice: N-5 0 N+1 with N being today's date. For Debit Note or Credit Note only N-5"

Task Adhoc side: 37771
Task latam side: 1194

This pr replaces https://github.com/odoo/enterprise/pull/65675

Forward-Port-Of: odoo/enterprise#72901
Forward-Port-Of: odoo/enterprise#72656

[FW][IMP] l10n_ar_reports: VAT Book: use load_more_limit

PR #73012

Enterprise18.0

When this report contained too many lines (~6000), the browser couldn't handle the load and did not manage to render it. This is a known case, which normally only happens with line expansion, for which the prefix groups and load more features have been made. In this case, though, it's a bit different, as those lines are directly at the root of the report (they don't come from a line expansion). We make the choice here to use the load_more_limit anyway as a means to put a limit to the number of l

Original PR description

When this report contained too many lines (~6000), the browser couldn't handle the load and did not manage to render it. This is a known case, which normally only happens with line expansion, for…

When this report contained too many lines (~6000), the browser couldn't handle the load and did not manage to render it. This is a known case, which normally only happens with line expansion, for which the prefix groups and load more features have been made. In this case, though, it's a bit different, as those lines are directly at the root of the report (they don't come from a line expansion). We make the choice here to use the load_more_limit anyway as a means to put a limit to the number of lines that are shown.

When this limit is reached, we just don't display the exceeding lines, and replace them by a summary line.

To avoid confusion, a warning is now shown on top of the report when some lines need to be hidden. Since such a warning requires a module update (because it's a template, and needs to exist in db), we only apply our new trimming mechanism if the warning template exists (and can hence be displayed). This way, we won't change the behavior on existing databases without being sure the user is properly notified. Plus, thanks to that, we're sure the old load_more_limit value (originally 80 by default) set on the VAT Book will have been increased to a value fitting our use case more, so we won't bother people with excessive trimming.

Original fix suggestion raised here by Adhoc: https://github.com/odoo/enterprise/pull/45936

Forward-Port-Of: odoo/enterprise#72836
Forward-Port-Of: odoo/enterprise#72096

[FW][FIX] delivery_ups_rest: correct shipper on return label

PR #73026

Enterprise18.0

**Current behavior:** Return labels are being generated with the `shipper` field set to the partner defined on the delivery picking (i.e., customer). **Expected behavior:** `shipper` should match the `ship_to` field (the original sender) as this field informs who gets billed for the return shipment. **Steps to reproduce:** Generate a return label with `delivery_ups_rest`. **Cause of the issue:** The return label is generated with `shipper=picking.partner_id`. **Fix:** Set it to

Original PR description

**Current behavior:**
Return labels are being generated with the `shipper` field set to the partner defined on the delivery picking (i.e., customer).

**Expected behavior:**
`shipper` should match the `ship_to` field (the original sender) as this field informs who gets billed for the return shipment.

**Steps to reproduce:**
Generate a return label with `delivery_ups_rest`.

**Cause of the issue:**
The return label is generated with `shipper=picking.partner_id`.

**Fix:**
Set it to
`shipper=picking.picking_type_id.warehouse_id.partner_id` (which matches the `ship_to` argument).

opw-4147118

Forward-Port-Of: odoo/enterprise#72482

[FW][DRAFT][FIX] web_studio: previous button appears in right direction

PR #72919

Enterprise18.0

Before this commit currently when creating a new app using Studio the previous button icon in the navbar appears in the wrong direction After this commit The previous button icon should appear in the right direction Task - 3845561 Forward-Port-Of: odoo/enterprise#72674 Forward-Port-Of: odoo/enterprise#61835

Original PR description

Before this commit

currently when creating a new app using Studio the previous button icon in the navbar appears in the wrong direction

After this commit

The previous button icon should appear in the right direction

Task - 3845561

Forward-Port-Of: odoo/enterprise#72674
Forward-Port-Of: odoo/enterprise#61835

[FW][FIX] l10n_fr_hr_payroll: revert translation of salay rule codes

PR #73005

Enterprise18.0

Steps to reproduce: - Switch to 'FR company' > New employee > New contract (Use defaults) - Payroll app > Payslips > All Payslips - New Payslip for your employee using a french structure (like 'cadre') - Compute sheet > Salary computation tab - (Maybe set 'Salary Journal' in Configuration > Structures if needed) Salary rule codes were translated leading to confusion in the fields to fetch when computing payroll sheets. opw-4240326 Forward-Port-Of: odoo/enterprise#72872

Original PR description

Steps to reproduce:
- Switch to 'FR company' > New employee > New contract (Use defaults)
- Payroll app > Payslips > All Payslips
- New Payslip for your employee using a french structure (like 'cadre')
- Compute sheet > Salary computation tab
- (Maybe set 'Salary Journal' in Configuration > Structures if needed)

Salary rule codes were translated leading to confusion in the fields to fetch when computing payroll sheets.

opw-4240326

Forward-Port-Of: odoo/enterprise#72872

[FW][FIX] account_accountant: change order to check for Sign install

PR #72982

Enterprise18.0

**Steps to reproduce:** - Install Accounting - Go to Accounting settings - Disable "Checks" option (A warning pops up infoming that "account_check_printing" module will be uninstalled) - Save **Issue:** A traceback is raised because it tries to access some fields that are defined in "account_check_printing" module. **Cause:** After uninstallation of "account_check_printing" module, the settings page is reloaded. However, this reload is performed with an old version of the env where

Original PR description

**Steps to reproduce:** - Install Accounting - Go to Accounting settings - Disable "Checks" option (A warning pops up infoming that "account_check_printing" module will be uninstalled) - Save…

**Steps to reproduce:**
- Install Accounting
- Go to Accounting settings
- Disable "Checks" option (A warning pops up infoming that "account_check_printing" module will be uninstalled)
- Save

**Issue:**
A traceback is raised because it tries to access some fields that are defined in "account_check_printing" module.

**Cause:**
After uninstallation of "account_check_printing" module, the settings page is reloaded.
However, this reload is performed with an old version of the env where the fields defined in the uninstalled module are still there. It's coming from an override of "execute" method of "res.config.settings" defined in Accounting module.
This override is checking if "sign_invoice" field is enable in order to install Sign module.
This action is performed after the "execute" on "super()". If the "execute" is uninstalling a module, the "env" is reset as some models or fields may not be present anymore.
However, in the override of the "execute" method, the old "env" is still used and non-existent fields are prefetched.

**Solution:**
Check to install Sign module in the override of "execute" method before executing the one from "super()" to prevent using an expired "env".

opw-4251932

Forward-Port-Of: odoo/enterprise#72227

[FW][FIX] sign: assign partner to sign log on cancel as public user

PR #72638

Enterprise18.0

**Steps to reproduce:** 1. In the Sign app, create a sign request for a partner. 2. From the sign request email, cancel the request as the public user (partner). 3. The cancellation log is created without a partner assigned. **Issue:** When a public user (partner) cancels a sign request, the cancellation log entry does not have a partner_id. **Cause:** The partner_id was set as none when there was a public user **Solution:** Assign the partner_id to the sign log during the cre

Original PR description

**Steps to reproduce:**

1. In the Sign app, create a sign request for a partner.
2. From the sign request email, cancel the request as the public user (partner).
3. The cancellation log is created without a partner assigned.

**Issue:**
When a public user (partner) cancels a sign request, the cancellation log entry
does not have a partner_id.

**Cause:**
The partner_id was set as none when there was a public user 

**Solution:**
Assign the partner_id to the sign log during the creation.


task-4213637

Forward-Port-Of: odoo/enterprise#71335

[FW][FIX] account_{batch_payment,sepa,sepa_direct_debit}: fix sanitize_communication

PR #72961

Enterprise18.0

This commit aims to fix an issue in the sanitize_communication function and move its logic to the account_batch_payment module to improve reusability and testability. The function trims the communication text after removing the '/' characters. However, if the communication text contains '/' and is truncated, the '/' could end up at the end of the string (see tests for more examples). The solution is to remove the '/' after truncating the text. Additionally, the sanitize_communication funct

Original PR description

This commit aims to fix an issue in the sanitize_communication function and move its logic to the account_batch_payment module to improve reusability and testability.

The function trims the communication text after removing the '/' characters. However, if the communication text contains '/' and is truncated, the '/' could end up at the end of the string (see tests for more examples). The solution is to remove the '/' after truncating the text.

Additionally, the sanitize_communication function has been moved to the account_batch_payment module, since this module is a dependency for both account_sepa and account_sepa_direct_debit, these two modules can now use it as well.

The functions sanitize_communication and _sanitize_communication have been marked as deprecated and will be removed in the master branch.

opw-4220421

Forward-Port-Of: odoo/enterprise#72883
Forward-Port-Of: odoo/enterprise#71552

[FW][FIX] web_studio: add data-oe-demo support for t-out

PR #73004

Enterprise18.0

Some reports have been edited to have qweb default content that was meant to only be used from within studio. ```xml <t t-field="some_field">studio placeholder</t> ``` This content is displayed if the evaluated value is either False or None. This can also happen outside studio, if the field is not required. An attribute `data-oe-demo` was introduced for t-fields. ```xml <t t-field="some_field" data-oe-demo="studio placeholder"/> ``` This attribute was introduced for t-field no

Original PR description

Some reports have been edited to have qweb default content that was meant to only be used from within studio.

```xml
<t t-field="some_field">studio placeholder</t>
```

This content is displayed if the evaluated value is either False or None. This can also happen outside studio, if the field is not required.

An attribute `data-oe-demo` was introduced for t-fields.

```xml
<t t-field="some_field" data-oe-demo="studio placeholder"/>
```

This attribute was introduced for t-field nodes in order to only display
placeholder content inside the report editor.

We didn't introduce it for `t-out` as it was possible to change the
expression

`<t t-out="obj.prop"/>` -> `<t t-out="obj.prop or ''"/>`

While this definitely works, the attribute better signals the intent of
the change.

We thus add support for the attribute on t-out.

Forward-Port-Of: odoo/enterprise#72967

[FW][FIX] documents: inspector behavior in mobile

PR #72873

Enterprise18.0

Steps to reproduce: 1. Go to documents on mobile 2. Click on doc thumbnail 3. The inspector open where preview should open When the preview is open, click on an arrow to see the previous or the next doc 1. The inspector opens again where the previous or next should Technical Reason: In 'documents_inspector.js' file, a condition set only open the inspector if there is only one selected element, so every time it get executed and opens the inspector. After this commit: 1. Click on a

Original PR description

Steps to reproduce:
1. Go to documents on mobile
2. Click on doc thumbnail
3. The inspector open where preview should open

When the preview is open, click on an arrow to see the previous or the next doc
1. The inspector opens again where the previous or next should

Technical Reason:
In 'documents_inspector.js' file, a condition set only open the inspector if there is only one selected element, so every time it get executed and opens the inspector.

After this commit:
1. Click on a doc thumbnail, the preview will open.
2. When the preview is open, click on an arrow to see the previous or the next doc will not open the inspector.

Task-3919285

Forward-Port-Of: odoo/enterprise#72677
Forward-Port-Of: odoo/enterprise#62957

Branch: saas-17.2

Other(17)

[FW][ADD] l10n_my_edi: Malaysian E-Invoicing

[FW][FIX] l10n_in_edi_ewaybill: fix the ewaybill name log

[FW][IMP] web_editor: autoscroll latest response message in chatgpt

[FW][FIX] l10n_fr_facturx_chorus_pro: udpate PartyIdentification tag

[FW][FIX] web: remove invisible fields from default export fields

[FW][FIX] web: fix makeAsyncHandler and makeButtonHandler

[FW][FIX] payment_adyen: add idempotency key for customer-initiated payments

[FW][FIX] website: fix highlighted field update and synchronization conflict

[FW][FIX] mail: close thread action in chat window with Escape

[FW][FIX] packaging: update windows installer logo

[FW][FIX] gamification: fix traceback when user deletes a module having gamification record

[FW][FIX] stock: don't rollback scheduler if it succeeeded

[FW][FIX] base: prevent selection of invalid home actions

[FW][IMP] l10n_es: Add new tax grid for es

[FW][FIX] web: add an empty value to the minute selection in DateTimePicker

[FW][FIX] base: compare email_normalized for {email/smtp}_from

[FW][FIX] sale: allow overriding behavior after creating invoice

Branch: master

Improvements(3)

[IMP] helpdesk, planning: improve planning slot and helpdesk ticket list views

Branch: 18.0

Improvements(3)

[IMP] web: add base64 pdf o_image mimetype

Branch: 17.0

Bug Fixes(4)

[FIX] helpdesk_fsm: not create an empty partner when no info

Branch: saas-17.2

Other(17)

[FW][ADD] l10n_my_edi: Malaysian E-Invoicing

[FW][FIX] l10n_in_edi_ewaybill: fix the ewaybill name log

[FW][IMP] web_editor: autoscroll latest response message in chatgpt

[FW][FIX] l10n_fr_facturx_chorus_pro: udpate PartyIdentification tag

[FW][FIX] web: remove invisible fields from default export fields

[FW][FIX] web: fix makeAsyncHandler and makeButtonHandler

[FW][FIX] payment_adyen: add idempotency key for customer-initiated payments

[FW][FIX] website: fix highlighted field update and synchronization conflict

[FW][FIX] mail: close thread action in chat window with Escape

[FW][FIX] packaging: update windows installer logo

[FW][FIX] gamification: fix traceback when user deletes a module having gamification record

[FW][FIX] stock: don't rollback scheduler if it succeeeded

[FW][FIX] base: prevent selection of invalid home actions

[FW][IMP] l10n_es: Add new tax grid for es

[FW][FIX] web: add an empty value to the minute selection in DateTimePicker

[FW][FIX] base: compare email_normalized for {email/smtp}_from

[FW][FIX] sale: allow overriding behavior after creating invoice

Branch: master

Improvements(3)

[IMP] helpdesk, planning: improve planning slot and helpdesk ticket list views

Branch: 18.0

Improvements(3)

[IMP] web: add base64 pdf o_image mimetype

Branch: 17.0

Bug Fixes(4)

[FIX] helpdesk_fsm: not create an empty partner when no info

[IMP] l10n_in_reports_gstr: remove dead code

[IMP] sale_subscription: remove duplicated close reason

Bug Fixes(2)

[REF] industry_fsm: suppress reference to a deleted field in...

[FIX] stock_barcode: correct help text

Removals(1)

[WIP] [REM] l10n_lu_hr_payroll: remove useless tax classification warning

Other(10)

[FW][FIX] documents_spreadsheet: share public spreadsheet

[FW][FIX] website_delivery_sendcloud: fix test_sendcloud_delivery_partner

[FW][FIX] pos_restaurant_appointment: show today appointment on floor screen

[FW][IMP] documents: add list view documents type icon

[FW][IMP] l10n_ar_edi: manage 10016 afip error.

[FW][IMP] l10n_ar_reports: VAT Book: use load_more_limit

[FW][FIX] delivery_ups_rest: correct shipper on return label

[FW][FIX] l10n_fr_hr_payroll: revert translation of salay rule codes

[FW][FIX] l10n_*_reports*: remove 'countries' info from manifest

[FW][FIX] web_studio: add data-oe-demo support for t-out

[IMP] l10n_in_gstin_status: add the missing pot

[IMP] documents: replace pin icon by tick icon

Bug Fixes(6)

[FIX] base: clean removed module data

[FIX] account: prevent an error when open a preview of invoice

[FIX] base: prevent traceback when editing the view

[FW][FIX] l10n__reports: remove 'countries' info from manifest