Before this commit:
redirect_url may have never been asssigned before being read
opw-2827002
closesodoo/odoo#90374
X-original-commit: 1aa35cba14528f413e9813707c406f31bfb07967
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>
Fixing docstring of new get_view method (odoo/odoo#87522),
to include it in the doc (and replace reference to the deprecated
method fields_view_get).
models.py:docstring of odoo.models.BaseModel.get_view:8: WARNING: Unexpected indentation.
models.py:docstring of odoo.models.BaseModel.get_view:9: WARNING: Block quote ends without a blank line; unexpected unindent.
+ some little improvements to the docstring
closesodoo/odoo#90372
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Step to reproduce:
- As mitchell admin
- Change user's/employee tz to something != UTC
- Go to time off
- Click on the calendar
Current behaviour:
- Wizard Popup with a timezone warning
- If the same thing is done with the 'New Time Off' button, the
warning is not present
Behaviour after PR:
- No Warning
- `request_unit_custom` should be False if `holiday_status_id` is
set which might happen in default_values.
opw-2828936
closesodoo/odoo#90357
X-original-commit: 5565eb9f3dc4259f1304373eff83f7d54a0db7be
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Remove most values uselessly specified because giving the same value as
the default one (see _DEFAULT_MANIFEST in odoo/modules/module.py)
* auto_install is Falsy by default
* author is Odoo SA by default
* summary & description are empty strings by default
* application is False by default
* test, demo, depends and data are empty lists by default
This will reduce noise/inconsistencies between manifests specifications,
simplify analysis of manifests content, ...
closesodoo/odoo#90209
Related: odoo/enterprise#26807
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
*: hr, im_livechat, snailmail, website_livechat.
This PR prepares the ground for the one introducing the new environment in the
discuss app. Indeed, tests will now use the mainComponentRegistry in order to mount
those components. Doing so, the parameters has{Discuss/Dialog/ChatWindow} will become
obsolete. Removing those parameters now helps reducing the noise in the main PR.
task-2582313
closesodoo/odoo#90120
Related: odoo/enterprise#26759
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Model pattern was too permissive, separator is the literal `.`
character, not any random thing.
Also remove unnecessary bracket expression, it's unnecessary when
matching a single item.
OPW-2836106
closesodoo/odoo#90107
X-original-commit: 320cdb4e85cb86915fa25cfda8f17e0a372e765e
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Signed-off-by: Raphael Collet <rco@odoo.com>
Current behavior:
When opening the giftcard popup in a PoS the focus would always
always go back to the first input field after typing in any other
input field.
Steps to reproduce:
- Install PoS and activate gift card
- Activate option "Scan an existing barcode and set a price"
- Start a PoS session
- Access the giftcard popup
- Select "Scan and set price on gift card"
- Type anything in the second input field
- The focus will go back on the first input field
opw-2825163
closesodoo/odoo#90081
X-original-commit: 84c129c7e05bb22e5dde272ab0a7cf8d4e1c2011
Signed-off-by: Grazioso Andrea (agr) <agr@odoo.com>
Signed-off-by: Engels Robin (roen) <roen@odoo.com>
Description of the bug :
Registering a payment for two confirmed bills/invoices from different partners would result in a stack trace.
Steps to reproduce :
Create a bill from a specific partner and confirm it.
Create another from another partner, confirm it.
From the list view, select both those documents, click Register Payment.
The StackTrace appears.
FIX :
handled the case by setting the payment_difference field to 0.0 if the wizard contains multiple payment batches.
Modified some tests to detect this behaviour in the future.
closesodoo/odoo#89757
X-original-commit: def467e82b12c5ec7284ed9c966bb13ab3a77298
Signed-off-by: Laurent Smet <las@odoo.com>
The base model is modified in order to be able to make comparisons between
recordsets contained in lazy values. The isinstance method will always
return an error, so we consider that we receive a recordset and try to
access the `_name` and `_ids`. If an error is triggered, it was not a
recordset.
This way of doing it involves little change in performance (improvement
when it is good and decrease when there is an error) because we do not
test if it is a recordset before comparing it.
closesodoo/odoo#89141
Signed-off-by: Rémy Voet <ryv@odoo.com>
The test 'test_inactive_related_product_update' raises a ValueError
"Wrong value for product.template.detailed_type: 'product'".
(which causes the L10n nightly build many fails)
See https://github.com/odoo/odoo/pull/89468closesodoo/odoo#90339
X-original-commit: d0ff5fe311cd69a3068593142aff66b09f13c43d
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Julien Van Roy <juvr@odoo.com>
Previously, the useAssets hook would load the templates from the given
bundles into the qweb instance that was in the environment. In owl 2,
qweb is no longer in the environment, and templates need to be loaded in
the app.
This commit fixes that by exporting a function to load templates in the
main app from assets.js, when the main app is created, it should be
written on the function in a similar vein to renderToString, so that all
further calls to the function will load the templates in that app.
This commit also adds an actual lazy-loading test in the
test_assetsbundle module, as we don't want to pollute the manifest of
web with bundles that only exist for one specific test.
closesodoo/odoo#90122
Related: odoo/enterprise#26776
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
To find the 'country_code' field.
closesodoo/odoo#90255
X-original-commit: 980b7d09f63de17651e27d06170c8265530b99b1
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
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>
Moens Alexandre