Steps to reproduce
==================
- Open studio
- Go to reports
- Click on invoices
- Try do drag a text block at the end of the page after the table with
the total
Studio doesn't place a drop hook after the table.
Cause of the issue
==================
Studio only adds hooks before and after each direct child of the element
with a 'page' class.
Since [commit], the `#right-elements` and `#payment_term` elements are
outside the page and thus we can't place an element after.
Solution
========
- Move the `#right-elements` and `#payment_term` inside a new div since
they are part of the same line and we don't want to put an element
between them.
- Move that div inside the page.
- Add a clearfix class in order to have it's height correctly computed.
[commit]: https://github.com/odoo/odoo/pull/107714/commits/66373a538e123b29b983a8e02f302e7e258e084d
opw-3345430
closesodoo/odoo#127771
Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>
From 16.0 any user can delete a customer invoice/vendor bill even if it creates a sequence gap.
This commit updates the rights and the warning message:
- The deletion confirmation message contains a warning about the sequence gap
- Only a Billing Administrator/Accountant can delete customer invoices/vendor bills creating the gap
- Also, if the fiduciary mode is on (`quick_edit_mode`) it should be possible to delete
invoices/bills regardless of the user group
task-3284218
closesodoo/odoo#128556
X-original-commit: 2249f899049ef94b14b083c8db976662b868b026
Related: odoo/enterprise#44128
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Aliya Tastemirova (alta) <alta@odoo.com>
Before this commit, when an invoice is reversed we used to put the message
"this entry has been duplicated from XXXX" but the message that we log in the
chatter was not very clear and also to have the info on the invoice that it has
been reversed you add to go on the credit note itself.
Now when an entry is reversed, the link to the credit note is put in the chatter
of the invoice and the message on the credit note has been changed.
closesodoo/odoo#124060
Task-id: 3326780
Signed-off-by: William André (wan) <wan@odoo.com>
Trying to access quotations using an older version of a browser, that
doesn't support `structuredClone` like i.e Safari <15.3 will throw a
traceback that will block the regular usage of the app.
We can use an older alternative to handle the deep cloning, with this
approach tho, we will lose the support of Dates, RegExps, Maps, Sets,
Blobs, FileLists, ImageDatas, sparse Arrays, Typed Arrays.
opw-3386434
closesodoo/odoo#128472
X-original-commit: 5b4526b5dab519178a7c694de0625629e8686396
Signed-off-by: Samuel Degueldre (sad) <sad@odoo.com>
This branch adds the fields and constraints required by its enterprise counterpart.
Task 3098971
closesodoo/odoo#127236
Related: odoo/enterprise#43601
Signed-off-by: John Laterre (jol) <jol@odoo.com>
When creating a Vendor Bill, the default Sales Team & Person of the company is
assigned to the Vendor Bill. The field isn't even displayed, it's hidden, you
can only display it with Studio and can't even change it.
The fact is : purchases and sales are two completely different roles and
business in companies. This has the indirect consequence that any user that
follows the default Sales Team will get notified of any new Vendor Bill created
in Accounting, which he very likely does not need/want to see.
This PR correct that by adding a condition on the filling of these fields. These
fields will be filled when the move is a sale document.
closesodoo/odoo#120628
Task-id: 3279233
Related: odoo/enterprise#44034
Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>
This commit aims to improve the order of draft bills / invoices. Currently when importing multiple vendor bills they aren't ordered logically since they're still draft bills. Adding a fallback order by invoice_date until they're posted will help the user find the bill he's looking for more easily. It also allows to preserve the order of the imported bills in case of validation in batches.
Task ID: 3383575
closesodoo/odoo#126691
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
The aim of this commit is to add a warning when an invoice is uploaded and a duplicate of this invoice already exists in db.
It is the same behaviour that we already have for vendor bills
Previous to this commit:
When uploading duplicate vendor bill -> Warning
When uploading duplicate invoice -> NO Warning
After this commit:
Warning in both cases
closesodoo/odoo#126096
Task: 3378169
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
Since 7bd93cc64b, we add the amounts to
invoice from sales order to the credit limit warning. When looking at
the credit amount on a partner from an accounting perspective, it is
not correct though that sales orders to invoice are considered as well.
In this change we split the credit amount from invoices and from sales
orders to invoice. On the partner we only show the credit amount from
invoices. In other places we add both.
task-3375260
closesodoo/odoo#128158
X-original-commit: 94eae9b73995dbf2175ecee65548ace5a382f5f8
Signed-off-by: John Laterre (jol) <jol@odoo.com>
Signed-off-by: Dylan Kiss (dyki) <dyki@odoo.com>
When upgrading and loading data from templates, there could
be journals that match our target but the code is modified by
the users. The code may be different due to translations or simply
a user choice, but the journal can be the standard one. And the
noupdate=True that is on the xmlids of the created journals
confirm that it is possible for the users to keep their
customizations on the journals.
Matching the journals by type and name can be an alternative
to creating a duplicate journal, which will cause more conflict
down the line (for ex. the unique constraint on mail aliases)
closesodoo/odoo#128139
X-original-commit: 069714ee8e7175ab92a4d28b75e3725ea0be1b0f
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Jinane Maksoud (maji) <maji@odoo.com>
Issue Description
When a user changes the sequence of the lines which have a parent_id field,
particularly when it changes the sequence and the parent field of the line is
after the line, then it will give an error in the opening of the reports.
Steps to Reproduce:
[This step is only used for this traceback. But the issue occurs in all the
account reports.]
1. Install the account_reports module.
2. Open accounting and go to configuration.
3. Then, click on accounting reports and select the profit and loss report.
4. Change the sequence of the lines.
5. Save the changes.
6. Click on the reporting menu and select the profit and loss report.
7. The traceback will generate.
Fix:
This commit resolves the above issue by throwing a validation exception
when the parent line is set after the line. And also throws a validation
exception when the user sets the parent line as itself.
Sentry ID: 3944989529
closesodoo/odoo#128209
X-original-commit: a8a147dab40af4732bbe072cfd9cff1d1ba80e36
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
Create a Bill
Register payment
Create the bank statement
Match with the payment
Go to accounting dashboard, hit "Vendor Bill" (open bill list view)
Clear filters
Add filter: Unpaid
Issue: Users should not be able to clear the journal filter when opening
the bill view
This commit align the behavior of the dashboard to the menu entries
by adding a default search domain to the actions instead of the default
search filter
opw-3228450
closesodoo/odoo#128203
X-original-commit: 4e612d5434d8254c3ba44b8a00d7d71bc0ab4084
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
Signed-off-by: Andrea Grazioso (agr) <agr@odoo.com>
Before this PR, the incoterm location was not present in the account module.
This pr does multiple things:
- Add the Incoterm Location field in Accounting on Customer Invoices and Vendor
Bills. The field already exists on Sale Orders and Purchase Orders. When you
create an Invoice from a Sales Order, or a Vendor Bill from a PO, copy the value
of the field on the invoices.
- Update the PDF to display the field value if present, and remove the useless
duplication
- Remove incoterm setting on sale
- Remove useless xpath since now it is displayed directly on invoice when
incoterm field is fill.
Task-id: 3273460
Part-of: odoo/odoo#118954
In the process of making bank statements optional, the usability of bank statement was reduced.
This PR aims improve that, by providing the ability to view and manage bank statements on the bank reconciliation widget.
See the Enterprise PR.
Task-3270046
Part-of: odoo/odoo#127630
Otherwise, when displaying the field in the view, the field might remain set, causing confusion.
closesodoo/odoo#128143
X-original-commit: 003edebd7e90d3e24a2f932c5ff90b1b13758b35
Signed-off-by: John Laterre (jol) <jol@odoo.com>
Improves the update of accounting report expression when switching the engine to 'tax_tags'.
To reproduce:
1) Create a new report line in a report with an expression using the 'external' engine, giving it "dudu" as formula.
2) Save your changes.
3) Modify your expression to use 'tax_tags' instead of 'external'. Save your changes.
=> +dudu and -dudu tax tags are now created (with this commit), as expected
task : 3270506
closesodoo/odoo#128053
X-original-commit: a7dfd79ec13bae3d43cda7be06ebd07ba3ce135c
Related: odoo/enterprise#43918
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
Signed-off-by: Hugo Poncelet (hupo) <hupo@odoo.com>
Commit ee6e560415 probably forgot to wrap the
rounding data of the document_tax_totals_template in a table row `<tr />`
This commit corrects it
Part-of: odoo/odoo#126963
They have been removed in 3fea5b213, these must be left overs.
They don't really do any harm besides providing a bad example for devs.
closesodoo/odoo#127767
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Currently, when reversing a customer invoice with a credit note
that included an exchange difference, the payment state would
switch to 'Paid' instead of 'Reversed'.
This was due to the fact that the exchange difference entry
changed the way the payment state was evaluated. This
is being fixed here.
task-3418480
closesodoo/odoo#128000
X-original-commit: 01cb9804d46d75d820e7e16ce065e1034d7a8c20
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Signed-off-by: John Laterre (jol) <jol@odoo.com>
Create an invoice and without saving it:
- Add a line
- Switch currency
Issue: currency change of the move is not propagated to the move line.
Not even after saving and confirming the invoice
opw-3267497
closesodoo/odoo#127878
X-original-commit: 4774a66771d66c20011ed4d8b543b007ec21e059
Signed-off-by: Andrea Grazioso (agr) <agr@odoo.com>
Signed-off-by: William André (wan) <wan@odoo.com>
Before this commit, when trying to install the l10n_sa or l10n_ae localization,
we get an error in the chart template resulting in no demo data installed. In
fact, when doing a Command.update to link the account to the journal in the
files template_sa and template_ae. The "values" dict was always filled no matter
the Command, this mistake had repercussion on the "deref" method.
In the deref method we do a loop on values items, but in the case we are facing
the last_part variable was filled with an integer.
When doing the recursion in case command is a "create" or an "update", the new
values is the last_part, so the loop on values items raised an error since we
cannot do a .items() on an integer.
closesodoo/odoo#116643
Related: odoo/upgrade#4687
Signed-off-by: John Laterre (jol) <jol@odoo.com>
In this pr, we have improved the l10n_hu localization by adding a Tax rounding
(global) by default.
Also, a lot of localization will need a delivery date on invoices. We added a
field in account that can be overridden if needed. In this pr, we did an
override on l10n_sa and l10n_hu.
When creating a sale order and that the effective date is fill, we take this
value for the delivery date.
The delivery date field will always be displayed in the other info tab, and if
there is a delivery data, the field is also display in the header of the form
view. Exception for l10n_sa and l10n_hu where the delivery date is always
present.
Also for l10n_sa company there was a problem with the vat number, it was not in
the right format.
Task-id: 3191530
Part-of: odoo/odoo#116643
While creating an invoice if the user chooses a payment term with an early
discount, saves the invoice without adding invoice date and tries to
preview it or prints it, then the user will face the error.
steps to produce:
- Create an invoice without entering invoice date, with a payment term having
early discount through 'Invoicing > Customers > Invoices'.
eg: (Payment Term with early discount: 2/7 Net 30 )
- Now click on 'Preview' to preview the invoice or print the invoice report.
By following above steps you will be able to produce the error.
Error: A Traceback appears "TypeError: unsupported operand type(s) for +:
'bool' and 'relativedelta'"
sentry-4250888430
closesodoo/odoo#127791
X-original-commit: 9b20af823d3d2d8c3c70fd016d71448caa039958
Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>
Signed-off-by: Saurabh Mishra (sami) <sami@odoo.com>
This commit fixes a bug (corner case) concerning payments
to yourself where an early payment discount is applied.
Details / steps to reproduce the bug:
1. Create an invoice
2. Select your own (currently selected) company as customer
3. Select some payment term with early payment discount (e.g. '2/7 Net 30')
4. Confirm the invoice.
5. Click "Register Payment" and keep the default values (i.e. "Mark as fully paid" should be selected)
6. Click "Create Payment"
7. A User Error like the following should appear (with different journal entry names):
"Journal Entry Draft Entry PBNK1/2023/00001 (INV/2023/00005) is not valid. In order to proceed, the journal items must include one and only one receivable/payable account (with an exception of internal transfers)."
Why the bug happens:
The early payment discount adds some extra lines to the journal entry associated with the payment.
Currently those extra lines are classified as "counterpart lines" since the customer is our own company.
But there must be exactly 1 "counterpart line".
How the bug is fixed:
The condition that classifies the extra lines as "counterpart lines" was only intended for internal transfers.
Each company has a related "transfer account" that is used as an intermediary account for internal transfers.
Thus the old condition (c.f. commit diff) when checking whether a line is a "counterpart line"
can be replaced by checking whether the account associated with the line is the "transfer account" of our company.
task-3388294
closesodoo/odoo#127844
X-original-commit: b1536ecb6bc94a2bd5ff3bdf1b73289ca87a744d
Signed-off-by: Laurent Smet (las) <las@odoo.com>
In this pr https://github.com/odoo/odoo/pull/121601, we did some modification on
the payment form but by doing that we change the label of the menu item.
So this PR will change the menu item back to what is used to be but keeping the
change on the action.
closesodoo/odoo#127626
Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>
Fixup of 5cb044dd8a2385c9a3c09520ed97eb4faa39216d
We should use float_compare when working with float amounts as the
standard == may give wrong results
opw-3389449
closesodoo/odoo#127684
X-original-commit: 91f970fdfd8136e303b7052d690d8997f0278f24
Signed-off-by: John Laterre (jol) <jol@odoo.com>
Add a test that checks that a chart_template reload
when data didn't changed won't delete or create any
records.
Test added retroactively for this fix: https://github.com/odoo/odoo/pull/126830closesodoo/odoo#127685
X-original-commit: 7d78bd2733e9b1aaada0551333bfdf8e7d470c8b
Signed-off-by: William André (wan) <wan@odoo.com>
This constraint did not exist prior to version 16.0 and was
added here : https://github.com/odoo/odoo/commit/7c4e591d58dd2b882f0c237d52490b2756c94203
But this feature is used by fiduciaries for printing customer
invoices, which is why we are removing it here.
No task, internal feedback.
closesodoo/odoo#127490
X-original-commit: d54bae78db25dc62687e3afc64f8699dfbfd5cf8
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Signed-off-by: John Laterre (jol) <jol@odoo.com>
- The private addresses have been removed from the "res.partner" model.
- The employees' private address information has been moved to the "hr.employee" model, preserving the old records but emptying the private information fields.
- The applicant's private address information has been moved to the "hr.applicant" model, following the same approach.
- More generally, some efforts have been done to ensure we only create and use the same partner from the application form, to the employee creation and also the user creation.
- The salary configurator offer mechanism has been improved to provide stability (no more arguments in URL), traceability (track changes and responsibles) and reporting.
closesodoo/odoo#120586
Taskid: 3101400
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Prior to this commit, the patches done by `account_portal.js` and
`sale_portal.js` were done without any import.
This means that the widget it modifies (PortalHomeCounters) might not
already be loaded in the registry. This could lead to some issue later.
This commit uses an "import" statement on the module that defines
PortalHomeCounters to ensure that it is present in the registry.
task-3249625
closesodoo/odoo#127371
X-original-commit: 7937dbec9699e7d0f68450c469c9b742446303eb
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
- Billing officers / HR officers have access to all bank accounts
- Internal users only have access to bank accounts that are not linked to an employee
- Portal/Public users have access to nothing.
TaskID: 3101400
- Improve performances, as the ir.rule restricting private partners
visibility is also applied on res.users by inheritance, on each
prefetch.
- Solve the issue of partners set as followers on records (eg: application
form) and then made private, making them impossible to contact via the
chatter.
- Solve the multiple access issues when trying to access the bank
account, or the private address for non HR people like the accountants
forcing the usage of sudo in the business code.
TaskID: 3101400
This commit remove the forgotten '#TODO: remove in master' that
were forgotten during the FW-port
closesodoo/odoo#125887
Signed-off-by: John Laterre (jol) <jol@odoo.com>
Add a read only field which enables to visualize the DSO ratio (days of sales outstanding) when determining a credit limit for a specific customer on the partner page. This helps the user to know in how many days its customers pay their invoices. In our case, we needed to adapt the computation of the DSO for a single customer. The computation is therefore: DSO = [(Total Receivable/Total Revenue) * number of days since the first account move] for this customer. The amounts used are tax included. If this number is large, it means this customer takes a large number of days to pay the invoices, while a short number means it pays fast.
task : 3196659
closesodoo/odoo#113296
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
Currently when saving a miscellaneous journal entry, we always recompute
the taxes and modify them to be exactly as calculated by us.
However a user could also modify taxes based on a document he got from
a supplier, where the tax might be 1 cent off.
Before this change: On save, we recompute the taxes and override the
user's modification.
After this change: If the user manually modified the taxes, we don't
touch them anymore on save.
task-3262448
closesodoo/odoo#127166
X-original-commit: 8752013127160334c1690518586531fabd6d3f18
Signed-off-by: William André (wan) <wan@odoo.com>
During upgrade, l10n migration scripts that call `try_loading()` can cause an
exception _You cannot switch an account to prevent the reconciliation_ in
`_toggle_reconcile_to_false()` of model `account.account`.
This is caused by new chart template data containing a _False_ value for the
_reconcile_ field, while the already existing record has this field set to
_True_. Under this constellation, the code path leads into
`_toggle_reconcile_to_false()`, which checks for partial reconciliation and
throws the exception when the record is under partial reconciliation.
Also, the update of existing account.account data from the default data
triggers a lot of superfluous re-computes.
To avoid both the update of the reconcile field as well as other unnecessary
updates that trigger superfluous re-computes, filter the default data in the
update case to only update `tag_ids`. This is done after the code that fixes
XMLIDs to be sure about whether the record is being updated or created.
closesodoo/odoo#127099
X-original-commit: 2a8100e9ee8d49a957c1aab21a5a533a28dc2060
Signed-off-by: Carsten Wolff (cawo) <cawo@odoo.com>
Signed-off-by: William André (wan) <wan@odoo.com>
When having lock date for non advisor
set before all user lock date, reconiling
lines between the two lock dates leads
to a wrong calculation of the cash basis
move, even for user with advisor rights.
Steps:
- With a company having cash basis activated
- Set a period_lock_date to a specific date
- Set a fiscalyear_lock_date one month later
than period_lock_date
- With user having Advisor rights, create
an invoice between the two lock dates
- Register a payment in the same period
-> Cash Basis move is created with date == today,
it should be the date of the payment.
opw-3245409
closesodoo/odoo#127060
X-original-commit: ffb9230afbfb5b0f76148e102463e37a55b42f64
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
*: account,event_sale,fleet,hr_attendance,hr_contract,hr_timesheet,
im_livechat,point_of_sale,project
When the user tries to delete a record(s) from the reporting views, this
traceback will be generated.
Steps to produce (Example only):
- Settings > Technical > Actions > Window Actions
- Search for the Work Entries Analysis. Open it and add a 'tree' as view_mode
in that action.
- Payroll > Reporting > Work Entries Analysis menu and select the tree view.
- Select one or more records and try to delete these records.
Error: A traceback appears: "cannot delete from view "hr_work_entry_report"
Handled the unlink access by using their model access of the reporting models.
similarly, this issue resolves in other reporting models.
Sentry-3975590063
closesodoo/odoo#125697
X-original-commit: 209d8c76ce9bb1d6cc7084d55b5623e939af8fbc
Related: odoo/enterprise#42825
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
**Summary**
Currently, if you create a credit note/refund and reconcile it directly
with a statement line (without creating a payment), the
credit note/refund ends up in the "reversed" payment state, whereas it
should be "paid".
**Setup**
- Install `account_accountant`
**Steps to reproduce**
- create a credit note/refund and confirm it
- create the corresponding bank statement line
- reconcile those two
Go back to the credit/refund not, you should see that its payment state
is "reversed", instead of "paid".
opw-3328830
closesodoo/odoo#127027
X-original-commit: 2dd3fa7d4d367e38baf529fdde5d18caa2f238cf
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Signed-off-by: Séna Serge Nshimiyimana (sesn) <sesn@odoo.com>
Before, when you click the Reload button at the chart template in the accounting
settings on an already installed CoA that has no changes in the taxes, it will
delete the tax mappings in the fiscal positions.
Apparently the values['tax_ids'] == [] was interpreted by the ORM as remove all
tax mappings instead of do nothing, so we remove the key from the dictionary
when there is nothing to change.
closesodoo/odoo#127008
X-original-commit: ca40db275f4ba8da2d6a2f1bfcb980fb387fc44d
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
Signed-off-by: Josse Colpaert <jco@odoo.com>
Current behaviour:
When reversing a bank statement,
the partner id gets removed
Steps to reproduce:
1. Go to Accounting, Journal Entries
2. Select/Create a bank statement with partner
3. Click on Reverse entry, then Reverse
4. Head back to Journal Entries
5. Reversal of the bank statement has no partner
opw-3345594
closesodoo/odoo#126992
X-original-commit: 72d82ed813c4baa11060ebcd1df6335410c5e337
Signed-off-by: William André (wan) <wan@odoo.com>
For task-3347812, we needed to create the same Adapter used in l10n_eg_edi_eta. Moving the adapter to account.tools allows us to reuse the same class in different modules.
closesodoo/odoo#126985
X-original-commit: a88027af5f5eb5d0efb4d2c42d5a179aa9bd2dc1
Related: odoo/enterprise#43457
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Signed-off-by: Ali Alfie (alal) <alal@odoo.com>
* = account{_payment}, base, onboarding, payment{_stripe},
sale{_management}, web, website_sale
Use the dedicated onboarding module introduced in 16.0 instead of
the res.company model to store onboarding progress.
It allows
* onboarding steps to be reused across panels
* to support steps that should be completed per-database or per-company
* to clean the res.company model from many fields and methods,
* to remove many views, controllers, actions
Module-specific notes:
* account: We also clean the remaining two steps that are not
part of an accounting panel but make the most sense to be kept here.
* account_payment: Following 8e4e8eb8, the payment provider step is
added to the invoicing onboarding panel. We apply this change here too.
Also impacts the website_sale_dashboard panel (see related ENT PR).
(The "sale tax" one is currently used for to the website sale dashboard).
* payment: Note that the step was already not part of an onboarding
panel within this module.
* website_sale: We clean
* a field not used (The website_sale dashboard onboarding panel used
the payment_provider_onboarding_state field).
* a method that was only called from website_sale_dashboard, so it is
moved there. See related ENT PR.
Includes a few tests.
Moving views/templates/styling, as well as cleaning residual onboarding-related fields and methods in base, including populate.
This also includes restoring the "onboarding_complete" overlay panel
animating it to disappear after a few seconds so that it doesn't hide
text and block buttons to re-open steps.
Task-3025136
Part-of: odoo/odoo#104223
Added a saveForm to wait for the compute/onchange to proc on the save
Added a tax, to be independent of localizations
Changed the product, to have a product with an amount that won't be
impacted by difference of default decimal place from localizations.
Fixes runbot error 22093
closesodoo/odoo#126883
X-original-commit: 2678f490648f81488c8635f2ebc01591935a48f1
Signed-off-by: Wala Gauthier (gawa) <gawa@odoo.com>
Signed-off-by: William André (wan) <wan@odoo.com>
*: account, event_booth, gamification, hr, project,
website_event_track, website_hr_recruitment, website_slides
HTML fields that appear in the front-end can be modified using the
website editor. Some of them are sanitized in a way that breaks the
behavior of snippets that can be dropped within them.
This commit adapts the sanitization of those HTML fields so that the
snippets behave as expected.
opw-3267589
closesodoo/odoo#126708
X-original-commit: 7fd28afaf3e45cafbef80b69aa45c58b31fb3de6
Related: odoo/enterprise#43311
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
Hubert Van de Walle (huvw)