The patch method is not thread safe, which is very annoying for SH users
for instance.
One obvious issue is that during one thread patching the method, other
threads will also be impacted and have 100 decimal places for the
discount.
But it is even worse:
* thread A start: original = real_original; new = patchedA
* thread B start: original = patchedA; new = patchedB
* thread A end: reset original to real_original
* thread B end: reset original to patchedA
Now at the end of the transaction, the original method simply doesn't
exist anymore, and we only have one of the patches, which forces a
restart of the server to fix it.
opw-3552839
closesodoo/odoo#152168
X-original-commit: 9239ee3a95b474ce2eea92747b64f17f58c5c4cc
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Signed-off-by: William André (wan) <wan@odoo.com>
Steps to reproduce the issue:
1. Open Menu Items
2. Open the form to a menu
3. Select an action type (e.g. ir.actions.report)
4. Select another action type (e.g. ir.actions.act_url)
5. Click on the field next to it
6. Click on "View all"
7. The results displayed match the first action type selected (report), not the second (act_url)
Explanation:
`res_model` is initiated in two functions: `useOpenMany2XRecord()` and `useSelectCreate()` in the `setup()` of the `Many2XAutocomplete` class. The value is never updated for as long as this instance of the field exists.
Suggested fix:
Everytime the key changes, a new instance of the field will replace the current one, calling its own `setup()` with the updated values.
opw-3628017
closesodoo/odoo#151495
X-original-commit: d4078d783717986189f9fbc1b6dd6b264e41e49e
Signed-off-by: Francois Georis (fge) <fge@odoo.com>
Signed-off-by: Stroobant Paul (stpa) <stpa@odoo.com>
Before this commit, we tried to access in javascript the cssRules
property of some stylesheets, to parse and display to the user
potential css errors, to help him to detect and fix them. [1]
Since a recent change [2], people get tracebacks on website pages
in odoo.com (without being logged in).
The issue comes from the fact that when assets are served via a
CDN (which is the case in odoo.com for not logged users), reading
the cssRules throws a CORS error. This error is logged in the
browser console.
We only spotted the issue since [2], because it delays the moment
we access the cssRules property (we wait for translations). Thanks
to that, the error service is ready and able to handle errors, and
it does display the error in a dialog, which allowed us to detect
the issue.
To fix the issue, we filter out stylesheets with a different
origin.
[1] 5e920db3ee
[2] 332268c724closesodoo/odoo#152696
Signed-off-by: Samuel Degueldre (sad) <sad@odoo.com>
Before this commit:
While applying font color, when multiple picture snippet is selected the
color was not properly applied to the selection. It was observed that the
font was unintentionally applied around the figure which was preventing the
proper application of selected color.
After this commit:
It has been made sure that whenever the figure element is enountered it
should not be appended inside font tag.
task-3640901
closesodoo/odoo#152660
X-original-commit: 09a9dede95fbcc230a468913d188988cb9ad01e2
Signed-off-by: Antoine Guenet (age) <age@odoo.com>
Before this commit:
- Emoji picker opened at an incorrect position.
After this commit:
- The Emoji picker now opens precisely at the cursor location
task-3569967
closesodoo/odoo#152645
X-original-commit: 7fd291355d555af229a33665f472db0811876299
Signed-off-by: Antoine Guenet (age) <age@odoo.com>
Before, the tax tag invert is computed based on the entry type if the entry
type is different from "entry" or based on the tax set and the balance of aml
for entries with type "entry".
This is fine in most cases but we can reach a wrong tag invert if we use cash
basis and down-payment.
Here are the steps to reproduce:
- Create a company with cash basis tax (ex: "TVA 20% (Services)" for l10n_fr)
- Make sure no "base tax received account" is set in the cash basis settings
- Create a product with a cash basis default tax and an income account which is
not the default one
- Create an sale order with this product for 100€ + 20% tax
- Create a down payment for 30€ + 20% tax (add the tax to downpayment)
- Create the final invoice with deduction of down payment
- Register a payment on both to create the caba entries
=> Tax report will show 160€ of base instead of 100€
To have the issue, it's important that the income account of the product line
differs from the account used on the down payment line in the final invoice
because the issue involved having a negative base line in the resulting caba
move. If the same account is used for invoice down/product line the caba base
lines will be grouped in one non negative line. For the same reason, the
"base tax received account" must remain empty.
The deduction aml on the cash basis entry of final invoice have an tag invert
at False instead of True. So it's computed as -30€ instead of +30€.
If we reproduce the case with a non cash basis tax, it will work because the
move type will be different from "entry" and tag invert will be computed only
based on the type.
To solve this issue, we now compute the tag invert based on caba origin move
if any to improve the tag invert computation for cash basis entries.
opw-3597141
closesodoo/odoo#152575
X-original-commit: d780a2fc73259244411329027349fad1cb353f34
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
Signed-off-by: Thomas Beckers (tbs) <tbs@odoo.com>
Steps to reproduce
==================
1. Go to the slides website.
2. Open any course.
3. Click on 'add a review' or 'edit review'.
4. Attach any files.
-> Files appear misaligned.
After this commit
=================
They will be perfectly aligned.
Task-3624281
closesodoo/odoo#152443
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Add support for `HALF-EVEN` and `HALF-DOWN` as value
for `rounding_method` argument of `float_round()`.
closesodoo/odoo#152227
Signed-off-by: Raphael Collet <rco@odoo.com>
This commit will change the label to avoid the clash with account audit trail
module.
Also updating the pot of the localisation.
closesodoo/odoo#145149
Task: 3627720
Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>
In the context of the bookkeeping act in denmark, we need to record all the
modification and delete of all the input, so we should by default install the
audit_trail module.
Since they need this in 17.0 we will make a bridge module.
Task: 3627720
Part-of: odoo/odoo#145149
Since 857c485175, rates are
not truncated anymore.
The stored rate value on SO, between SO currency and company currency
was not adapted and was still truncated, leading to invalid values
after rates conversion.
See also 5a621cea4c5a16998a3b83890144f81a3880244b where the same solution
was appied to pos orders.
opw-3638199
closesodoo/odoo#152592
X-original-commit: 6291424bd49a55f446f87c09af71fd13a1c13851
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Steps:
- Go to website and edit
- Add an event block
- Change the template of the block from picture to card layout.
- Replace the image of one card by a 4k image.
Issue:
The custom cover is blurry.
Reason:
By default the custom cover is resized to 256x256 (but not the default one because
it uses a static image path).
opw-3390459
closesodoo/odoo#152278
X-original-commit: d6d24ceb2a5b6e735ffb2fe1d5cea1f8f945f288
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Jérémy Hennecart (jeh) <jeh@odoo.com>
Issue:
Possible to reproduce in 17.0: when adding a new field to the website
form of the "Extra Info" page in the eCommerce, a traceback is raised
(`OwlError: Missing template: "website.form_field_json"`) when the user
selects "Delivery Point Address" (`sale.order.access_point_address`).
Explanation:
JSON fields (which exist since [1]) are not supported as selectable
types in website forms, and they should not be because customers would
not be able to properly fill them out.
Fix:
Filter out all JSON fields from the list of authorized fields in website
forms; they will not appear in the list of selectable types anymore.
[1]: https://github.com/odoo/odoo/commit/7eeba9d205d2dace571b5d0895ddba6290a512db
opw-3596713
closesodoo/odoo#152545
X-original-commit: 28c3eb5878ad6f3d40a096803f3ba4aef5ef7937
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Steps to reproduce the bug:
- In Website edit mode.
- Drag and drop a "Cover" snippet into an empty page.
- Sets the "Height" option of this snippet to "100%".
- Drag and drop a "Media List" snippet into the page.
- Drag and drop a "Popup" snippet into the page.
- Save the page.
- Scroll quickly the page to the bottom before the popup appears.
- When the popup is open, resize the window to trigger a "resize" event.
- Close the popup.
- Scroll the page to the top.
- Bug: the height of the "Cover" snippet is a way too high.
This bug occurred because the height of the snippet with the "Height:
100%" option enabled is calculated based on the scrollable element it is
in (since this commit [1]). However, when a popup is opened, the
detected scrollable element was incorrect due to the "overflow: hidden"
rule added to "#wrapwrap" by the "modal-open" class on the <body>.
[1]: https://github.com/odoo/odoo/commit/b371cb42cb67115692464c102813b7ebd54785d9
opw-3643498
closesodoo/odoo#152402
X-original-commit: 35b3f676820f7a19e842b3403a5ebcf956714a70
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Benjamin Vray (bvr) <bvr@odoo.com>
we execute a subprocess without checking if an error occurs
so we place the subprocess.call() in a try except
closesodoo/odoo#152331
X-original-commit: 4adda36260f3ba0fdf75688b419593006b80adb7
Signed-off-by: Yaroslav Soroko (yaso) <yaso@odoo.com>
Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>
Prevent an infinite loop when the cycle in the parents does not contain
the starting id: `3->2->1->2->1...`
Example:
```
>>> m=self.env['ir.module.category']
>>> c1,c2,c3 = map(m.browse,[1,2,3])
>>> c2.parent_id = False
>>> c3.parent_id = False
>>> c1.parent_id = c2
>>> (c3|c2).parent_id = c1 # this never ends
```
With current patch the call to `_check_recursion` successfully detects
the new cycle.
closesodoo/odoo#152080
X-original-commit: e7c6445dd1896bb182b44af768814f297027d3a4
Signed-off-by: Raphael Collet <rco@odoo.com>
Signed-off-by: Alvaro Fuentes Suarez (afu) <afu@odoo.com>
Before this commit:
- When a banner was inserted at the first line and Ctrl+A and backspace
is performed, nothing happens.
After this commit:
- Now, all the content except banner will be selected and removed.
task-3432167
closesodoo/odoo#151735
X-original-commit: 530f102720458e5e1c224bf38073cd763309bf0a
Signed-off-by: Antoine Guenet (age) <age@odoo.com>
Before this commit:
- Performing ctrl+a and backspace inside a banner would unintentionally remove
its first element, which could be a block tag
After this commit:
- Now performing ctrl+a and backspace inside the banner will no longer remove its
first element if it's a block tag.
task-3432167
X-original-commit: ddc8587f8a712fdddaa714bee2931cb149c03a38
Part-of: odoo/odoo#151735
Before this commit:
- Inserting a banner did not set focus inside the banner; instead, focus
was placed after the banner.
After this commit:
- Now, upon creating a banner, focus is now correctly set inside the
banner.
task-3432167
X-original-commit: 7327d20626ec9164f47e00f7094a36b8794db5de
Part-of: odoo/odoo#151735
Before this commit:
- Inserting a banner after already existing content it's impossible to
go to the next line of the banner.
After this commit:
- It's now possible to navigate to the next line of the banner.
task-3432167
X-original-commit: 05a879f81ac59d47b718abbb5966fd4f8214e1de
Part-of: odoo/odoo#151735
Steps to reproduce
==================
- Use a laptop with touch or apply the following patch
```diff
diff --git a/addons/web/static/src/core/browser/feature_detection.js b/addons/web/static/src/core/browser/feature_detection.js
index 21c6294b1b0e..64c4bc9b899c 100644
--- a/addons/web/static/src/core/browser/feature_detection.js
+++ b/addons/web/static/src/core/browser/feature_detection.js
@@ -62,6 +62,7 @@ export function isDisplayStandalone() {
}
export function hasTouch() {
+ return true;
return browser.ontouchstart !== undefined || browser.matchMedia("(pointer:coarse)").matches;
}
```
- Enable debug mode
- Go to contacts
- Hover the mouse over a question mark next to a field
=> Nothing happens
Cause of the issue
==================
The function `shouldCleanup` returns true when the device has touch and
the popover has been triggerd with the mouse
opw-3694156
closesodoo/odoo#152629
X-original-commit: 27242a0f1070b6b16c16e479e22dc0ccad0d9659
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
The root of the issue:
The external identifiers are not guaranteed to be unique on their `name`
alone, the unique constraint is on the `name` and on the `module` fields.
Before this commit:
If a user or third party app were for example to create an external identifier
"project.autovacuum_job" and point it to an `ir.cron` record,
then that `ir.cron` would also be kept activated, which could cause
major issue if it makes calls to external systems, sends mail, etc...
After this commit:
All the crons are deactivated by the neutralisation, except for
the autovacuum
closesodoo/odoo#152535
X-original-commit: 0cc89a026d05b37714864e7ebb695e77ef2d1e7d
Signed-off-by: Jérémy Kersten <jke@odoo.com>
Signed-off-by: Alexandre Moens (mao) <mao@odoo.com>
Some of the translation needed to be done or updated,
especially the ones about the warnings.
closesodoo/odoo#142596
Signed-off-by: Josse Colpaert <jco@odoo.com>
All the pre-sending checks that were done on the invoices before sending are now split by model, so that there's more separation.
ActionableErrors is used to show all the errors and give the user a quick action to fix the problems.
"These partners have an incomplete address, please verify xyz"
-> View partners ----> <partners view>
- Tooltip for IT XML export when readonly
We relied on the Italian xml export field's help tooltip before.
Now like other export options we have a dedicated <i> tag only shown when the field is readonly.
- Cannot change to test/official if you don't register
If you have Demo edi_mode, and you change to Test/Prod but don't register,
the EDI proxy user won't be deleted, and the edi_mode won't be saved.
So you think you changed to Test, but you haven't.
For compatibility in 17.0
- `l10n_it_edi_warning_message` must be maintained for the old view to work and make sense.
- Modified `l10n_it_edi_warning_message` becomes then `l10n_it_edi_actionable_errors`
Part-of: odoo/odoo#142596
`Model_get_actions_record(**kwargs)` helps building `ir.actions.act_window`
actions based on a certain model on very simple cases.
It opens a form if there's just one record, a list,form if there's more than one.
Given keyword arguments will overwrite those in the action.
This change serves as a base for the `actionable_errors` widget,
where it's used extensively to remove boilerplate code.
Part-of: odoo/odoo#142596
The new widget is meant to be a warnings header for wizards and forms,
where flows like EDI can list a series of errors and actions for
the users to fix the roadblocks.
The HTML result is an `<ul>` list with a point for each warning
and a link to a given action. Clicking the link will fire the execution
of a Python method on the backend, also passing back to it a series of
parameters the component has stored on setup time.
During setup, ActionableErrors accepts this structure as incoming data:
{
'error_key' : {
'message': _("Description of the warning"),
'action_text': _("Text of the link"),
'action_model': 'model.on.which.the.method.is.called',
'action_name': 'action_python_method_name',
'action_params': [...],'
},
...
}
A map is used instead of an array, so that the Owl framework
could be more precise in rendering changes in future development.
(i.e. remove a warning after clicking the action link
without re-rendering the whole widget)
This Widget will be used both for `l10n_it_edi` and `account_intrastat`
and can be embedded in many other occasions.
Part-of: odoo/odoo#142596
Before: When a user receive a mass_mailing and click on the
unsubscribe button, he arrives on the unsubscribe webpage where
the first sentence stay in english whatever the website language
Step to reproduce:
- Create a db with the email marketing and web module
- Create a mailing list with at least one recipient
- Send the mailing (catch the email with an email catcher, ex: mailhog)
- Click on the unsubscribe button
Now: The first sentence is in the website (or portal) language
opw-3538873
closesodoo/odoo#152579
X-original-commit: 6ba3dc277b9bf6b093eeefe889f20734ae4d135b
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Slot params are dynamic content, similar to props, and are not
translated.
There is no point in adding untranslated content to the .pot files; so
this commit prevents the content of slot params from being exported for
translation.
Task-3718993.
closesodoo/odoo#152606
X-original-commit: b839faf09be259ffdccf9d872e646e4ebe4a8bcb
Signed-off-by: Géry Debongnie <ged@odoo.com>
Signed-off-by: Louis Wicket (wil) <wil@odoo.com>
To reproduce
=============
- Go to shop page
- Edit the page
- select a product
- add a ribbon
- modify the ribbon (background or text color)
the ribbon is not updated
Problem
=======
the default ribbon are using the bootstrap class "text-bg-*" to set the
background color and the text color. But the editor expects the ribbon
to have a class "bg-*" and color css style. That's why when editing, the
class "text-bg-*" is never removed so each time it's taken instead of the
added style.
Solution
========
remove the class "text-bg-*" from default ribbons and use the fields
"bg_color" and "text_color" to set the background and text color
opw-3674520
closesodoo/odoo#152604
X-original-commit: 2bd09b4b41b27780ec20820cac76051ae20b7f4d
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Signed-off-by: Abdelouahab Laaroussi (abla) <abla@odoo.com>
Problem
---------
Currently, when importing a UBL/CII xml, the bank account details remain
empty while we usually have the bank account number and the BIC code
provided in the XML.
Objective
---------
Autofill the partner_bank_id field on the invoice using the values
provided in the UBL/CII XML.
Solution
---------
Currently, UBL XML are organized as such:
PaymentMeans(0..n)
|-PayeeFinancialAccount
|-ID
|-FinancialInstitutionBranch
|-ID
And CII as such:
SpecifiedTradeSettlementPaymentMeans(0..n)
|-PayeePartyCreditorFinancialAccount
| |-IBANID (for SEPA)
| |-ProprietaryID (for national payment)
|
|-PayeeSpecifiedCreditorFinancialInstitution
|-BICID
We first fetch the account numbers from the XML (several may be
present) and store them in a list.
This list is sent to the edi_common which will attempt to find one
account that match the given values. If none are found, we create one
bank account for each piece of bank data found in the xml. We then set
one account that was freshly created.
task-3636150
closesodoo/odoo#152559
X-original-commit: 63a32be1e3b32762bc489e17eea634a071a597b9
Signed-off-by: Habib Ayob (ayh) <ayh@odoo.com>
Signed-off-by: Antoine Boonen (aboo) <aboo@odoo.com>
Before the current PR, the version of Odoo along with the git branch of
the IoT Box and the associated image were never logged. Adding this
information to logs allow to to debug / inspect issues more easily
task-3716879
closesodoo/odoo#152558
X-original-commit: 8bf1c8984948b003544427eb81f66514ed783bd0
Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>
Create an automation rule for a field for which there's no onchange
yet. The rule type is "on_change" (on UI change).
This type of automation rule adds an onchange method on the
selected fields, which thus involve the onchange mecanism: the
"on_change" attribute will be set on that field nodes in views,
s.t. when the user changes it, onchange rpcs are done.
However, views are cached, and creating such a rule didn't clear
the cache. So if the view was already in cache, the rule seemed
not to work, because the client still received the old version of
the view, without the "on_change" attribute.
This commit clears the cache when such a rule is created, s.t.
after a client reload, the feature gets enabled as expected.
opw 3701125
closesodoo/odoo#152498
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Before this commit, it was possible for users to drop website snippets
(e.g., the "Badge" block) inside the inline form of payment acquirers.
At least for Adyen, it would prevent payments because the payment inputs
within the inline form wouldn't load anymore.
As inline forms are part of the payment form widget, which itself is not
customizable by users, this commit blocks the website editor inside the
entire payment form and its children elements.
opw-3607719
closesodoo/odoo#152469
X-original-commit: 814ee63956fce740b8cdae0a235351d8a9e6028d
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Summing discount percentages doesn't mean
anything.
This commit makes sure the operator used to
compute discount on group of records is 'average'.
It won't always be meaningful, but in some cases,
e.g. when the solines only hold one product,
and the lines are grouped by product.
opw-3649377
closesodoo/odoo#152455
X-original-commit: bf4aa3fdfcb6b2b3a5b4411130321e154fa098aa
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
The opportunity is taken to fix an issue where removing a record from
assign would not update the inverse.
closesodoo/odoo#152442
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Steps to reproduce the bug:
1. Create a storable product "P1."
2. Create a quant for P1 with a package and apply.
3. Navigate to the package.
4. Attempt to unpack.
Problem:
A user error is triggered:
"Quant's editing is restricted; you can't perform this operation."
This occurs because when accessing the package from the quant, we are
in inventory mode. And as the "package_id" field is on the forbidden
list, the error is raised.
Solution:
During the unpacking process, ensure that we are not in inventory mode.
opw-3687164
closesodoo/odoo#151826
X-original-commit: 6d38d26de994e25b3b552c341bae27799ac63b38
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
Currently, if a customer wants to edit his/her information from the
Portal access, they cannot modify the information linked to EC.
This commit aims to support Ecuadorian companies needed information when
editing the portal contact information:
- added "Identification Type" field
- renamed "VAT" to "Identification Number"
- make those 2 fields required
closesodoo/odoo#142730
Task-id: 3620196
Signed-off-by: Josse Colpaert <jco@odoo.com>
Currently the eCommerce workflow in Ecuador lacks some information
needed to issue EDI invoices.
The main adaptions needed are:
* Identification type and number in the checkout process (in the billing address)
* SRI Payment Method in the eCommerce Payment Method
SRI Payment Method
* The SRI Payment Method value is required for the EDI
* In the payment method form view the SRI Payment Method field is hidden
if the list of fiscal countries of the selected companies does not include Ecuador.
* Payment methods which do not have an associated SRI Payment Method
cannot be used in the eCommerce checkout of an Ecuadorian company.
* A (default) SRI Payment Method has been addeded to some payment methods to simplify the setup.
* When creating an invoice from a sales order we try to compute the SRI Payment Method as follows:
We consider all the SRI Payment Methods of the payment methods of the payment transactions associated with the sales order.
If there is exactly 1 such SRI Payment Method we use this on the invoice.
This should ensures that we can always set the SRI Payment Method on invoices created through the eCommerce flow.
task-3585823
Part-of: odoo/odoo#142730
In Ecuador, the ZIP code is not a required field to create invoices.
Customers usually don't even know their ZIP code as the street number,
city and state (province) are mostly used for delivery (and not the
ZIP code).
task-3585823
Part-of: odoo/odoo#142730
Confirming a repair order with parts assign moves quantities.
Ending it without any of the picked flags automatically pick them.
But ending it with some non-picked parts does not cancel the moves.
Now they are.
closesodoo/odoo#149157
Task: 3679247
Signed-off-by: Steve Van Essche <svs@odoo.com>
Before this commit, there was a race condition with the statusbar
field, and more specifically with useRecordObserver.
The issue could be reproduced in the form view of project.task. In
an existing task, belonging to a project with some stages, change
the project to another project with its own stages. It might happen
that the displayed stages weren't the ones of the newly set project.
If this didn't happen directly, this happened upon saving (i.e. the
correct stages are displayed just after switching the project, but
as soon as the user saves the record, the former stages are back).
This happens because useRecordObserver used an outdated version
of the props to get the domain (i.e. the props of the component
have been updated, but useRecordObserver still used the old version,
in particular the old props.domain).
This commit fixes the issue by ensuring that we always use the last
version of the props.
opw 3693113
closesodoo/odoo#152433
Signed-off-by: Francois Georis (fge) <fge@odoo.com>
Purpose
=======
From O.6 to 0.04 seconds to call get_allocation_data_request (15x faster)
and 574 to 25 requests for an employee with 10 years of XP in odoo.com.
Part-of: odoo/odoo#152311
Before this commit, discrepancies between
leaves and allocations for an specific employee
and a specific time off type would have prevented
the employee from taking any time off for that
time off type.
It would also affect their dashboard.
__How to reproduce the issue:__
- time off type without negative amount
- create 2 allocations: last year and this year
- create a leave last year
- remove last year allocation from DB
- you cannot take leaves this year
- dashboard amount is affected by last year's leave
__Changes brought with this commit:__
This commit keeps the logic identical for negative
time off types. However, for the others, the
check ensuring the allocation validity for the
leave will now check the discrepancies before and after
a time off creation or modification. The error
will be thrown if the discrepancies have changed, meaning
that the leave had an effect on it. This way, any
other issue will not prevent leave creation.
Those leaves are still noticeable through the warning
though, meaning that they can be noticed and dealt with
accordingly.
Part-of: odoo/odoo#152311
william-andre