Bug
===
Since 6185f14807 we check the <mail.mail>
existence before marking the <mailing.trace> as opened, but since
57ae1b9b8b61f5f4719a8a81e9d0d21fab58cfda we remove the <mail.mail>
automatically when we send them.
The result is that this endpoint always raise a 500 error.
To be: the <mail.mail> existence shouldn't be checked in this endpoint
(the token is valid for the raw integer id).
Task-3234519
closesodoo/odoo#115842
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
The pictures of the employees were no longer showing in the kiosk mode
as it tried to read on `hr.employee` instead of the `hr.employee.public`
model.
closesodoo/odoo#115950
X-original-commit: 3794bfed7d474f470f6e401d697d8c36ad620820
Signed-off-by: Kevin Baptiste <kba@odoo.com>
task - 3147639
Adding precision digits and displaying the number without unnecessary trailing zeros using JS
closesodoo/odoo#115944
X-original-commit: b6c715cc5b39e28b4f40803a5f161845f5b407ab
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Steps to reproduce:
- Install Sales, Subscriptions or similar app.
- Go to Sales, and try to save a favorite filter without name.
- It can also be done in the order lines of the Subscriptions, if
we try to add a product and select "search more", inside the new
window try to add a favorite filter without name.
Issue:
We got a traceback that's not user friendly instead of the proper
warning message, this is because inside the `saveFavorite` method we
check if the description is empty, but we can't use `.length` because
when we don't fill any name, the description is `undefined`.
Solution:
Removing the `.length` check, and just checking if the description is
undefined or not.
Forward bot up to master.
opw-3200499
closesodoo/odoo#115204
X-original-commit: c0fe1408da48e43b3e7e55de8e1c1edb09c982d2
Signed-off-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Since 16.2, a condition was added to _get_available_qr_methods :
if self.env.company.country_id.code == 'CH':
rslt.append(('ch_qr', _("Swiss QR bill"), 10))
This condition was not allowing a multi-company call, and caused another issue.
Once the method was called to check on the eligible QR choices, the ORM would consider the current company to be the US default one.
Hence the condition would never be fulfilled and a stacktrace would appear :
Oh snap!
Wrong value for account.move.qr_code_method: 'ch_qr'
Reverted back to the unconditional behaviour, and will check this occurence with the framework team.
closesodoo/odoo#115952
X-original-commit: cdba8a062985bfbdcbe8d51aa9705e702b4dee61
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
Signed-off-by: Camille Spiritus (casp) <casp@odoo.com>
Add a selection field on the partner to choose the EDI format.
Merge the `cii_` and `ubl_` fields.
Add an `endpoint_value` and `eas_code` on the partner. These values are
read when generating the Bis 3 (or one of its derivatives) to fill the
`EndpointID` and the `@schemeID` in the xml.
We can remove `l10n_nl_oin` and `l10n_nl_kvk` which are only used by
electronic invoicing, and replace every usage of them by the new fields
`endpoint_value` and `eas_code` (since for NL partners, they should
necessarily represent the KVK or OIN number: eas code '0106' or '0190').
We can also remove the `l10n_lu_peppol_id` module which was only there
to allow an arbitrary number to be set on the `EndpointID` (for
instance, for public administration that doesn't have a vat number).
task-3232845
closesodoo/odoo#115934
X-original-commit: 8bef3ac696d387a5b5867bc239d628477278fb1b
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
Before this commit
- an editable list will not refocus a date field after a pick of a date
After this commit
- it will
closesodoo/odoo#115892
Taskid: 3184929
X-original-commit: 6e570bc446295a1d56bd9f171b1f1d328a98127f
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit
- since [1]
- a traceback occurs when opening a kanban group config menu if the view
has "records_draggable" and "groups_draggable" attributes set to false
Explanation
- the kanban renderer template do not set a group id on o_kanban_group
elements when the aforementioned attrs are false
- the kanban renderer then use a selector in order to give the kanban
groups config menus their container element (used for positioning the
dropdown).
- as there is no elements that matches that selector: a traceback occur
later in the usePosition hook positioning logic.
After this commit
- this is fixed by always setting ids on the group elements.
[1]: https://github.com/odoo/odoo/commit/65e43dd88115b46e2d8585cf6dd7af4a89693e68#diff-823da6a5974aafef6ec7d54b4d410ccd8dc54e1892aee57c3bb62ff8a0414826R21closesodoo/odoo#115891
Taskid: 3231051
X-original-commit: c8e9cf7f691dd208ffa947f110596beaf2f9ae94
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
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
std-odoo