Based on RFC3462, a Content-Type text/rfc822-headers
exists and provide a mechanism to label and return
only the RFC 822 headers of a failed message (bounce)
These are only the headers and not the full message.
The Content-Type-Encoding should be either 7-bit(US-ASCII)
or Quoted-Printable (QP) as in the section 2 of the RFC.
Spawn the error:
After getting reported by a customer, I had to reproduce
by spamming wrong outlook addresses and add logging
in a sh database on the message_process of mail_thread.py
and logged the `message` variable.
After few retry, I got one of the part that was defined
as followed:
Content-Description: Undelivered Message Headers
Content-Type: text/rfc822-headers
Content-Transfer-Encoding: quoted-printable
The `get_payload()`function used was only assuming
that there is a full email on that part and that
it could only be encoded as an email, which was not
the case in this situation (quoted-printable:
76 characters per line, character `=` used
as the end of line character).
opw-3064589
task-3131561
closesodoo/odoo#110901
X-original-commit: f86f4b671696178f8fa42b81d8753d2591578431
Signed-off-by: Julien Castiaux <juc@odoo.com>
Co-authored-by: Baptiste Vergote <bve@odoo.com>
The "All Websites" list of views is confusing for users with its
combination of default and specific views.
This commit makes the "All Websites" filter only available in debug
mode, and defaults the selected website on either the current website
(if one is selected) or the first website of the list.
The test is adapted because only the current website's pages are
displayed now.
task-3092786
closesodoo/odoo#110898
X-original-commit: 01cb743f1c0c22621bcfa92005a7d10dfa92e746
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Unfortunately, when I wrote the loc, I forgot to include
`account.group.template.csv` in `__manifest__.py`.
As such, the account groups were not loaded, and I didn't notice an
error in the chart template name.
Thanks to WAN for finding this.
closesodoo/odoo#110890
X-original-commit: 7610f1ef5f329a52ee16fe88909be30ddf395b8d
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Antoine Dupuis (andu) <andu@odoo.com>
In [1], conditions have been made in order to allow/forbid each snippet
to toggle the grid mode. However, a case has been forgotten: when a
snippet that cannot toggle the grid mode is dropped inside a snippet
that can toggle it (so it is an inner snippet). Indeed, if we drag one
of the inner snippet columns, we can see that the grid mode is toggled,
where it should not be the case.
This issue comes from the check looking if the grid layout option is
in the right panel. Indeed, even though such a snippet does not have
it, if it is dropped inside a snippet that can toggle the grid mode,
then the option is well present in the right panel (= the outer snippet
one).
This commit fixes this issue by improving the check: now, dragging a
column can toggle the grid mode only if the container having the option
is the same as the one of the column. This commit also improves the
siblings/children filtering (to only have the relevant dropzones) in
order to take this case into account and to be more robust to
customizations.
Steps to reproduce:
- drop a Text-Image snippet
- drop a Form snippet inside one of the columns
- drag a form field
=> the grid mode is toggled.
[1]: https://github.com/odoo/odoo/commit/84d684d8bdf43d3db11defd8174dee44775085c2
opw-3100399
opw-3139938
closesodoo/odoo#110888
X-original-commit: 34b534f75dbf3e4c475ca8cc40c8fafde5dbea5d
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: qsm-odoo <qsm@odoo.com>
https://github.com/odoo/odoo/pull/102662 Highlighted the fact that in some
cases, an rpc call can be done on a destroyed component.
There is such a case in Knowledge, which now causes a warning in some cases.
Impacted Versions
- 16.0 and higher
Steps to reproduce:
- create a new article in Knowledge
- type the space character: [ ] in the article body
- switch to another article
Current Behavior:
- warning
Expected Behavior:
- no warning
Contents of the fix:
Do not try to update the value of the html_field if the component is already
destroyed. This could happen when an urgent commitChanges was requested (i.e.
when leaving an article to open another).
Task-3101553
closesodoo/odoo#110862
X-original-commit: 1b683bd600bbf5c39c520afa041c4f6124c9dea8
Related: odoo/enterprise#36232
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
The JSON object can contain characters such as `<` (i.e. in domain expressions
for the act_window object of an embedded view). This means that the JS sanitizer
DOMPurify will remove the attribute when parsing a node that contains it.
Instead of encoding/decoding that attribute each time the DOMPurify sanitizer is
called, we could encode at all time, and decode it only when we use the value it
contains, since JSON.parse has to be used at those times anyway.
This way, we don't pollute OdooEditor.js code, which is already quite complex.
Task-3101553
X-original-commit: 7686ae282c97bc255ebb66367b39447b7bc1749b
Part-of: odoo/odoo#110862
before this commit, the action name was not getting translated to user language.
after this commit, the action name will get translated to user language.
closesodoo/odoo#110856
X-original-commit: 6758cde0358359d76642b0cbea4c208eac57dd92
Signed-off-by: Tiffany Chang <tic@odoo.com>
The payment account should either be of type `asset_current` or `liability_current`, but now only `asset_current` type is allowed.
`liability_current` should also be in the payment account domain.
task-3145725
closesodoo/odoo#110846
X-original-commit: d29268c397c900774313d6069790073551458546
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Aliya Tastemirova (alta) <alta@odoo.com>
Steps to reproduce the bug:
- Create a storable product “P1”:
- Variant: Color: Black and white
- BOM 1:
- product variant: P1 - White
- Type: Kit
- Consumable: C1
- BOM 2:
- product variant: P1 - Black
- Type: Kit
- Consumable: C1
- Create another kit product “P2” without variants
- Create an SO:
- Add “P1 - white”, “P1 - black”, “P2”
- Confirm the SO
- Go to the delivery → validate it Print the delivery slip
Problem:
only product "P2" is displayed in the report.
The `product_id.name` is used as `move.name`:
https://github.com/odoo/odoo/blob/16.0/addons/sale_stock/models/sale_order_line.py#L333
but then only compare it with the name of the `product_template` set in
the bill of material to filter the moves.
Solution:
Check if the `move.name` is equal to the `product_id.display_name`
set in the bill of materialale au product_id set dans la bill of
material.
opw-3051639
opw-3047822
closesodoo/odoo#110837
X-original-commit: eae5cf84625f8155bc72b63eaed28819698810cf
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Well it is not a typo but a mini code improvement. The suggested diff
clarifies the intent of `_handle_control_frame` with regards to
`_get_messages`. Because it was `return self._handle...` we had to read
the method to determine if it was returning something in order to know
whether the message would be propagated to the rest of the websocket
routing by `_get_message`. Now it is clear that the control frames are
handled right away and that they are not propagated to the business.
closesodoo/odoo#110834
Signed-off-by: Julien Castiaux <juc@odoo.com>
*: website_crm, website_form_project, website_hr_recruitment,
website_mass_mailing, website_sale
Prior to this commit, modules that add elements (fields, references,
etc.) to the website_form registry, would do so inside the
`website.assets_editor` bundle.
It creates a module dependency error since [1] + [2]:
The form options (`s_website_form/options.js`) defined in
`website.assets_wysiwyg` requires the registry defined in
`website.assets_editor`. But since [1] and [2], the
`website.assets_wysiwyg` bundle is loaded inside the iframe without
`website.assets_editor`, as only `website.assets_wysiwyg` is needed to
properly display and interact with the editor. (Although, most of the
bundle is not necessary and a later IMP will either only load the CSS
needed or split the bundle).
This commit moves the modules that creates the registry as well as
modules that extend it to the `website.assets_wysiwyg` bundle, fixing
the dependency error. Though they are not required inside the iframe,
the bundle can now be loaded without the need of assets_editor,
removing the missing dependencies. But mainly, this should have been the
case since the introduction of website.assets_wysiwyg at [3] anyway: we
want to lazy load everything that is editor related. Although it was [4]
which mixed the form editor files between the `website.assets_editor`
and `website.assets_wysiwyg` bundles.
[1]: https://github.com/odoo/odoo/commit/03c552690b15cbf2e7d6b7812386ac64042219af
[2]: https://github.com/odoo/odoo/commit/a154ee7ad6fd3ebdd38943e1439badae11c3151d
[3]: https://github.com/odoo/enterprise/commit/19a144d6af2974e964c6487170e6bca1b14d3898
[4]: https://github.com/odoo/odoo/commit/f8882698e8f4d1a3ad081522778344e2bd7aa0declosesodoo/odoo#110811
Related: odoo/enterprise#36195
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: qsm-odoo <qsm@odoo.com>
Before this commit, there is no verification while changing a product's
company. That can lead to issue where some operations cannot be done
because of access errors.
To avoid that, this commit prevents to change the product's company if
some quants for this product exist in another company's location.
How to reproduce:
- Have at least two different companies (let say CompA and CompB);
- Create a new product who belong to no company;
- For this product, add quantity on hand in a CompA location;
- Now, change the product's company for the CompB;
- While selected only the CompA, go into the Inventory Adjustments and
try to create a new inventory adjustment for the CompA location with
this product's quant -> Access Error.
opw-3095984
closesodoo/odoo#110810
X-original-commit: 46987e13f35dc140869c58f6c5a09d9c542c3ae5
Signed-off-by: Tiffany Chang <tic@odoo.com>
Signed-off-by: Steve Van Essche <svs@odoo.com>
Add a constraint preventing the user from switching the project from company
if the partner doesn't belong to that company, and vice versa.
task-3126301
closesodoo/odoo#109464
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Currently, the character `/` appears at the end of the url of the
language dropdown on the home page e.g. /en/, /fr/. This will cause one
more redirect when performing the language change.
Indeed, this error is only encountered with path = /
Please try the following `url_lang('/', 'en_US')` => /en/
After this fix, the trailing `/` will be removed when using the func
`url_lang` e.g. `url_lang('', 'en_US')` => /en, this means that the
language switching links on the homepage no longer redirect redundantly
again.
closesodoo/odoo#106109
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Before this commit project simplified view was not pretty because
of some alignment between different section/fields and width of
name field is not as expected.
This commit fix layout of project simplified view to make UX
better.
task-3102445
closesodoo/odoo#108151
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
This commit aims to notify the user (currently through an email) that some
important security parameter of his account has changed.
Here is a list of what is currently notified:
- password change
- login change
- email change
- 2FA enabled/disabled
- trusted device (for 2FA) added/removed
This email is rather simple and only invites the end-user to take actions if
that change was not done by him (reset password, contact administrator, ...).
Task-2639168
closesodoo/odoo#94922
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Since e3eb7d9bef, the accounting logic
has been moved out of the payment module, to be only in the
account_payment bridge module.
This bridge module has been set as strict dependency of
module providing payment & invoicing abilities, e.g. sale .
Nevertheless, the account_payment module also held the logic to
allow users to pay for their invoices on the portal and there
was no dedicated setting to enable/disable this feature.
This means that in 16.0+, you cannot disable online invoices
payment without removing sale and subsequent modules.
This commit introduces a temporary bugfix module to allow
disabling invoices payment without uninstalling the
account_payment module. It will be merged in the core
account_payment afterwards.
opw-3114860
closesodoo/odoo#110843
X-original-commit: be242cf658e7742600dec4824ba96a89f4d6142a
Related: odoo/documentation#3396
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
For companies having a Chart of Accounts that inherits from an ancestor CoA linked to the taxes, the current tax update script did not work.
This change also supports this case.
X-original-commit: 45aae69c20d40467d64af4c7e4f0b45b7832b89c
Part-of: odoo/odoo#110841
before this commit, in the draft state the l10n_de_document_title field value is computed as Repair Order and in other state it is computed as Repair Quotation.
after this commit, in draft state Repair Quotation and in other state Repair Order will be computed in field l10n_de_document_title
closesodoo/odoo#110839
X-original-commit: 522745b8cefd771c9bea8571f8f35725e817c285
Signed-off-by: John Laterre (jol) <jol@odoo.com>
Prior to this commit the limit set on accrual plans was in hours but
effectively used as a limit in days in the code.
Meaning that a level with a limit of 240 hours effectively applied a
limit of 240 days (or 1920 hours with 8 hour days).
TaskId-3145560
closesodoo/odoo#110835
X-original-commit: c9df4a33fcfe2dbcbac35923d0bceb3757516fb1
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>
before this commit, the lots info shown in the products were always computed, no matter if they were printed or
not.
after this commit, the lot info only is computed when is actually used and will be printed: that is when the user has the
stock_account.group_lot_on_invoice group.
closesodoo/odoo#110808
X-original-commit: 9e95dd198790d26addfb0d30dd83d66fc1055c53
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
To reproduce the issue:
1. Install Inventory & Purchase apps
2. Toggle on Settings > Inventory > Purchase Agreements and save
3. Go to Purchase
- [Products] > [Products]: add a product w/ internal reference and w/o
- [Orders] > [Blanket Orders]: create a blanket order with the products
- Save, Confirm and click Print icon to generate the said report in pdf
Desired behavior: Do not show brackets for null internal reference
opw-3138636
closesodoo/odoo#110812
X-original-commit: fb0567ee4fe75d3d0ab2475eaf1c7277ee24636a
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Lee, Hansun (hale) <hale@odoo.com>
Prior to this commit, the recipient in the SMS wizard
shows The name of the record.
In this commit, we make the partner the recipient instead
showing The name of the record itself.
task-3000243
closesodoo/odoo#110801
X-original-commit: 16e25edaf5c589046d42c62a2c32d337504d9e37
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Before this commit: if cashier A starts an order, and cashier B completes
the order and validates it, the order would be saved to the database as
belonging to cashier A, but cashier B will be printed on the receipt.
The problem is that `employee` has been refactored to `cashier` in this
commit:
https://github.com/odoo/odoo/commit/0e7fdbe06cce41bdea1af9a96205a2ea0cf041a6
But `employee` hadn't been changed.
The solution is to keep the cashier who validated the order as the final
cashier.
opw-3114318
closesodoo/odoo#110695
X-original-commit: a3baacb0c3a631f52ce97c0179b4c7c7888471dc
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
Steps to reproduce:
- Add Switzerland Accounting, go to the CH Company and create a PoS.
- Go to the PoS and go to the Cash In/Out in the top bar.
- Start introducing a value in the input field.
Issue:
The field is only made to 1 character as a currency symbol, so when the
currency has more than 1 it will overlap with the values in the input.
Solution:
Added a new class to put currencies above one symbol to the left,
and we keep the rest as it was.
opw-3121266
closesodoo/odoo#110694
X-original-commit: e8a29a53f7db681d9cb94dc88ab7887a0d4d2f61
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
before this commit, the sale_amazon module is not listed in community instance with upgrade button.
after this commit, the sale_amazon module will be listed in community apps list with upgrade button similar to sale_ebay module.
closesodoo/odoo#110447
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Steps to reproduce the bug :
- In Website (edit mode), drag & drop a "text-image" snippet.
- Click on the button.
- Change the size of the button to "small".
- Click outside the button.
- Re-click on the button.
- The size selected in the options is "medium" and not "small".
Note that the same bug exist in backend with the link dialog.
This bug was introduced in ([1]), the code of the "else" (which was
removed by it) made it possible to take into account the cases where the
option had no "value" (e.g. "medium" size button). And so, without this
"else", the options without "value" were activated in any case.
This previous commit, which fixed an issue with the presence of the
"btn-success" class on a link, could in fact be based on what had
already been done for the links with the "btn-link" class (in [2]).
In this commit, this issue with the "btn-success" class is handled the
same way as for "btn-link".
[1]: https://github.com/odoo/odoo/commit/4c68b3e923610e1d573b4bd2b241b2fc5923c412
[2]: https://github.com/odoo/odoo/commit/c3e08e7a7baab1035c3d5c48d668cc02a232e1ac
task-3002177
closesodoo/odoo#110809
X-original-commit: 5e98953d67042dcffa978ab7d240d8677e847456
Signed-off-by: Outagant Mehdi (mou) <mou@odoo.com>
- Create un SO in EUR with a product with service_to_purchase, with supplier A
- Supplier A work in USD
--> Confirm order
Issue fields.datetime.now() doesn't exist.
closesodoo/odoo#110795
X-original-commit: 02813802a429570a05cf5ad1402408b2e3d01e99
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Release notes: https://github.com/odoo/owl/releases/tag/v2.0.4
- [IMP] app: expose live apps for the devtools
- [FIX] compiler: support t-model radio group in t-foreach
- [IMP] runtime: improve useExternalListener typing
closesodoo/odoo#110790
X-original-commit: f7192699aea443bea278a55e0e383e59d98394c5
Signed-off-by: Géry Debongnie <ged@odoo.com>
Sale module has setting `Lock Confirmed Sales`, which particularly doesn't allow
order line modification. However, the application does modify special lines for
Down payment: it changes name from `Down Payment: 09 2001 (Draft)` to `Down
Payment`.
Fix it by excluding down payment lines from the constrain.
Also, this commit fixes access error when user doesn't have read access to
`ir.model.fields` model.
STEPS:
* Create user with only BILLING (group) access in accounting App.
* Now Logged in with Admin user
* Create any SO, Confirm, Validate the delivery order.
* Create an invoice with Down payment (%) as 10.
* Now do Logged in with BILLING user
* Open the draft invoice which gets created by SO.
* Confirm the invoice.
opw-3134083
closesodoo/odoo#110788
X-original-commit: b9cd677b7e20579b9fb0d59a2d24ae5d2e11fb72
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Signed-off-by: Ivan Elizaryev (iel) <iel@odoo.com>
This commit aims to make easier the overriding of _action_assign by extracting the inner function that retrieves available moves out of it and splitting it in two parts to be able to have a better control on the available moves in and the available moves out.
It is currently not possible to modify the way _action_assign get available moves to create new stock move lines due to the fact that the algorithm is an inner function.
We are currently making a custo that uses consumables and need to change the reserved quantity based on some conditions therefore, the function returns every done stock move line in previous picking and get the wrong result in the end.
For example, let's say we have 3 PACK pickings containing 2, 1 and 3 units of a consumable product respectively. Let the two first PACKS be done, so the OUT picking contains two stock move line, one with 2 units, one with 1 unit. When confirming the last PACK, instead of getting a new stock move line with 3 units, we get two lines, one with 2 units and one with 1 unit because the function looped over all the done stock moves without taking quants into account.
This behaviour is correct but cannot be overriden properly as of now apart from copying the whole function and change what we need.
closesodoo/odoo#110787
X-original-commit: b3d869a3a1ef7591ab846e347f261518fc09f12d
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
before this commit, when try to create a purchase order without inputting currency field it was showing exception like "The operation cannot be completed:
- Create/update: a mandatory field is not set."
after this commit, user cannot save the record without filling currency field
closesodoo/odoo#110786
X-original-commit: 34b24e4e3d34470bcbeb28f0b89b59cea84b7c7d
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
When inserting a backtick in text that has another backtick before
(case 1) or after (case 2) it, we convert the text contained between
said backticks into inline code. Case 2 was not tested, and didn't work
properly.
closesodoo/odoo#110784
X-original-commit: cc2a4a960d6d83362e35abc8a253e95105fd07f9
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Signed-off-by: Antoine Guenet (age) <age@odoo.com>
Wrong syntax made it so that having a text node after the text node in
which we're inserting a closing backtick character, converted all the
text after the backtick to the word "NaN". This fixes that syntax error
and ensures such cases are properly handled.
X-original-commit: 2833b42c09582dbcfed334d9fe6628a8eaf476b8
Part-of: odoo/odoo#110784
To reproduce the issue:
(Need account_accountant,purchase)
1. Setup a product P
- Storable
- Invoicing Policy: Delivered
- Category:
- FIFO + Auto
2. Process a PO with 1 x P at $10
3. Process a PO with 1 x P at $15
4. Create and confirm a SO with 2 x P
5. Process the delivery one by one (backorder)
6. Create one invoice for each delivery
- The COGS of the first one are equal to $10
- The COGS of the first one are equal to $15
7. Reset and repost the first invoice
Error: The COGS are equal to $15 instead of $10
Steps 5: it creates 2 out-SVL (1x$10 and 1x$15). Step 7, we try to get
the anglo saxo price unit. It leads to `_compute_average_price` with
the invoiced qty (1) and the qty to invoice (also 1). In this method,
we iterate on each out-SVL, we first skip the invoiced quantity and
then consume the quantity to invoice. Here is the issue: we will
skip the SVL we should use and keep the one already used. As there
isn't any link between an AML and the SVL it used, we need a new
approach.
OPW-3062069
closesodoo/odoo#110783
X-original-commit: 17438d5befcd6e9f1fc2ec2a54dfcebbc846d251
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
As sale does not know about special lines it will always update
the price based on product and price list instead of applying the correct
shipping rate, so we do skip those lines by using a newly introduced hook method
closesodoo/odoo#110782
X-original-commit: f1265b7fdce6bbe3fea97fc4b275dc2dca18103d
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Usecase to reproduce:
- Product A with Vendor supplier lead time=1day
- Product B with same Vendor supplier lead time=4days
- Launch the replenishment report for both products at the same time
Current Behavior:
The expected arrival is correct but the order date deadline is today - 3
days
Wanted Behavior:
Same but the order date dead line is today
It happens because it does the minimum of expected arrivals - max of
supplier delays. However the supplier delays are already correctly
apply on each procurement (correct expected arrival). To know the
correct order deadline we should instead take the minimum date planned
with the related supplier delay.
opw-2822588
closesodoo/odoo#110779
X-original-commit: 9364f4fbc3966373a33c32b1325b3b22cc6c5f2e
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
The mnmliconsv21 is not used anymore for 7 years (see 660b13b)
Closes#6382
X-original-commit: 0f59b958fb9013bfd47ba16b36204bcbee731b72
Part-of: odoo/odoo#110616
Before this commit the dynamic event snippet sorts the events from further
in the future to current, making it so that events in the near future are
not in the spotlight.
After this commit the events are sorted as expected, with the earliest events
first.
Task-3105126
closesodoo/odoo#110791
X-original-commit: de1dc9e888f3ffc59589f1fdd4e518638c35bca6
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Since we reuse sale order lines as much as possible, having reward lines
with no tax means that we need to explicitely reset the taxes on those
lines. However this was not done before.
TaskId-3138483
closesodoo/odoo#110785
X-original-commit: e945526f3a69d0adaa283c9a5aa4f5dde6027e4e
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>
Fix two issues:
- Payment rewards have to be applied after any other reward, the logic
to do so was already implemented but the condition got inverted
somehow.
- Allow discounts to be applied on orders if the total is zero in case
a payment reward is being used.
TaskId-3138483
X-original-commit: 7104527ffc5606c054e2b8d596b869cd4ccfce64
Part-of: odoo/odoo#110785
**Steps to reproduce:**
- helpdesk.ticket form view
- set a user on the ticket
- create & edit a new user on the fly
- discard the user creation modal
- [BUG] the avatar of the user that was initially assigned to the ticket is still displayed
**Solution:**
This is because when closing the dialog, we only clear the input. This fix
proposes to also clear the value of the field -- which unlinks the previously
selected record for the field. Note that it only makes sense to do it in m2o
fields so another test is added for extra assertion.
closesodoo/odoo#110781
X-original-commit: df783ada3281e33038253deffd75d35f44b9d579
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
