Add back the 'sudo()' on batch mail unlinking.
Sudo is necessary to delete user notifications on auto-delete.
Which makes sense as the recipient would have an email for it anyway.
The sudo was there as far back as:
c5c369355d
Then transfered in this change:
036a739b62
And removed in the recent optimization here:
e38bfd25df1bb25e7e5695b536052d5a0c85c5c4
task-3225207
closesodoo/odoo#115956
X-original-commit: 93a28f17024511e30d3c70eb847c361ca87e0ffe
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Signed-off-by: Thiry Renaud (reth) <reth@odoo.com>
Steps to reproduce:
- take a project;
- change the visibility to allow sharing;
- click on "SHARE EDITABLE";
- share the project with a portal user;
- login as portal;
- try to open a project task.
Remark: the problem does not occur for all tasks.
Issue:
A traceback appears.
Cause:
Error occurs because: `return (token and record and consteq(record[token_field], token))`
compare two values with different type.
- `token` is equal to `'null'`
- `record[token_field]` is equal to `False`
In the code: `consteq = hmac_lib.compare_digest`
> `hmac.compare_digest(a, b)`
Return `a == b`.
This function uses an approach designed to prevent timing analysis
by avoiding content-based short circuiting behaviour, making it appropriate for cryptography.
a and b must both be of the same type:
either str (ASCII only, as e.g. returned by HMAC.hexdigest()), or a bytes-like object.
[source](https://docs.python.org/3/library/hmac.html#hmac.compare_digest)
The source of the problem is upstream to this comparison.
Indeed, we first test if we have a token.
As the value of the token is `'null'`, we pass the condition.
Solution:
It is necessary to have a token equal to `False` if the task has not token.
Therefore, whatever the value of the token (token value or `False`), we have to update the token.
opw-3217490
closesodoo/odoo#115947
X-original-commit: dd3a59fa28c5644be93cc2778e0c6854a4481d51
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
We created an index in the mixin, but the `init` was never called
as there was a missing `super` in `account_move_line`.
We also remove the index in `sales_project`, as it now is done in
the mixin (and we don't want different names for it).
closesodoo/odoo#115948
X-original-commit: 98a556031180cf72680b4f082a5c5d7b491742b7
Signed-off-by: William André (wan) <wan@odoo.com>
Steps to reproduce:
- open Discuss app with "General" as active thread
- open call settings in the inspector
- open a mailbox as active thread
Crash:
```
Cannot read showOnlyVideo of undefined
```
This happens because discuss has a single thread view
that is shared for any selected thread. However, the
call settings menu only makes sense for thread that
have call feature, which applies for only channels.
Mailboxes should not have any call settings menu.
closesodoo/odoo#115769
X-original-commit: 6e98ed068f01903383aca3348c193b56b46c6f95
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Steps to reproduce the bug:
Here are aliases for the used contacts:
- A: Azure Interior
- B: Gemini Furniture
- C: Gemini Furniture, Edwin Hansen
- D: (delivery address for Edwin Hansen)
1. Login on a runbot.
2. Set VAT of A and B to different values.
3. Open C, and create a delivery address: D
4. Check: VAT of D = VAT of B
5. Change the related company of C from B to A.
Bug:
The VAT of C = VAT of A, however VAT of D did not change.
When syncing the commercial fields of a partner, we also sync his childs.
PS: Due to function _compute_commercial_partner, the commercial partner is always updated for
all the childs.
So the condition child.commercial_partner_id != self.commercial_partner_id
is never satisfied in function _children_sync and the commercial fields were
never updated.
opw:3111493
closesodoo/odoo#115932
X-original-commit: df87448f2a39eead079cffea566cd760a8918542
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Raphael Collet <rco@odoo.com>
Co-authored-by: kmagusiak <>
If the method were called on several new questions from different
surveys at the same time (can it happen?),
allowed_triggering_question_ids would include questions from all
surveys for each of them.
A unit test of the method is also included.
Introduced in b1d18562.
Task-3226408
closesodoo/odoo#115930
X-original-commit: e506e8b049c61d5b772370792541b6875d5e5d72
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Signed-off-by: Florian Charlier (flch) <flch@odoo.com>
Steps to reproduce:
-Enable multistep routes for manufacturing
-create a MO for 50 products
-In internal transfers from Stock to Pre-production validate
part of the tansfer (20 units) and create a back order
for the remaining qty (30 units)
-create and validate another pertail transfer (3 units)with a back order
for the remaining quantity (27 units)
-create a return for the last validated transfers
Bug:
the default qty for the return is set to -20 where it should be 3
this commit[1] deducts the previous transfers from the returned amount
Fix:
only deduct returns from current transfer
opw-3104699
[1]:https://github.com/odoo/odoo/commit/7b08f0ae0a39e8f575b21e744de16264b6365704closesodoo/odoo#115929
X-original-commit: 0278a4a7ba5cdd7a722e5d576d22820a3ee64308
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Walid Hanniche (waha) <waha@odoo.com>
Steps to reproduce:
- Go to a website page (edit mode) > Duplicate the footer (or any
snippet with a Social Media block).
- Save > Traceback.
Starting from [1], a `dbSocialValues` variable was used to update the
"Social Media" DB links for the current website (on save).
These URL values are fetched from database (see: `_fetchSocialMedia()`)
to "compute the widget state" and when the snippet is dropped
(`onBuilt()`).
The specific case of "snippet clone" will lead to a situation where the
editor is created with an `dbSocialValues === undefined`, leading to
trigger the website `write` method with an empty update value...
Remark: The "save" works correctly after calling `_computeWidgetState()`
The goal of this commit is to simply prevent triggering the `write`
update on `clanForSave()` when `dbSocialValues` is `undefined`.
[1]: https://github.com/odoo/odoo/commit/f243bcbafb9291d94840795951c8fd51cab0cae1
opw-3204862
closesodoo/odoo#115912
X-original-commit: d3edef46426d1fefb31dae482f4c05dade4865a6
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Bug
===
When the from_filter of an outgoing mail server contains a domain
(e.g. company.com), and when the system parameter "mail.default.from"
is a full email address, with a different domain name
(e.g. notification@example.com) we concatenate both value which produce
an invalid email (e.g. notification@example.com@company.com).
Instead, we always give the priority to the from_filter, and fallback
on "noreply" for the local part when needed.
Task-3230917
closesodoo/odoo#115890
X-original-commit: bf02481de9932de2e0246ac36fcf59f37a89b511
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Steps to reproduce:
- Install Employees App Configuration
- Got to the Employees > Configuration > Activity Planning > Set the On/Offboarding Plans
- Create Test Employee With No Catch
- Click on Launch Plan action
- Check the Warning in Launch Plan Wizard
When employee's coach or manager empty then warning is appeared coach's/manager's
user is not set.In this commit we have shown in the warning that the coach/manager
is not set.
task-3193218
closesodoo/odoo#115889
X-original-commit: 421c238129676a83df63f00abadd539e82ced2eb
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Time Off officer would sometimes get an AccessError when requesting
leaves for many employees.
opw-3220920
closesodoo/odoo#115886
X-original-commit: f38a3d1ee398242f5dad6860bac95143256015b5
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Description:
The pop-up that shows suggestions when adding a tag on a task is
really slow (300~500ms per request on prod).
Cause:
`project.tag` has an override of `_name_search()`, which adds a
domain of the form
```python
['|', ('task_ids.project_id', '=', project_id),
('project_ids', 'in', project_id)]
```
which is expensive to compute.
Functional requirements:
- Suggest tags of the "project" first (those that are on tasks in the
same project), then all the rest.
- Tag's name should be sorted alphabetically per result set (tags on tasks of
project first, sorted alphabetically, then all other tags, sorted
alphabetically)
Solution:
Construct a custom query that makes use of CTE and `UNION ALL` to sort
only on a subsets of the tags to speed up. Also `UNION ALL` with a
`LIMIT` is lazy evaluated, so we gain on speed of all tags are comming
from tags on tasks in the current project.
Affected version:
- 16.0
- saas-16.1
- master
perf-3209468
closesodoo/odoo#115867
X-original-commit: 9e4ed8942800a7fc6e980e79b3e744fc35bd2a0d
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Signed-off-by: Olivier Dony (odo) <odo@odoo.com>
Signed-off-by: Piryns Victor (pivi) <pivi@odoo.com>
The translation alert banner is an old remaining edit/save feature that
is not relevant anymore with the new "always edit" and the "save when
leave" features.
closesodoo/odoo#115866
Task-id: 3232795
X-original-commit: dfd65d08ef3d76f9cd702927ee09dafe429d895a
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Add a stat button on customers views to easily retrieve all
the linked loyalty cards.
task-3050152
closesodoo/odoo#107375
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Before this commit, when over a man2one avatar, on a task project for
instance, we don't have any information about the user.
Now, a tooltip with the name is shown, note that this was already the
behavior in previous versions.
task-id = 3148168
closesodoo/odoo#115865
X-original-commit: c361cff78ddb2ad6b1f1c1d80c71a3ab154c6789
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
An error during the conversion of the html field to Owl caused the
embedded style of the Mail Debug tab to be lost because they were inside
a `<link>` element rather than in a `<style>` element.
closesodoo/odoo#115863
X-original-commit: 218909a339b2f3937e6d6f72fd0c6ff62aa305ce
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
while we are creating a new record of the mrp.workorder from the editable list
view (mrp_production_workorder_tree_editable_view), we are getting the singleton
error, as it is not taking any production record.
by applying this commit, it will resolve that singleton error
sentry - 3982694755
closesodoo/odoo#115862
X-original-commit: 91e7d36a48d58aea1d63999dd150b543983aeba1
Signed-off-by: Tiffany Chang <tic@odoo.com>
**TO REPRODUCE**
- open contacts
- open a contact with a picture (for ex, douglas fletcher)
- change the picture => new picture is displayed
- click on cloud icon to force save => new picture is displayed
- repeat: After repeating, the old picture will be displayed.
**SOLUTION**
Before this change, `getUrl` is bound to the rendering context
instead of the component and it will write to the rendering context.
This is introduced in this commit: https://github.com/odoo/owl/commit/df59ec49aefce2e0913fdc1792d42b9680fb28b6
The following excerpt from the mentioned commit explains:
"A side-effect of this change is that now the rendering context is no
longer the instance of the component by default, but is always an object
with the component in its prototype chain."
To make sure that `getUrl` is properly bound to the component,
we should call it from the `this` of the rendering context.
closesodoo/odoo#115857
Task-id: 3204546
X-original-commit: 05898cdaaf2dbf628665f3fa4c24769f7c424efe
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
They dates from < 2027 and are quite outdated. Favour the nl
translation instead.
n_BE is not on Transifex so it was not possible to correct bad
translations.
closesodoo/odoo#115845
X-original-commit: d04c8b7e484db8306d858c891a7a2b11885fdcd9
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
before this commit, from the function action_validate the function _original_records is called twice to assign the value to original_records variable.
after this commit, redundant function calling will be deleted.
closesodoo/odoo#115844
X-original-commit: 61e12347beef8666b47e51c3c4846cf1d5b2e17e
Signed-off-by: Kevin Baptiste <kba@odoo.com>
This commit deactivates the daterangepicker from reacting to the
`input` keyup events.
The handler for input keyup must only be the parent because
daterangepicker does not have access to both the start and end date
inputs.
As a consequence of not having access to both inputs, the
daterangepicker always sets the end date to the start date when a date
input is modified.
**Steps to reproduce:**
- Go to the event app and open a record
- Click on an input of the date range picker, and the picker opens
- Move the cursor in the input with the keyboard (right or left arrow)
- The picker loses the range
**Current behavior:**
The picker sets the end date to the start date whenever there is an
onKeyup event on the input.
**Expected behavior:**
The picker should not reset the end date when there is an onKeyup
event on the input.
closesodoo/odoo#115834
Ticket-id: 3198864
X-original-commit: 2a1857db4bee43ff266b4be279791c9b5c957085
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
**To reproduce:**
- go in any view with a search bar and favorites
- click on favorites and save current search or add to dashboard
- click with the mouse anywhere inside the default text and begin typing (e.g. in between existing character of the default filter name)
- the first letter will be at the spot you placed the mouse
- the second letter will be at the end
**Solution:**
Remove the autofocus.
Since the autofocus doesn't work and making it work might result to significant change
in the code, then it's better to just remove the attempt to autofocus. An issue is posted
in the owl repo to potentially provide better api for this kind of situation:
https://github.com/odoo/owl/issues/1381closesodoo/odoo#115833
Task-id: 3221734
X-original-commit: 71a7036a01486c6b4c99e506326d8b6a23b4de0c
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
In large database, to compute picking_count on orders and sessions, can take lot of time.
closesodoo/odoo#115469
X-original-commit: 59d3377e0631810d01e8637f56d52258f7cb87cc
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
New text_cover snippet added for the editor. Editors are now able to use
a cover composed of an image and some text on the side.
task-2691555
closesodoo/odoo#105650
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Steps to reproduce:
- install hr_referral to have the group "group_hr_recruitment_referral_user";
- with a user, check "Recruitment Interviewer" (to access the Recruitment application);
- with the same user, put the person as interviewer;
- checked/uncheck the "Display CV on application form" parameter on the user;
Issue:
Depending on whether the CV is displayed or not, the display of the buttons
differs in the chatter on the form view of a job application.
Cause:
The "hr_applicant_view_form_interviewer" view allows to hide the buttons
only when the chatter is contained in the form container.
Solution:
Add the class that allows to hide the information
with an override of the FormController component.
opw-3202343
closesodoo/odoo#115828
X-original-commit: 878289c30d3bc0c24d0f01b20dd6a640b181c3b0
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Signed-off-by: Lefebvre Thomas (thle) <thle@odoo.com>
before this commit, on contact us form, except
question input all the other required input
field has * (asterisk) after the field label.
after this commit, * will be added for the
question input label in the contact us form
closesodoo/odoo#115780
X-original-commit: 127f7f5cfbca103f6d50330aefe355fdaee808c8
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Following 873d6d9, the forecast would now redirect correctly to the
corresponding bom when a `product.product` was used.
The issue is that `bom_variant_ids` doesn't exist on `product.template`,
raising a traceback when the forecast was accessed through the product
themselves instead of their variants
closesodoo/odoo#115776
X-original-commit: 93f6bf8dc5319082579a2b4ecbc48b482b81cc9d
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Quentin Wolfs (quwo) <quwo@odoo.com>
after odoo #113888
when copy translations from one record to another, translations for
non-installed languages may raise error.
These translations may be
1. created before the langauge is deactivated
2. en_US which is always available for non falsy translated field value
this commit drops translations for uninstalled languages except 'en_US' when
copy and prevents raising error when users want to translate en_US when en_US is
not activated
closesodoo/odoo#115711
X-original-commit: 7bb1825ddbf2340882bef5ed1d9c877f78a2b815
Signed-off-by: Raphael Collet <rco@odoo.com>
Signed-off-by: Wang Chong (cwg) <cwg@odoo.com>
Existing constrains method had a bug in it, so let's take this
opportunity to replace it with the more efficient _sql_constraints
check.
closesodoo/odoo#115613Fixes: odoo/odoo#92799
X-original-commit: 0751a0e27b653d5c471120ba7f5dea37a3f30a28
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Tiffany Chang <tic@odoo.com>
Some users were updating their access rights to allow for direct
deletion of quants. This could lead to the infamous:
"It is not possible to unreserve more products of %s than you have in stock."
error since directly deleting a quant bypasses the flows of correctly
unreserving the amounts you are deleting. Therefore we now restrict
the unlinking to:
- when in sudo mode, since the automatic unlinking of zero quants always
occurs in sudo mode.
- stock manager when unlink access right = True. Normally we would allow
any user with the unlink access to do it, but since we are using the
existing `_apply_inventory` to ensure that reserved qtys of the
quant are correctly unreserved before the unlinking, only stock
managers will correctly do this unreservation.
It is expected that some custom code may break due to this restriction,
but if custom code is directly unlinking quants without a sudo or with a
non-stock manager, then the code in these cases probably need to be
fixed anyways since this will cause inconsistent db data and lead to
the error above.
X-original-commit: d1602e7ddefd59cafa1ce0a5522a53c987135858
Part-of: odoo/odoo#115613
Problem:
When point_of_sale and pos_mercury are both installed,
_gc_old_tokens will get called by the scheduled action "Base: Auto vacuum internal data"
and it will try to remove the Vantiv tokens from POS orders that are 6+ months old.
However, there are fields named ref_no and record_no that exists for pos.order;
so the AttributeError will get thrown.
Solution:
It is safe to remove the entire method since the Mercury API documentation
does not explicitly mandate the tokens be removed from old POS orders.
It was recommended by JOV to not modify the method to prevent the modification of
potentially 8 years old POS orders from client's databases.
Since the method is removed, the error will not be thrown when auto vacuum is called,
pos_mercury is installed, and POS orders are 6+ months older.
opw-3082616
closesodoo/odoo#115466
X-original-commit: 41a82c3326150fba6948667c9e455ae82088bb6d
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
Before this commit when in a multi-company environment an user
could assign a company to the sale order and use taxes related
to a different company for the sale order lines.
This is a functional error and also provoques that taxes are not
shown for some users when in a multi-company environment.
After this commit a ValidationError will be raised whenever the
company of the taxes in the sol and the so do not match.
opw - 3117352
closesodoo/odoo#115162
X-original-commit: 295c408568bb623f0b0ead3f18493ba339b87161
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Signed-off-by: Horacio Tellez Perez (hote) <hote@odoo.com>
Decimals were displayed in the quantity of products bought in the checkout page, which is not necessary.
task-3135936
closesodoo/odoo#110379
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
This commit fixes an issue with the tour service tests. Those
tests start the tour service, which in turn uses a MacroEngine.
The MacroEngine uses a MutationObserver. However, tours don't
have a cleanup function, because in the "real" world they are
started once and live forever. In the "test" world, services can
be started in each test, and thus we sometimes need to properly
clear they side-effect. In this particular case, we need to remove
the MutationObserver at the end of the tests.
Please enter the commit message for your changes. Lines starting
closesodoo/odoo#115841
Signed-off-by: Géry Debongnie <ged@odoo.com>
Python tests that run chrome headless wait for "test successful"
to be printed in the console to end the test with green status.
Tours and qunit suites logs that message when their work is done.
Commit [1] reworked the tour system and introduced some qunit
tests of the tour engine. However, running fake tours in qunit
tests produced the "test successful" message, which caused the end
of the suite. As a consequence, only a small part of the WebSuite
test suite was really executed.
This commit mocks console.log in those tour qunit tests, s.t. the
suite is now fully executed again.
[1] 3a798039d6
Part-of: odoo/odoo#115841
Partner's VAT identification number now is not missing when printing Foregin Invoices.
closesodoo/odoo#115595
Task: 947
X-original-commit: a0d684f6f93598024be4dcff82c6a7bc21277ce0
Signed-off-by: Josse Colpaert <jco@odoo.com>
before this commit, on printing employee badge the
download pdf file is named print badge - employee name
after this commit, the downloaded file name will be
changed to badge - employee name
closesodoo/odoo#115009
Signed-off-by: Kevin Baptiste <kba@odoo.com>
*: hr_attendance,hr_skills_slides,hr_timesheet,hr_work_entry
Don't show smartbuttons that lead to a view without records
task - 3134772
closesodoo/odoo#113105
Related: odoo/enterprise#37274
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Renaud Thiry