*: 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>
Before this commit, some editor options could break the autocompletion
of form fields. This commit ensures that auto-fillable fields remain
auto-fillable when using the editor. In addition, this commit improves a
test to ensure that this bug does not reappear.
Steps to reproduce the fixed issue:
- Go to the "contact us" page or drop a form in a page
- Edit an auto-fillable field of the form ("Your Name" for example)
- Change the label position of the field
- Save
-> The field is no longer auto-fillable.
task-2715201
closesodoo/odoo#90103
X-original-commit: 455e0cc58c7fa1e02ebaa19dd2f99d829ca6e302
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
This commit allows to give priority to auto-fill values and to values
coming from a data-for when in addition to one of these values this same
field has a default value. The form's test are also improved so that it
checks for this desired behavior.
task-2715201
X-original-commit: 7b23d3aacd22f87cb0c22ecd0478eba4a17b4bf3
Part-of: odoo/odoo#90103
Some form fields are dynamically filled. As the inputs that hold these
values do not always have a value property, their HTML value attribute
can be modified. Before this commit, the form option had to remove these
values before saving so that these values wouldn't become default values
(see [1]). Sadly this system is problematic and can remove default
values set by the user. This commit ensures that only values from
auto-fillable fields and from data-for fields will be removed and from
now, the suppression of these values is done at a more appropriate time
than what is done in [1]. Test is added with this commit to verify that
the default values are not erased on later form edit.
Step to reproduce the fixed issue:
- Create a form, add a (required hidden) field with a default value
- Save, then enter edit mode again
- Add a new field and save again
The default values of the form are gone. Enter edit mode again to see
the hidden input, you will see there is no value.
[1]: https://github.com/odoo/odoo/commit/b637a5e32f767b62736241042f88fa0cecf9f10b
task-2715201
X-original-commit: 043e1fdf923d2037dd8da128ab99388f0c92e544
Part-of: odoo/odoo#90103
File uploader might be deleted because it is linked to views, but the process of
upload should still happen for the related thread.
closesodoo/odoo#90102
X-original-commit: aa57c1804ecd9c88188e33c098b805f65f103a33
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Translations of type model_terms are similar to model and the access
rights can be checked on the referenced record instead of
ir.translation
closesodoo/odoo#90101
X-original-commit: 992a919d09c3ba224a64241f4a6c16c1a086eb4b
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
- Filter in attributes rather than filter out.
The goal is to not gather attributes which are
costly in term of performance if they are not requested
in the first place.
e.g., with all modules installed:
- Before rev:
```py
In [1]: %time for _i in range(1000): self.env["res.partner"].fields_get(attributes=['readonly', 'required', 'states', 'invisible']);self.invalidate_cache()
CPU times: user 1.99 s, sys: 9.83 ms, total: 2 s
Wall time: 2.03 s
```
- After rev:
```py
In [2]: %time for _i in range(1000): self.env["res.partner"].fields_get(attributes=['readonly', 'required', 'states', 'invisible']);self.invalidate_cache()
CPU times: user 345 ms, sys: 0 ns, total: 345 ms
Wall time: 345 ms
```
- Use the `_description_` mechanism for the attributes `name` and `type`,
so its no longer needed to treat them as exception in
`field_get` and `get_description` respectively,
and make the code shorter and cleaner.
- Move out from `fields_get` the block
```py
has_access = functools.partial(self.check_access_rights, raise_exception=False)
readonly = not (has_access('write') or has_access('create'))
...
if readonly:
description['readonly'] = True
description['states'] = {}
```
because:
- It meant you had a different behavior using `fields_get` or `get_description`
for the keys `readonly` and `states`, meaning a field could be marked as `readonly`
by `fields_get` but not by `get_description`, which is confusing.
- It is actually used in only one place, the post-process of back-end views,
which mark the fields readonly for the web client if you do not have
the create or write access to their model.
closesodoo/odoo#87273
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
* web_editor
Prior to this commit, removing a snippet while its widget was still
active could lead to slow removal as editors would be created for its
inner content.
Stopping a widget before removing it is good practice as it will clear
the DOM from any content it may leave behind and will prevent snippet
editor to be created for its dynamic inner content.
As an example, the `Products` snippet had SnippetEditors being created
for its product cards, which could lead to slow removal especially
in later versions of Odoo. E.g. in 14.0, because ImageTools were
introduced.
Closes#85464
task-2781418
closesodoo/odoo#90100
X-original-commit: ca1359e0f40b94b93eb8cfd6834a05796f64c675
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Steps to reproduce the bug:
- Create a MO with work orders
- Confirm the MO
- Under the tab Work Orders > click on the button start multiple times quickly
Problem:
Several `mrp.workcentre.productivity` are created for the work order,
whereas normally the workorder can have only one timer started (without date_end).
Solution:
- If the workorder already has a timer running, return true to stop the process
- Add a constraint to block the user when he tries for example to create with an rpc call several `mrp.workcenter.productivity`
without an end date for the same workoder
opw-2802436
closesodoo/odoo#90094
X-original-commit: dd22195a75ec437e42424ee95ca9a41feeb48b0b
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
In a multi-company environment, creating a product template will always
try to assign it's route to `route_warehouse0_buy` but this throws an
error if the current company is not the one of the route
Steps to reproduce:
1. Install Inventory and Purchase
2. Go to Settings > Inventory > Warehouse and enable Multi-Step Routes
3. Open Inventory and go to Configuration > Warehouse Management >
Routes
4. Open the 'Buy' route, assign it to one of the company for example 'My
Company (San Fransisco)' and save
5. Go to Products and select an other company for example 'My Company
(Chicago)'
6. Click on `CREATE`
7. An error is thrown, preventing the user from creating new products
Problem:
Function `_get_buy_route` always fetched the same route but this route's
company might have been changed so an error is thrown when trying to
access it from the other company
Solution:
Check if we have access to `route_warehouse0_buy` before using it.
opw-2805154
closesodoo/odoo#90093
X-original-commit: 1a733ae0bfd9f1cb1e90a2cab80af290560c6f12
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: Guillaume Merlin (megu) <megu@odoo.com>
set test env and remove username,password,token and token validity
so call never go to production server from test db
closesodoo/odoo#90084
X-original-commit: 955a83f9e773ad1bf7ce0aa4a834d9ca833cd580
Signed-off-by: William André (wan) <wan@odoo.com>
Before this commit: whenever we left the PaymentScreen when we were paying (either by reloading the page or by backing to the ProductScreen), the real payment status was not properly saved even tho the payment has been paid or cancelled.
With this commit: whenever we go to the PaymentScreen with a pending payment line with Adyen, we fetch the latest status from the back end. This way, the front end will always have the latest status of the payment.
opw-2802676
closesodoo/odoo#90083
X-original-commit: 07b30c519b101a2998f5320dde5203bfc964b7e9
Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
Purpose is to ensure tools are called like intended, notably by filtering
input and raising if an unexpected value check is asked. Some code is also
made a bit more generic to have the same kind of parameters when searching
for mail.mail.
In this commit we therefore fix some bad calls to assertSentEmails which
were not checking the right stuff.
closesodoo/odoo#90082
X-original-commit: d9759b2ee86b79b4fb2739a4aebd24a8044cf947
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
This PR helps redducing the noise in the one introducing the new environment
in discuss. Indeed, the createWebClient helper will always be used so we won't
be able to use the form utils anymore. Moreover, since the clean up of the widget
is now handled by the start method, the calls to widget.destroy in those test was
not required.
task-2582313
closesodoo/odoo#90079
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Before this commit, the public user would be prevented from creating,
reading, or using payment tokens entirely. This was put in place in an
effort to homogenize the way each application interacts with tokens,
and because it was considered more logical to only create tokens when
you can see actually them afterward. This however led to an undesirable
side effect in Subscriptions where customers would pay while being
logged out, thus preventing the token from being saved and failing the
automatic renewal of the subscription.
With this commit, we enable the public user to create tokens from any
payment flow. This also means that when a token is created, its owner
will not see it until they log in. This commit also reverts 2a084c48
which was intended to hide payments acquirers from the public user if
their payment would end up being tokenized.
opw-2789340
closesodoo/odoo#90061
X-original-commit: 4e03d4b6106f10522dd5f1839a0f941ca6b202fa
Related: odoo/enterprise#26741
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
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#90057
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
For some unknown reason (part of a huge refactoring during the BS3 to
BS4 migration at [1]), a background color was applied to the <header>
(behind the navbar) once it becomes fixed (after scroll if the related
header scroll effect has been chosen).
That $light color made no sense as is visible if the header uses rounded
corners but is impossible to edit / remove.
This commit, for master, simply removes it. This is not possible to
migrate (for example to try and handle the case where the menu color is
transparent) as it would require to know the color of $light. It would
be overkill anyway, this just relies on users with that problematic
transparent header (probably nearly no one) to review their header in
the next Odoo version.
[1]: https://github.com/odoo/odoo/commit/09f40036b9c14161db90c6128861369c91c8c64e
opw-2686695
closesodoo/odoo#90058
X-original-commit: f721e6187933cde4366a7f987fb80612da581670
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
This PR prepares the ground for the introduction of the wowlEnv in the discuss app.
Indeed, the local_storage service is not available as a service anymore so the one
from the browser is used instead. In order to reduce the noise in the main PR, this
change is done separately.
task-2582313
closesodoo/odoo#89851
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Current behavior:
The invoice payment term of the report is a p tag with another p tag inside like:
<p name="payment_term">
<span>
<p> This is a payment term note</p>
</span>
</p>
but because nested p tags are not supported in html de result in the browser is something like:
<p name="payment_term">
<span></span>
</p>
<p> This is a payment term note</p>
<p></p>
Similar behavior can be observe for the fiscal position note.
Expected behavior:
The code should respect html format rules and not have nested p tags.
Solution: We replace the parent p tags by div tags, and we modify xml file that have xpath relying
on this tag.
opw-2804933
closesodoo/odoo#88660
Related: odoo/enterprise#26372
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Before when reporting in the sale module in a multi-company
environment currencies where not converted to a unique currency
before mathematical operations (sum, avg, ...).
Now before mathematical operations currencies are converted to
the currency of the company currently selected.
Task - 2696759
closesodoo/odoo#83550
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Current behavior:
When 2 steps delivery and product packing is activated, and have 2 kit products that have common components.
If you create a sale order with those 2 kits and pack them in the first step of the delivery. And in the second delivery step mark the pack as done the done quantity in the package
are not correct.
Before this fix, all the products quantities from different kits were on the same stock move line and the other lines were ignored,
this result in lines with too much products and lines with no product. When validating this
incorrect transfer an unnecessary backorder was created and the sale order lines were not correctly marked as delivered.
Steps to reproduce:
- Activate 2 steps delivery and product packing.
- Create Kit A with Component A and Component B
- Create Kit B with Component A and Component B
- Create a SO with 1 Kit A and 1 Kit B
- Confirm the SO
- Go in the first step of the delivery and put everything in a pack
- Go in the second step of the delivery and set the pack as done
- Go in the package details : The first component A has 1 reserved and 2 done, same for component B
opw-2754106
closesodoo/odoo#90033
X-original-commit: b81f70babc774eff2e04d2f7854d75ec7273a757
Signed-off-by: Engels Robin (roen) <roen@odoo.com>
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Step to reproduce:
- Create an expense for an expense product which has a cost
Current behaviour:
- Expense's unit price is modifiable which shouldn't be
the case according to the help message of hr.expense.unit_amount
Behaviour after PR:
- Expense unit price is only modifiable is there is no unit_amount
(unit_amount = 0)
opw-2781040
closesodoo/odoo#90014
X-original-commit: 44b6d60de301651e52df4c41e32e38d23b0a154e
Signed-off-by: Kevin Baptiste <kba@odoo.com>
It was impossible to create a new gift card or pay with a gift card from the front end.
With this fix, it's possible to use a gift card code in the front end and to generate a new gift card. The gift card product is now available in the pos.
closesodoo/odoo#89999
X-original-commit: 2a9b6a763b11084735cf46ac9aa83b39098b958c
Signed-off-by: Masereel Pierre <pim@odoo.com>
Since those tests are related to the legacy mockServer, they have been
moved to the legacy folder.
task-2582313
closesodoo/odoo#89883
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
This PR prepares the ground for the one introducing the new env in discuss.
The signature of the notify function has changed a lot from the one in the old env.
In order to ease the transition and reduce the noise, the discuss models now
rely on the messaging's notify function.
task-2582313
closesodoo/odoo#89877
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Alexandre Kühn