Purpose:
Increase usability of the Plan feature
This change implies changing 'hr.plan.wizard' m2o employee_id
field into m2m employee_ids field.
task - 2797331
closesodoo/odoo#88119
Related: odoo/enterprise#26264
Related: odoo/upgrade#3439
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Previously, the "debounce" util function was broken when passing
immediate=true, this was caused by the fact that the timeout was not set
to null after being executed, leading the function to always act as
though a call is already scheduled.
This commit basically rewrites the entire debounce function to fix this
problem, simplify the code, and make the API of debounce as close as
possible to underscorejs' debounce utility (with the exception that our
debounce function returns a Promise that gets resolved if and when the
call eventually goes through, and with the extra feature that the
debounced function has a cancel method to cancel the currently scheduled
call)
closesodoo/odoo#90297
X-original-commit: 24c39ba1744d83ef9712ef4d3df7db5baf35bc2e
Related: odoo/enterprise#26821
Signed-off-by: Samuel Degueldre <sad@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Bug
===
If you install the module "Google Gmail", you won't be able to save
the settings without filling the API credentials which is annoying.
Task-2837340
closesodoo/odoo#90275
X-original-commit: c09473a4b975287fba8fb862430403d40da2e1ef
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
When selecting products with a certain price in POS (e.g.: 24.99, 5.1), the
POS displays as if there were a discount while they aren't any (e.g.:
~~$24.99~~ $24.99 instead of just $24.99).
Step to reproduce the issue:
1. Install POS and Sales
2. In Sales settings activate "Discounts" and "Pricelists" with advanced price
rules
3. In the pricelist activate the discount policy
"Show public price & discount to the customer"
4. Create a product with a price of 24.99 without tax (or with tax but in the
end the total must be 24.99)
5. In POS select the product. It will show that the price of the product went
from 24.99 to 24.99, while we should simply see 24.99.
Solution: The issue comes from the backend that sends to the POS (upon loading)
some prices with invalid precision (giving, 24.990000000002 or 5.1000000005).
Consequently, following the logic of the POS, he think that the `price` and
`lst_price` are different because the `price` is rounded after applying any
discount (in this case, none). As I was not able to understand why we have such
a rounding in the backend, a workaround was to also round everything before
checking if there is a discount.
opw-2780083
closesodoo/odoo#90345
X-original-commit: 0a8391b4420f038056dfccc7d4391969a1fd97f5
Signed-off-by: Masereel Pierre <pim@odoo.com>
The user profile view is loaded using sudo
https://github.com/odoo/odoo/blob/183b021b2f01595caee7fa672cc5f212a9e63075/addons/hr/models/res_users.py#L172-L185
Therefore, there are in the view field nodes which are restricted to some groups,
the user might not belong to.
These fields need to be in the result of the `fields_get` in order for
the web client to be aware of them.
```
/web/static/src/legacy/legacy_load_views.js:75
Uncaught Promise > models[resModel][fieldName] is undefined
```
This issue happens since odoo/odoo#87522
with which the fields are no longer returned in `fields_view_get`,
renamed `get_view`.
The behavior before this revision was weird:
When calling `load_views` on `res.users` to get the profile form view,
you had fields added in the `fields` key of the `form` view
which were not present in the `fields` list key of the main result dict,
which is supposed to have all the fields of the model.
e.g.:
```
{
'fields': {
...
# address_home_id not there
},
'views_fields': {
'form': {
'arch': ...,
'fields': {
...
'address_home_id': ....
...
}
}
},
}
```
closesodoo/odoo#90331
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
The performFetch method has been rewritten in 14.5. Since then, we're relying
on the is_pending parameter given in the form data. This parameter is used as
if it was a boolean but is in fact a string representation of a boolean. This results
in incorrect attachments since this parameter is used to determine both the
res_model and the res_id of the created attachment.
closesodoo/odoo#90330
X-original-commit: 743face4357403861423ba242fa2be8ac364c546
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
*: sms, snailmail, test_mail
This commit introduces models that define records being 1:1 map with components,
as a step to move further to having essentially all business code in models.
Having code in models is desirable to have very maintainable code, thanks to
robust and declarative code with an ORM-like architecture.
Task-2831082
closesodoo/odoo#90320
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
When a an activity was already created, it is no longer to schedule it
when we change the type to a call or a meeting.
Step to reproduce the issue:
1. Create any activity (without scheduling it) on for example a Quotation
2. Edit this activity and change its type to meeting/call
There are no longer a Open Calendar Button, thus we can't schedule it.
Solution: The issue is simply that the Open Calendar button is only displayed
when the activity is not yet created (and if we have the appropriate category).
Instead of this condition, we should display this button if there are no event
already created.
opw-2824396
closesodoo/odoo#90028
X-original-commit: 1a66a3c4478c5b98951b658b6efbbd0b0d82166d
Signed-off-by: Anh Thao PHAM <pta@odoo.com>
Signed-off-by: Desausoi Laurent (lade) <lade@odoo.com>
Earlier in Odoo, JS views were defined by defining 4 elements: View,
Controller, Model, Renderer. This was complex in some way, because we
wanted to inherit behaviour as well, so it was necessary to think along
multiple dimensions to understand how the code was running.
Then, with Owl, we rewrote some views, and simplified them: views were
now just a Component. Most of the common behaviour now came from the
generic View component that instantiated the concrete view with the
proper informations. In practice, views were still split in views
(which was the equivalent of the Controller of earlier views), Model and
Renderer
Now, this commit reintroduce the Controller, and change the way views
are defined: by an object with multiple metadata, and an (optional)
props function to compute the actual props used by the view.
As a result, views are now much easier to extend/modify.
closesodoo/odoo#89889
Related: odoo/enterprise#26728
Signed-off-by: Géry Debongnie <ged@odoo.com>
A call to get_views returns an object with a "models" key, which is
a mapping from model names to their fields_get. There is an entry
for the main model, and an entry for each model for which there's
an inline x2many view inside the form view.
Before this commit, this was processed in the view service, s.t.
we generated a "fields" object and we added a "relatedFields" key
for x2manys fields, pointing to the fields_get of the related model.
This can create a structure with cycles, which can lead to problems
e.g. if we try to stringify it.
This commit prevents this by no longer nesting the related fields,
but rather keeping them in another structure.
closesodoo/odoo#90271
Signed-off-by: Géry Debongnie <ged@odoo.com>
When a doAction is done, the action service stringifies the given
action and writes it in the session storage, s.t. it can be
restored on F5 even if it's a dynamic action (i.e. not in DB).
However, the stringify operation may crash (e.g. if there is a
cycle in the action description). As we do not control what is
given to doAction, it can happen, and we have to properly handle
it.
This commit simply catches the error, and there's nothing more to
do in this case.
Part-of: odoo/odoo#90271
Processing failed mails is quite consuming operation that leads to browser
slowness or even crash. It's especially painful, because user doesn't see the
reason for it.
Bypass the problem by processing first 100 notifications only.
---
opw-2810681
opw-2754243
task-2806549
closesodoo/odoo#90246
X-original-commit: ec2d3550f32ae1e0585630b5b38befb73ddf2b26
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Signed-off-by: Ivan Elizaryev (iel) <iel@odoo.com>
Test case:
~ 16 000 products and using a pricelist with a fixed price for all products (so ~16 000 pricelist_item).
To reproduce:
Open PoS and add an item to the order
-> Very slow and not responsive: ~5 seconds to do the operation & around 2 minutes to fully load the PoS.
Issue:
`get_price` JS method is called several times and is a bit slow (~200ms). Mostly because of the linear search in the pricelist to check if the product does match.
Note that the function is called once per ProductItem rendered. Each time a product is added to the order the rendering is refreshed for all ProductItem displayed.
So the performance impact is significant if several of them are displayed.
To solve:
As the pricelist per Product.id is constant, we store the possible applied pricelist records on the product itself.
After this commit:
Order does take a few milliseconds to be added (2 ms VS 200ms)
Other notes:
A. With the current OWL version, it is not possible to force the render on only some of the ProductItem. A more appropriate fix could be done with "fine-grained reactivity" using a more recent OWL version
B. It was thought to store/cache the price value on the ProductItem itself. It does have its share of disadvantages (no check if the pricelist time period did start/end, etc.). Either way, with that being implemented, the PoS was still a bit slow (because of the 200ms per `_get_price` call)
OPW-2826122
closesodoo/odoo#90245
X-original-commit: 6f0bfb36a11e52e20b90ca85fc8847faadcdc95e
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
Signed-off-by: Masereel Pierre <pim@odoo.com>
Add a check in 'AccountTestInvoicingCommon' to ensure that all
tests using it are run in post_install.
These tests cannot be run at install, thus they would be ignored
and wouldn't run on the Runbot.
X-original-commit: 659ee179e1beed962026e3abac1bda322c2ac964
[FIX] account,*: Ensure tests using TestInvoicingCommon runs
Add a check in 'AccountTestInvoicingCommon' to ensure that all
tests using it are run in post_install.
These tests cannot be run at install, thus they would be ignored
and wouldn't run on the Runbot.
closesodoo/odoo#90242
X-original-commit: ec36b403edda3fbe3b5bd5f30f31ef6bad680967
Related: odoo/enterprise#26791
Signed-off-by: Florian Gilbert <flg@odoo.com>
Signed-off-by: William André (wan) <wan@odoo.com>
Steps:
Create a product with 2 attributes (2 values each):
> Color: black and white
> Size: small and large
Set their display type to "Pills".
Configure them so that only 2 combinations are possible:
> black - small
> white - large
Go to the website page (product configurator).
The first combination is set. Try to set another one.
Issue:
It is impossible to change neither attributes and, therefore, to change
the combination. With other display types, you can change one attribute,
even if it creates an unavailable combination. You are warned of this
fact, but you can change the other attribute and, by doing so, get back
on another available combination.
Cause:
The stylesheet does not allow to click on an incompatible variant
(attribute value).
Fix:
Delete this property.
opw-2762514
closesodoo/odoo#90236
X-original-commit: 089fda54e383c5f409bab1f2e4c822a4313864e0
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Onockx Audric (auon) <auon@odoo.com>
Fix a lost condition during a refactoring introduced by:
https://github.com/odoo/odoo/pull/82025
When dealing with payment transactions, a payment could be still in draft even after the call the 'action_post'.
closesodoo/odoo#90235
X-original-commit: 14cdb80774b638a39f430bc49c0c4d5a01925d90
Signed-off-by: Olivier Colson <oco@odoo.com>
Signed-off-by: Laurent Smet <las@odoo.com>
Set the survey in fullscreen (without the ribbon) and fixes the 404 page when
refreshing the survey management end page.
The end page has also been slightly modified by:
- hiding the header because it only contains relevant information when the
survey is running (link to join, number of person having answered the current
question, ...)
- hiding previous arrow which were not working (as the session is closed)
- hiding the next arrow which is not relevant and wasn't working
Task-2791044
closesodoo/odoo#90225
X-original-commit: dd6b007e174c19aeb45c1530aff987c393e36f70
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
When a 'manual capture' is set for Authorize.net and a client
make a payment in several partial payments the user can capture
all the authorized transactions without crashing now.
Task - 2676914
closesodoo/odoo#90212
X-original-commit: 68b354f7353e3b5fd1faaad1b762c3c73a286f0f
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Signed-off-by: Horacio Tellez Perez (hote) <hote@odoo.com>
The SVL of in/out moves may be different because of rounding
To reproduce the issue:
(Need purchase,sale_management,stock)
1. In Settings, enable "Multi-Currencies"
2. Edit the USD currency:
- Rounding factor: 1.0
3. Create a product category PC:
- Costing Method: FIFO
4. Create a product P:
- Type: Storable
- Category: PC
5. Create a purchase order PO with one line:
- Product: P
- Quantity: 0.5
- Unit Price: 3.0
- Taxes: None
6. Confirm the PO and receive P
7. Create a sale order SO with 0.5 x P
8. Confirm the SO and deliver P
9. Inventory > Reporting > Inventory Valuation
Error: The quantity of P is zero but its total value is 0.50$
When receiving P, a SVL is created but does not round the value. So, we
have 0.5 x P in stock with a value equal to $1.50
Then, when deliver the product, the FIFO process is executed and create
a second SVL. However, this time the value is rounded:
https://github.com/odoo/odoo/blob/2e4fdcb84ba6375bb51fe71355168cebe2d922a0/addons/stock_account/models/product.py#L290
Therefore, the SVL of the out move has a value equal to $2. This
explains why, when checking the inventory valuation, the value is $-0.50
OPW-2724864
closesodoo/odoo#90251
X-original-commit: 306f3be81192eef504927e30483856669b36b047
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
Some taxes had the wrong type of tax set when updating
from 12.0 to 13.0. The type should be Percentage of
Price instead of Group of Taxes.
opw-2801421
closesodoo/odoo#90249
X-original-commit: d8ff8d9a03f251cff4b87995e7ef3fad5a2b121f
Signed-off-by: Grazioso Andrea (agr) <agr@odoo.com>
Signed-off-by: Fockedey Martin (mafo) <mafo@odoo.com>
When filtering on product templates with a negative operator, the
result
is incorrect
To reproduce the issue:
(Need mrp)
1. Create two products P_compo, P_finished:
- Internal Reference:
- P_compo: 123
- P_finished: 456
2. Create a BoM:
- Product: P_finished
- Components:
- 1 x P_compo
3. Manufacturing > Master Data > Bills Of Materials
4. Remove search filters and apply this custom one:
- "Product doesn't contain 456"
Error: P_finished's BoM is still in the list, but '456' is the internal
reference of P_finished, so this BoM should not be displayed
The filter is applied on the field `product_tmpl_id` of the BoM, which
leads to the override of `_name_search` in `product.template`. In this
method, a call to the `_name_search` of `product.product` is executed:
https://github.com/odoo/odoo/blob/5ff4eb022757d7a522ccb975f8eb64053ef9780b/addons/product/models/product_template.py#L456
which is a good thing because the version of `product.product` handles
the case of the Internal Reference (`default_code`)
https://github.com/odoo/odoo/blob/1e8982e4cf6b604e4da2773f10bdf6cf94c7e683/addons/product/models/product.py#L532-L538
So, the call to this `_name_search` will not return P_finished. However,
later on in the `_name_search` of `product.template`, we call the
`_name_search` of `super` with the same domain (i.e., 'not 456 in name')
https://github.com/odoo/odoo/blob/5ff4eb022757d7a522ccb975f8eb64053ef9780b/addons/product/models/product_template.py#L474-L485
This is the issue: it leads to the `_name_search` of `BaseModel`, which
is the classic version: it does only consider the record's name. So,
this call will return P_finished.
In the `_name_search` of `product.template`, there are actually two
calls to `super`. Considering the commits [1] and [2], it seems that the
goal is the same in both cases: find the `product.template` that do have
any variant yet. However, in the first commit, the domain given to
`super` excludes the templates that have at least one variant, which is
not the case with the second commit (the "problematic" one).
Since both codes have the same goal, we should merge them by keeping the
best idea of each one. From [1], we keep the idea of restricting the
domain: we only look for templates that do not have any variant.
However, this domain needs to be improved: we need to include the
templates whose all variants are archived. From [2], we keep the idea of
looking for the templates outside the `while True` loop. This allows us
to do the search only if required.
[1] 21ae503
[2] 99bae2c
OPW-2791255
closesodoo/odoo#90248
X-original-commit: 942814844e982cbaec2329709c6ba9dd810d0c3f
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
When converting an element to a list element, we didn't preserve that
original element's attributes. As a consequence the text direction was
lost.
closesodoo/odoo#90247
X-original-commit: 0731ff677491d80540fa2ffc645fd2b471a9f61c
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
This introduces a "direction" option on the editor to set the text
direction of the editor (passed by Odoo based on the localization), and
a Powerbox command to switch said direction on a given block. This
allows users to mix several text directions within the same text, eg.
when quoting Hebrew in an English text.
task-2814004
X-original-commit: 693df325588ccaf6385c9f610709f687ccdf61a8
Part-of: odoo/odoo#90247
Once sale_project is installed, when trying to add/remove an employee on
the "Invoicing" tab on the project form view for a big internal project,
this decreases the execution time from 20 minutes / timeout to 12 seconds,
by decreasing drastically the execution time of _get_last_sol_of_customer
on sale_line_id recomputation (_compute_sale_line).
closesodoo/odoo#90263
Taskid: 2836314
X-original-commit: 757358449b7514f371415c528b818020f6147335
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Step to reproduce:
- Create a project with 2 task A and B
- Set task A blocked by task B
- Duplicate Project
Current behaviour:
- Duplicate project is also blocked by original project's task
- Original project's tasks are blocked by new duplicate project's
task
Behaviour after PR:
- Original project's tasks are not changed
- Duplicate project's tasks are blocked by duplicate project's task
if they were blocked by the original project.
- Tasks are still blocked by tasks not linked to the original
project
opw-2818476
closesodoo/odoo#90256
X-original-commit: 5c184628b2278814d2b28366587c8e4b813d0374
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Thanks to
- odoo/odoo#87522
- odoo/odoo#87273
It's possible to speed-up the postprocessing of views
by only requesting a few attributes to `fields_get`,
therefore avoiding to load other costly attributes
(e.g. string, help, selection translations)
Before:
```
In [1]: %time for i in range(10000): env["res.partner"].get_views([(False, 'kanban'), (False, 'tree'), (False, 'form')]);env["base"].invalidate_cache()
r"CPU times: user 9min 19s, sys: 10.9 s, total: 9min 30s
Wall time: 10min 53s
```
After:
```
%time for i in range(10000): env["res.partner"].get_views([(False, 'kanban'), (False, 'tree'), (False, 'form')]);env["base"].invalidate_cache()
CPU times: user 6min 39s, sys: 11.5 s, total: 6min 50s
Wall time: 8min 14s
```
closesodoo/odoo#90168
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
This lifecyle is useless. All attributes that were defined
using this hooks should become fields.
This commit remove `willCreate`, and turn attributes to fields.
Task-2837763
closesodoo/odoo#90198
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
*: hr, hr_holidays, im_livechat, website_livechat
This commit turns some `link`/`unlink`/`unlinkAll` to `replace`/`clear`.
The commands `replace`/`clear` are easier to understand, and also clearly tells what’s the expected resulting value of this field.
This change will help turning big and imperative code into smaller declarative code.
Task-2834598
closesodoo/odoo#89852
Related: odoo/enterprise#26673
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
The isDirty method of the wysiwyg was not very accurate
and was most of the time returning true
even if no changes were done in the editor.
task-2692125
closesodoo/odoo#90200
X-original-commit: bab673488e185ddd7792aedecc3870663290fed3
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
The correct context key is force_company to retrieve the correct
standard_price (which has company_dependent=True)
Use case:
- Set standard price of C as 10 in company A
- Set standard price of C as 20 in company B
- Create a BoM with Final Product -> Sub component (company A)
- Create a BoM with Sub component -> C (company A)
- Connect as company B
- Open the bom structure and cost report
It will display the price of C as 20. However since the BoM is used by
company A it should use the price of company A (10)
closesodoo/odoo#90196
X-original-commit: 275103447381c95e59e281ce6569bcce38b51815
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Having a value of 0 for `maximum_leave` means 'no limit', but it was
considered as a limit of 0 - thus no days were accrued.
closesodoo/odoo#90173
Taskid: 2832160
X-original-commit: 59a319a90a4232f869811ffca62cb356a50a3acf
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Steps to reproduce the bug:
- Create a product attribute “PA”:
- Variants Creation Mode: Never
- Value: “PA1”
- Create a storable product “test”:
- Add the attribute “PA“ and the variant “PA1”
- Save
- Archive the product and then remove the attribute from the product
- Unarchive the product
So the product has no longer the attribute line but if we check the
attribute itself, it is still having the product as a related one.
Problem:
When we remove the line attribute, the `_compute_products` is called,
but as the product “test” is archived, when we try to access the
related products of the product attribute, it returns an empty recordset
because the ORM only returns active records.
Since the attribute `product_tmpl_ids` seems empty and we try to update
it with an empty value, the ORM considers there is no change and so, it
does not update the field value in the DB.
Solution:
We must use `active_test=False` when accessing the related products, so
the ORM returns all records, active or archived.
And since there is indeed a linked product and we are trying to
overwrite it with an empty recordset, the change will be effective.
opw-2806316
closesodoo/odoo#90166
X-original-commit: 7d304078b4ed97d23ec84609e6aea137e8500a18
Signed-off-by: Steve Van Essche <svs@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
Since refactoring to OWL, the bot's avatar was hardcoded, while previous Odoo
release (v13) allowed to customize it.
STEPS:
* open OdooBot profile (user_id=1)
* change avatar to a custom one
* open any record with a message from the bot
BEFORE: always the same avatar
AFTER: the custom avatar is shown
The same issue with OdooBot at messaging systray when Odoo is requesting user to
enable browser notification
---
opw-2827424
closesodoo/odoo#90165
X-original-commit: 1a8992642c6df2d8235140292cbead6d578daf7a
Signed-off-by: Ivan Elizaryev (iel) <iel@odoo.com>
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
To reproduce:
Synchronise an IoT-box with a device with `\x00` characters in its name
=> ERROR: bad query: UPDATE "iot_device" SET "name"=%s WHERE id IN %s
ERROR: A string literal cannot contain NUL (0x00) characters.
Note that this is pretty rare to have this characters in devices names. But it looks to happen with some Chinese devices like the "TaoTronics 2-in-1 Bluetooth & Wired Barcode Scanner USB Portable Bar Code Scanner"
OPW-2748580
closesodoo/odoo#90018
X-original-commit: 5a94d445f1183f256d7847b332b86c81bb711854
Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>
In the current layout that displays user rank in the website profile,
the image overlaps content so the information is not fully readable.
This happens due to wrong value being set as a variable with q-web
directive.
With a recent refactoring (see commit[1]), the `_compile_format`
method replaces % into %%. So in our case, we are trying to set the
width in % (for ex 50%) which is parsed by qweb and converted into
50%%, and thus the CSS property is not applied correctly.
This commit fixes the issue by using `t-value` instead of `t-valuef to
avoid the string formatting related parsing, and thus making sure
that the proper css property is applied.
commit[1] - https://github.com/odoo/odoo/commit/e830953570d5f28aee9bdcdf97af18d3e3246030
task-2792149
closesodoo/odoo#90150
X-original-commit: 97628ef8b5998de546bac44d138ebf5b8a3a43ec
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Since commit odoo/odoo@9c41002b39, the
`.oi-fw` width value contained the `$oi-fw-ratio` variable name instead
of its value once compiled.
This commit fixes it by using SCSS interpolation, as expected.
To use SCSS variable in CSS `calc()`, the variable should use
interpolation to be properly evaluated at compile time.
Note: this apply only for LibSass, Ruby Sass and Dart Sass prior to
1.40.0.
Reference:
https://sass-lang.com/documentation/values/calculationsclosesodoo/odoo#90125
X-original-commit: 2465c9206a78289b294599451959c6cbc2c938d3
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
Since https://github.com/odoo/odoo/pull/87584
with `date` field, pressing enter will removes 1 day to the value.
To fix it we have to ignore the offset suppression used for `datetime`
opw-2818927
closesodoo/odoo#90115
X-original-commit: 46e6475708c7ba8289345c4f7c125f60fc77d08c
Signed-off-by: Achraf <abz@odoo.com>
Steps to reproduce the bug:
- Create a batch transfer with several pickings
- Confirm it
- Delete all the pickings > save
Problem:
The batch does not cancel as it should’ve been
A batch without transfers cannot be confirmed, so it makes no sense to leave a confirmed batch without transfers
opw-2792471
closesodoo/odoo#90104
X-original-commit: dcbf08edbb3a1ec49e84f0828b8f49ac4f836c25
Signed-off-by: Steve Van Essche <svs@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
Sébastien Alix