Before this commit, the default assignee set to a rating in a task is
always empty because we check if the `project.task` has a `user_id`
field to give the partner of this user.
Since it is no longer the case because we can recently assign many users
to a task. That is, it is `user_ids` field and no longer `user_id`
field.
This commit overwrites `rating_get_rated_partner_id` method to set by
default the partner of the user contained in `user_ids` field if this
field contains at most one user. Otherwise, we set no partner. We choose
to not select the first user in the user_ids field because we cannot
consider it is the responsible of the task and not another one.
We cannot create a rating per user because the rating average will no
longer right because at the beginning of the task we could have 5 users
and after we could have more users or less users and so the number of
ratings for this task could be different each time we send a rating
review to the customer.
Part of task-2696911
closesodoo/odoo#81009
X-original-commit: 88e7d270bee962d6e4d40f6b62d25a9519abfcf2
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Signed-off-by: Xavier <xbo@odoo.com>
Before this PR, the delete button was completely invisible on image with white
background.
task-2709788
closesodoo/odoo#81000
X-original-commit: fd1e05cd131273504e7e6cd4f64f6ea63514b6b7
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
This is a bunch of fixes (65 corner cases) for the search on
company-dependent fields:
Without a default value:
- `char` fields:
- operators `not like`/`not ilike` don't return records with unset value
- `(..., '=', False)` doesn't return records with unset value
- `(..., '!=', '<string>')` doesn't return records with unset value
- `(..., 'in', [..., False])` doesn't return records with unset value
- `(..., 'not in', value)` without `False` inside `value` doesn't return records with unset value
- `date` and `datetime` fields:
- `(..., '!=', <Date/datetime>)` doesn't return records with unset value
- `(..., '=', False)` doesn't return records with unset value
- `many2one` fields:
- operators `not like`/`not ilike` don't return records with unset value
- `(..., 'in', [..., False])` doesn't return records with unset value
- `(..., 'not in', value)` without `False` inside `value` doesn't return records with unset value
- `boolean` fields:
- `(..., '=', False)` and `(..., '!=', True)` don't return records with unset and `False` values
- `integer`/`float` fields:
- `(..., '!=', <number>)` doesn't return records with unset value
With a truthy default value:
- `many2one` fields:
- operators `not like`/`not ilike` don't return records with unset value
- `(..., '=', False)` returns the record with the default value (which isn't `False`)
- `boolean` fields:
- `(..., '=', False)` doesn't return records with unset and `False` value
- `(..., '!=', False)` returns records with unset and `False` value
- `integer`/`float` fields:
- all `(..., operator, value)` which include value 0, return all records with unset value, even if the default value does not satisfy the domain
closesodoo/odoo#80994
X-original-commit: 3e3be652ece83420782070bdb13da2c3a4930046
Signed-off-by: Raphael Collet <rco@odoo.com>
Expected behavior :
Project manager can change task's project of any task including timesheets
Current behavior :
When Project manager with `Timesheets : See own timesheets` permission is updating task's project, an Access Error exception is raised `Only a Timesheets Approver or Manager is allowed to modify a validated entry.`
Steps to reproduce :
*Use demo data to make steps easier*
- Install Project and Timesheets
- Go to Project and select one
- Select any Task
- Edit it and try to change the Project
Reason :
When a user is a project administrator, he can still have basic permissions in Timesheets (`Timesheets : See own timesheets`), which prevents him from modifying the task's project if the task has some validated timesheet
OPW-2646233
closesodoo/odoo#80973
X-original-commit: 41907c6722da5b4777cc3b8065f4057b0a5f0801
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Simon Goffin <sig@odoo.com>
Signed-off-by: Claude Thibault (thcl) <thcl@odoo.com>
This commit adds an index on picking_type_id for models stock.picking
and mrp.production.
Filtering on picking_type_id is often done via the Inventory Overview.
This should speed up the list render in case of many object.
Task : 2648449
closesodoo/odoo#80434
Related: odoo/upgrade#3068
Related: odoo/enterprise#22535
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
This commit rename product_uom_qty into reserved_uom_qty and product_qty
into reserved_qty on stock move line to stop mistake them with the stock
move quantities fields.
Task: 2648449
Part-of: odoo/odoo#80434
The stock convention on location name is always to name the destination
`location_dest_id`. It was not the
case on the stock rule model
Task: 2648449
Part-of: odoo/odoo#80434
Steps :
- Install Sales & Timesheets
- Timesheets > Settings > Time Encoding :
- Min duration : 60 min
- Rounding up : 15 min
- Create a Project P
- Create a Product S :
- Product Type : Service
- Service Invoicing Policy : Timesheets on tasks
- Service Tracking : Create a task in an existing project
- Project : P
- Create a Sales Order SO and add S
- SO > 1 Tasks (smart button) as T > Timesheets (tab) > Add a line :
- Employee : Mitchell Admin
- Duration : 0
- Timesheets > Start :
- Time : 1:09
- Project : P
- Task : SO:S
- T > Timesheets (tab) : Note Time = 1:15 (Min duration + Roundup)
- T > Start and Stop
- Confirm Time Spent Wizard : Note Duration = 1:00 (Min Duration)
- Duration : 1:09
- Save and T > Timesheets (tab) : Note Time = 1:09
Issue:
- Unconsistent behaviors :
The time is rounded when using Timesheets' timer and from Task's timer to Confirm Time Spent Wizard
but it is not rounded when confirming the Wizard.
Fix:
- Round it in when confirming the wizard too.
opw-2672249
closesodoo/odoo#80977
X-original-commit: 3e78c0dbf4adb98e98affefe7da526f73aa529e8
Related: odoo/enterprise#22762
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Change the github username of Danny de Jong from personnal to
corporate account
closesodoo/odoo#78613
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
After this commit, the js_transpiler will support exported hoisting
function. So it will be possible to define a hoisting function and
exported in an @odoo-module.
Example of exported hoisting function which wasn't supported before
this commit:
```
hoisted();
export function hoisted() {
...
};
```
closesodoo/odoo#80965
X-original-commit: 40ef9f7aeac8048cce8f002c84181abc64bcbe87
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
``channel_id`` field is used to compute ``render_model`` of invite wizard
used to filter templates to choose. It is a fake trigger ensuring the
render model field is computed, and then used in template domain
(see ``mail.composer.mixin`` and ``mail.render.mixin``).
As channel_id field is not available in view the domain computation for
template_id is not updated. No template is therefore available in template
m2o field in invite wizard. This commit fixes that by adding the channel_id
field in the view, meaning render_model is now computed.
Task-2709581
closesodoo/odoo#80947
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
When scheduling a mass sms with a template, do not force a void body in
context as default value. Indeed it takes precedence on computation of body
based on template and may lead to a void value being given to create.
Task-2709581
Part-of: odoo/odoo#80947
As body and composition_mode are required, an override of create has been
added to ensure they have a value. Indeed compute are computed after creation
which leads to required not being satisfied.
Now that precompute[1] are available this code can be safely replaced.
Task-2709581
[1] https://github.com/odoo/odoo/commit/d04a5b5c8c7dc13e4e911a29d1944e90587e2883
Part-of: odoo/odoo#80947
An override of invite wizard exists to give a value to body and subject.
However as those are computed field (not required) this is not necessary.
Task-2709581
Part-of: odoo/odoo#80947
Add a "clear qty" button to revert the change by "set qty" button in
(batch) picking.
On the move, Whenever the qty_done != reserved, we consider it a
manual change from the user. "set/clear qty" buttons won't change the
line with manual change.
Show "set qty" button when there are moves with 0 qty_done and non-zero
reserved. Show "clear qty" button when we don't show "set qty" button
and there are moves with qty done == reserved but the number is not 0.
Task-2659233
closesodoo/odoo#78737
Signed-off-by: Steve Van Essche <svs@odoo.com>
When refusing a leave, we are deleting the associated overtime if any so it can be
used again by the employee. However, we need HR Officer rights to access overtime
field. The sudo() should be used before we try to read the field to avoid errors
in case the manager of the employee does not have HR rights.
closesodoo/odoo#80945
X-original-commit: 1ffbcf9787e5efe00d49f18baba0144f631ada51
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Signed-off-by: Alex Thuyls (alt) <alt@odoo.com>
The query below
https://github.com/odoo/odoo/blob/81497125d8100c6bdd2dc30434232a88a419a3e3/addons/hr_work_entry/models/hr_work_entry.py#L92-L115
has bad performance without the bespoken indices on `date_start` and
`date_stop`. We can speed it up more with an index on `employee_id`.
This is not enough for DBs with many work entries (500K+), specially
during upgrades.
Here we optimize the query to take into account only the work entries
being modified.
This issue was observed during an upgrade saas~12.3->13.0 where the
payslip recomputation never ends due to the increased amount of hr work
entries created. Note how the first 1K payslips are processed in 1 hour
(~16 payslips per minute), while the latest 3 (before the upgrade
was killed) took 1 min.
```
2021-11-02 21:05:44,403 2229 INFO db_42897 odoo.modules.migration: module hr_payroll: Running migration [$saas~12.4.1.0] end-compute-amount
2021-11-02 21:06:44,577 2229 INFO db_42897 odoo.upgrade: [1.61%] 1120/69635 payslip processed in 0:01:00.036716 (total estimated time: 1:02:12.729213)
2021-11-02 21:07:44,602 2229 INFO db_42897 odoo.upgrade: [2.66%] 1853/69635 payslip processed in 0:02:00.062972 (total estimated time: 1:15:11.918540)
...
2021-11-05 09:59:46,565 2229 INFO db_42897 odoo.upgrade: [47.95%] 33390/69635 payslip processed in 2 days, 12:54:02.025479 (total estimated time: 5 days, 7:00:30.261882)
2021-11-05 10:01:04,990 2229 INFO db_42897 odoo.upgrade: [47.95%] 33393/69635 payslip processed in 2 days, 12:55:20.450549 (total estimated time: 5 days, 7:02:32.725840)
```
opw-2672031
closesodoo/odoo#80898
X-original-commit: 47b7a760c5788782c65136e529c8283fe5f0cce2
Signed-off-by: Nicolas Seinlet (nse) <nse@odoo.com>
How to reproduce :
-Create accrual plan with no level
Current Behaviour :
Traceback because num2words does not support all of odoo language
For supported language, the numbers showed are not ordinal
Behaviour After PR:
Show Basic numbers in every case
opw-2697987
closesodoo/odoo#80849
X-original-commit: 0cf2ade4e6e959170906b4b0143e07909980b1d7
Signed-off-by: Kevin Baptiste <kba@odoo.com>
How to reproduce :
-Set language to portugese
-Try to access accrual plan in time off
Current Behaviour :
Traceback because num2words does not support all of odoo language
For supported language, the numbers showed are not ordinal
Behaviour After PR:
Show Basic numbers in every case
opw-2697987
X-original-commit: afa531b6c8a06f553784e90df7641024d9bb142c
Part-of: odoo/odoo#80849
Prior to this commit, when the user was hovering on colors in the
web editor, the cursor would stay with its default appearance.
Some users weren't able to tell if this was an interactive
element or not.
With this commit, we change the cursor to the pointer cursor when a user
is hovering the element so that they have a visual element indicating
that it's interactive.
task-2687469
closesodoo/odoo#80933
X-original-commit: 40fec954a369c94576b5ed88eade5d3ff120ca4a
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Before this commit, the account reset would fail with the following traceback:
```py
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "/home/odoo/src/odoo/15.0/odoo/http.py", line 643, in _handle_exception
return super(JsonRequest, self)._handle_exception(exception)
File "/home/odoo/src/odoo/15.0/odoo/http.py", line 301, in _handle_exception
raise exception.with_traceback(None) from new_cause
AttributeError: 'res.users' object has no attribute '_set_auth_tokens'
```
This commit allows to use the wizard.
opw-2705169
closesodoo/odoo#80918
X-original-commit: 9f2aa5c87a9809899cba872e6a0428f86c687b9a
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Signed-off-by: Arnaud Joset <arj@odoo.com>
Within portal, subscriptions/sales orders presented in list view have their URL
containing the access_token as a GET param. However, when clicking on a
subscription and using the pager to navigate between records, the access_token
is not present in the URL. In order to keep consistency between the links and
views, this PR adds the access_token as a GET param in the pager as well.
task-2512070
closesodoo/odoo#76673
Related: odoo/upgrade#2752
Related: odoo/enterprise#20357
Signed-off-by: Arnaud Joset <arj@odoo.com>
Before this commit, unlink-all would sometimes fail to unlink more than one
record.
This seems to be the case in particular for x2many relations with isCausal true.
Indeed, the delete from isCausal is itself calling unlink-all on the inverse
relation (the same record that was being unlinked-all in the first place) which
would pre-emptively remove it from the same Set that was used during the initial
iteration.
The solution is to make a copy of the Set before iterating it to ensure all
records that were planned to be removed are actually removed.
Candidate fix for task-2410314 and definitely necessary for data integrity in
general.
closesodoo/odoo#80913
X-original-commit: 0077b93fea6f8c39ee535f19426c3f95a0e97e9f
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Whenever opening the codeview from mass_mailing and then directly
saving the document did not work.
Task-2704335
closesodoo/odoo#80899
X-original-commit: d9fe1e22b4f645f1732283ab558de170716a7434
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
The call to `addRowBelow` was not updated to the new API.
Task-2698729
closesodoo/odoo#80896
X-original-commit: f7fb967cd8ada702e298d097ea107fda802fa6a4
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
VAT check error message says 'record_label' instead of real partner name
Steps to reproduce:
1. Install the Contacts app and the VAT Number Validation module
2. Go to the Contacts app
3. Create a contact and define his country and an invalid VAT number
4. Save
Solution:
Modify the error message with the correct placeholder
OPW-2692320
closesodoo/odoo#80660
X-original-commit: 0aff6adc03c2d7cd6b3d29848e895cd258e42348
Signed-off-by: Guillaume Merlin (megu) <megu@odoo.com>
In preparation for using OWL v2 in discuss code.
(`shouldUpdateBasedOnProps` will be removed)
Task-2695743
closesodoo/odoo#80615
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Using <a> with 'download' attribute to download the attachment.
Prevent calling .navigate() interrupting the current call.
task-2692597
closesodoo/odoo#80903
X-original-commit: 97fa88c2e8407972c83c93d4d2198633a5560ecc
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
In preparation for using OWL v2 in discuss code.
(shouldUpdateBasedOnProps will be removed)
Task-2695743
closesodoo/odoo#80616
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
The website is now referenced to Odoo's website, with the most updated documentation.
closesodoo/odoo#80514
X-original-commit: 98025e4919e8a907419794b03d0386648c31343f
Signed-off-by: Josse Colpaert <jco@odoo.com>
When using AVCO and subcontracting without any additional cost, the
valuation of the finished product is incorrect
To reproduce the issue:
1. Create a Product Category PC:
- Costing Method: AVCO
2. Create two products P_compo and P_finished:
- Both:
- Type: Storable
- Category: PC
- P_compo:
- Cost: 10
- Routes: Resupply Subcontractor
3. Update P_compo's quantity: 2
4. Create a Bill of Materials BO:
- Product: P_finished
- Type: Subcontracting
- Subcontractor: a partner P
- Component: 1 x P_compo
5. In Inventory, create a planned Receipt R:
- From: P
- Operations: 1 x P_finished
6. Mark R as To Do
7. Process the delivery of P_compo
8. Validate R
9. Repeat steps 5-8
10. Open the Inventory Valuation
Error: There are two valuation lines for P_finished: one line has a
value of $10, which is correct (this is the cost of the component).
However, the value of the second line is $20, it should be $10 too.
Here are a part of the values used to generate the related MO:
https://github.com/odoo/odoo/blob/2d12fb8fb94c0f2acade7222cfedbec34114a8e9/addons/mrp_subcontracting_account/models/stock_picking.py#L21-L25
In the above case, an extra cost is defined on the MO and is based on
the unit price of the subcontracted SM. However, `_get_price_unit` will
return an incorrect value:
https://github.com/odoo/odoo/blob/251be6b943ea8c3f274bb0863d0af3f7c6b8d10d/addons/stock_account/models/stock_move.py#L39
After step 8, the standard price of P_finished is $10. Also, in the
above case, there isn't any subcontracting cost, so there isn't any unit
price defined on the SM. Therefore, `_get_price_unit` returns the
standard price of P_finished ($10). As a result, when computing the
value of the finished stock move:
https://github.com/odoo/odoo/blob/4fc2ec31861d4602357f130066ec3507b96d8dc8/addons/mrp_account/models/mrp_production.py#L39-L42
It uses the extra cost of the MO + the component cost. This explains
where the $20 come from.
OPW-2641339
closesodoo/odoo#80889
X-original-commit: 0567536f8b66c71f6860041926542f88026793b1
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
By searching on account.move.line parent_state instead
of move_id.state, we avoid a join in many circumstances
and allow the database to benefit on an index on
company_id+parent_state to optimize several
queries, such as the default filter on the Journal Items
menu which shows posted items.
closesodoo/odoo#80815
X-original-commit: c2a72c268e6a28d7448b6dbf96fed4e36d24b3fe
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Current behaviour :
In POS, pricelist are based on the day and not the current moment so if a pricelist item start on day X at 01:00, it's not taken into account at day X at 02:00.
Behaviour after PR:
Pricelist are taken into account based on full time.
opw-2691883
related to b3149d84a0closesodoo/odoo#80779
X-original-commit: c0c968063bf791a13117434e8cdd0e3c8120eaa3
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Masereel Pierre <pim@odoo.com>
Even though `uom_id` is required by product.template, it's still
possible for users to delete it within the product view and trigger a
compute that depends on it before saving.
Steps to reproduce:
1 - install sale_timesheet + activate UoM
2 - open any product form, click on uom_id and delete the uom
Expected result: No UoM + user cannot save
Actual result: traceback + user can appear to save (but uom defaults
back to last selected UoM
While this isn't a blocking problem since users won't be able to save
no UoM being selected, we would still rather avoid the traceback so we
default to no service_upsell_threshold_ratio message in this case and
properly prevent the saving.
Task: 2689438
Also fully fixes: odoo/odoo#78693closesodoo/odoo#80868
X-original-commit: f60786a7490cc09a31fe0dd0d74cf97368184bd9
Signed-off-by: Steve Van Essche <svs@odoo.com>
Signed-off-by: Tiffany Chang <tic@odoo.com>
In debug mode, the FieldDomain displays a textarea to allow the
manual edition of complex domains. However, when those domains
contain dynamic content (e.g. datetime stuff), the evaluated
version of that content was displayed, which isn't what we want.
We want to see the raw version of the domain as written in db,
and be able to edit it. This commit fixes that issue. Moreover,
we also ensure to keep whitespaces and new lines, which can be
useful for large domains.
closesodoo/odoo#80866
X-original-commit: 15301a1ddaf00e51688d8134b7cb19baf386577c
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, sometimes component do not properly
render changes in the models. Although the modeling is correct,
there is a problem in the component not re-rendering itself.
The shouldUpdateBasedOnProps component hook did not consider
update attempts that could be canceled. This commit adds this
consideration, so that it ensures component is eventually
rendered correctly
Task-2410314
Task-2705078
closesodoo/odoo#80877
X-original-commit: 12c77f52c5a16c95e57de31587d67eda4d582bde
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Before this commit, changing a filter in the dynamic snippet could
cause errors because the option wasn't awaiting an asynchronous
call.
This commit fixes that by using the same mechanism used in the
s_website_form snippet, relegating the rerenderXML call to updateUI
task-2654924
closesodoo/odoo#80867
X-original-commit: 8a4391a7d6e6988da7b62f6caa91e49c831da774
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Kartik Chavda