Before this commit: When you sync the Odoo calendar with Google for the
first time, it will resync all of the created recurrence events with
Google after fetching all of the Google events. The problem is that it
chooses the 'accepted' state by default for the current user's state.
If you were invited to events and you hadn't accepted that, it would
update your status and send an email per event for all attendees.
Steps to reproduce the issue:
1. Create two new google accounts ( you'll bombard with emails)
2. Create a recurrent event without ending with the first account and
choose the second account as a guest.(don't accept)
3. Sync second account with Odoo
=> It'll send about 700 emails
The solution is to prevent synced recurrence events from syncing and.
opw-2691146
closesodoo/odoo#89633
X-original-commit: 084aeb239e85a4e3abb3e233af68c6838dfbb3d7
Signed-off-by: Arnaud Joset <arj@odoo.com>
Before this commit, the rating feature is visible in some
`project.task` views even if the customer rating field is
disabled on the project related.
Unexpected behavior when the feature is disabled on the project:
- the rating column field is visible in project.task list view
- the rating icon is visible in project.task kanban and form view
This commit fixes the rating icon and rating field visibility by adding
a condition to check if the feature is enabled on the project.
task-2762166
closesodoo/odoo#86103
Related: odoo/enterprise#25129
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Steps :
Create a Project (P) :
> Analytic Account : AA
Create a Product (A) :
> Product Type : Service
> Create on Order : Task
> Project : P
Create a Product (B) :
> Product Type : Consumable
Create and confirm a Quotation :
> SOL > Product : A
Go to the Task consequently created.
Add B to the products.
Go back to the Quotation and create invoice.
Issue :
See Invoice Lines:
> INVL(A)'s analytic account is AA.
> INVL(B)'s is not set.
Cause :
To set the aa on the SOL, we use
SOL.task_id._get_task_analytic_account_id(),
which returns the task's aa or its project's.
Yet we do that only if the task has an aa.
Fix :
Call the method. If it returns something, set it on SOL.
opw-2817811
closesodoo/odoo#89660
X-original-commit: 9e7bf074c346c35325e14e14422f2d860d0db74e
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Signed-off-by: Xavier <xbo@odoo.com>
Prior this commit, the MessageActionList was behind and partly hidden by
the Composer when we edit small messages.
After this commit, the MessageActionList is in front of the Composer.
task-2819763
closesodoo/odoo#89610
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
There are cases that seems to reset the editor content but shouldn't.
This commit:
- provide a dialog to allow the user to save his content before being
lost forever
- reset only if the record content has changed
task-2810115
closesodoo/odoo#89625
X-original-commit: e812e923ffe040e734e4d913eceaae396adf6c3d
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
In hr_holidays, when creating a time off, set the default time off type based
on the sequence of the time off type
task-2832674
closesodoo/odoo#89623
Signed-off-by: Kevin Baptiste <kba@odoo.com>
- Install project
- Ceate an internal user without any access rights
- Go to `/my`
A 500 error is raised because of an AccessError.
When the user has no access rights to any of the mentioned applications,
the `search` call returns an AccessError.
We prevent the access error and return 0 as a fallback.
closesodoo/odoo#89648
X-original-commit: 53334071d3073e0404bb981e1309d351f5e3ab43
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Reproduction:
1. Install Survey, create a survey with one matrix type question (3 rows
and 3 options for example)
2. Click share, copy the survey link in an incognito tab, and finish it
twice
3. Go to the backend, click “See results”, click “Data” tab
4. The ratio is calculated based on the total number of received options
(#options * #answers)
Reason: the ratio for matrix questions should be computed row by row.
This behavior was correct in V13, but lost in V14 after model rewriting
Fix: Use the number of answers to compute the ratio instead of the
number of options made
opw-2809433
closesodoo/odoo#89434
X-original-commit: da7e242187f304c64ca945ea3d6e9e1d48a9d393
Signed-off-by: Anh Thao PHAM <pta@odoo.com>
Signed-off-by: Liu Jinjiu (jili) <jili@odoo.com>
This commit adds the possibility to add the hr.leave and hr.leave.type models
taskID 2823582
closesodoo/odoo#89017
Signed-off-by: Kevin Baptiste <kba@odoo.com>
The commit brings various features to the payroll app :
- visual improvements
- choice to recreate the original after a work schedule change
- after a new contract is sign, its differences with the last one is displayed in the chatter
TaskID : 2762038 [Payroll] Misc improvements
closesodoo/odoo#85581
Related: odoo/enterprise#24873
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Issues found using a mobile device only.
On the planning module, go to the gantt view and select a shift with a long name.
The title of the modal that appears will be displayed in three separate lines, and
not all the information is visible. This was fixed globally to avoid having the same
issues in other modules as well.
On the industry fsm module, the worksheet info when signing a document
is not correctly structured.
task-2755200
closesodoo/odoo#89630
X-original-commit: 297eca04fb85ccf95cd0daab9d7062bf46cd6f04
Related: odoo/enterprise#26588
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
- Setup at least 2 bank accounts [ACC1] and [ACC2]
- Setup a Journal [BNK1] with [ACC1]
- Setup a second journal [BNK2] with [ACC2]
- Create an Internal Outgoing Transfer from [BNK1]
setting as destination journal [BNK2]
- Save and confirm
partner_bank_id will be selected from:
- the Journal, for inbound payments, so [ACC1]
- one, possibly the first, bank account of the company for
outbound payment, so [ACC1] or [ACC2]
This is wrong as [ACC2] should be used because defined on [BNK2]
which is the destination journal
opw-2794081
closesodoo/odoo#89599
X-original-commit: 4624d1ebdedf84ed3031f7af1be827de54f72566
Signed-off-by: William André (wan) <wan@odoo.com>
A change introduced in https://github.com/odoo/odoo/pull/84644 removed the 'token' variable from a call to
the `portal.message_thread` template, which created a bug where a portal user
trying to submit a comment to a task would encounter an "Access Denied" error.
This commit reverts that change.
Task-2832688
closesodoo/odoo#89643
X-original-commit: 29c9eb4d65280dc5b23c89207dd7c2caa6ced596
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Signed-off-by: Xavier <xbo@odoo.com>
Currently, the timezone offset is taken from the date with reverse
timezone offset applied.
So if there is a change of timezone offset between the wrong date and
the local date, we apply the wrong timezone.
Example:
- be in "Australia/Sydney" timezone
- select date in datetime field 2021-04-03 16:12:34 (at UTC+11)
- save => time becomes 17:12:34
- change time to 17:12:35 and save => time becomes 18:12:35
- change time to 18:12:36 and save => time becomes 19:12:36
- ...
- this issue is happening until 01:59:59 of the following day
Fix:
When we are selecting "2021-04-03 16:01:23" we will get the timezone
offset from the date "Sun Apr 04 2021 02:01:23 GMT+1000" (at UTC+10)
but the DST change was at "2021-04-04 03:00:00 (UTC+11)" with time
becoming "2021-04-04 02:00:00 (UTC+10)".
With this changeset, we are getting the timezone from the local time,
not from local time with reverse timezone offset applied.
opw-2735369
closesodoo/odoo#89619
X-original-commit: 84eb850af614887f7040bffa71cbb7fd239ba857
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
When showing the discount the to the public, the down payment and gift card products were taken into account in the discount computation shown in the receipt.
This also fix a mistake made in fc546e0481ae0159e67791240833bc1e38a4440f where it was implemented in the wrong place and returning a wrong value in a reduce callback.
closesodoo/odoo#89603
X-original-commit: 597ea7aa3f28ad82e602e1ba5679bb49d2973b78
Signed-off-by: Masereel Pierre <pim@odoo.com>
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
Steps :
Install project and activate Timesheets.
Go to a task and add a timesheet with 30', then click elsewhere.
Issue :
The hours spent adapts, rounding to integer.
Cause :
The digits are not specified.
Fix :
Specify them.
opw-2822018
closesodoo/odoo#89596
X-original-commit: 307f403156f20e56fe91cad5397b3db1b3ae3f99
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Signed-off-by: Onockx Audric (auon) <auon@odoo.com>
Forward-port of PR odoo/odoo#86643.
Add a unittest for multi_step route on Ship Later warehouse to
ensure that the fix 5959d77f344 is not unintentionally reverted.
closesodoo/odoo#89595
X-original-commit: d5fb77e9d4716dd509e2e98ff39f7e1cb91ddaca
Signed-off-by: Masereel Pierre <pim@odoo.com>
Current behavior:
In PoS when you access payment screen with product tracked by SN
and if some of the SN are not set you have no warning.
Steps to reproduce:
- Create product tracked by SN
- Sell it in a PoS
- Don't set the SN
- Click on payment button
- No warning is displayed
Solution:
Add a warning popup to inform the user that he is going
to make a payment with missing SN
opw-2818511
closesodoo/odoo#89565
X-original-commit: c1a4b89e93207d7e18c5f7491db110f0d28ae836
Signed-off-by: Masereel Pierre <pim@odoo.com>
Steps to reproduce:
- Select any two storable product that has invoicing policy set on 'Delivery'
- Create a sales order lines with these two products and make sure that one of the lines should have a quantity set to 0
- Add shipping
Issue:
- The Invoice Status has changed to 'To Invoice'
Solution:
Add en extra filter to consider only lines that have not been invoiced.
opw-2750861
closesodoo/odoo#89548
X-original-commit: bfeb5f6317786edfd0fa464fe5798c7f7bc65ac9
Signed-off-by: yosa-odoo <yosa@odoo.com>
The problem is generally due to the use of `var`, this one
https://github.com/odoo-dev/odoo/blob/58a046d2146e884d467cde827f89fa603ed98a3b/addons/web/static/src/js/views/basic/basic_model.js#L1780 followed by an asynchronous call to a function using it
We can therefore summarize the part of the `_applyOnChange` function
that interests us by
```js
for () {
if (field. type === 'one2many' || field. type === 'many2many') {
var list;
...
//using list
...
promiseFunction(list).then(function(){
//using list
})
}
}
```
In the case where we have two one2many which follow each other,
this scenario occurs:
- `list` is initially the first o2m
- the `promiseFunction` is called with `list` (first o2m)
- before the promise is resolved the loop continues
- `list` is `Promise.then()` the second o2m
- the first call to `promiseFunction` with `list` (first o2m) is done
- we enter in `Promise.then()`
- `list` is currently worth the value of the second o2m because
`list` is a `var`
- the second call to `promiseFunction` with `list` is finished
- we enter the `Promise.then()`
- `list` is currently worth the value of the second o2m because
`list` is a `var`
Result: `Promise.then()` is called twice with the first o2m and never
with the second
We can see what happened with this code example:
```js
const array = ["a", "b"];
const asyncRead = async(value) => {
console.log("async function arg", value)
setTimeout(()=>{
return Promise. resolve(value);
}, 100)
}
const forFunction = () => {
for (let i = 0; i < array.length; i++){
var list = array[i];
asyncRead(list).then(function (){
console.log("then async function arg", list)
})
}
}
forFunction()
/*
async function arg a
async function arg b
then async function arg b
then async function arg b
*/
```
While if:
We use `let`
by replacing `var list = array[i];` with `let list = array[i];`
OR
We force the use of `Promise.resolve()` argument
by replacing `.then(function (){}` with `.then(function (list){}`
We will get:
```js
/*
async function arg a
async function arg b
then async function arg a
then async function arg b
*/
```
opw-2694855
closesodoo/odoo#89160
X-original-commit: 99cb2f52e109ccf94ac8bd735cd776e84ef04260
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
- The starred field was renamed as priority.
- The assigned date is now set back to False when the user is unassigned from the task
- An action helper was added to the collaborators view
- The year mode was added to the calendar view of tasks
task-2802506
closesodoo/odoo#87139
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Have an action with target="new" and a list or kanban view as
first view. This view is displayed in a dialog. Click on a record.
Before this commit, the action service tried to switch view, but
in the action displayed in the background (since we cannot switch
view inside the dialog anyway). As a consequence, if the action in
the background was a window action with a form view, we opened that
form view, which is absolutely not what we want (different action,
different model...). And if the action in the background was a client
action, it crashed, because we can't switch view in those actions.
With this commit, we simply ignore calls to switchView when there's
a dialog opened.
opw 2791201 and 2793678
closesodoo/odoo#89539
X-original-commit: 81f8de82daa47a31e4a33478aeb537f2c9c1519c
Signed-off-by: Géry Debongnie <ged@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Have an action with target="new" and a list or kanban view as
first view. It is displayed in a dialog, and a there is a control
panel. Before this commit, the breadcrumbs in that control panel
contained the complete history of controllers displayed in
background, which isn't what we want. For instance, clicking on
an element of the breadcrumbs crashed. After this commit, there's
only one element in the breadcrumbs, which corresponds to the
controller displayed in the dialog.
Spotted when investigating on opw 2791201 and 2793678
X-original-commit: 9838bb3a35e8b205fe30ceb5f86dcd81d536d1d0
Part-of: odoo/odoo#89539
Current behavior:
When using 2 steps delivery and selling a kit product, not all
moves had bom_line_id set. So if you go in the transfers you
couldn't always see the "Kit" column in the operations.
Steps to reproduce:
- Activate 2 steps delivery
- Create a Kit with 2 products
- Create a quotation with kit and confirm it
- Go in the delivery
- In WH/Pick you can't see Kit column
- In WH/Out you can see the Kit column
opw-2796974
closesodoo/odoo#89371
X-original-commit: 88c3c3f49393af08e4070c0d2f5cccbec9096c1f
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Engels Robin (roen) <roen@odoo.com>
Impacted versions: 15.0
Steps to reproduce (starting from ENTERPRISE 15.2):
- enable Work Orders
- create new BoM for a new product
- add 1 operation w/ 1 step (e.g. Instructions)
- add 1 component to BoM with operation_id (Consumed in Operation) = the operation
- Create and confirm a MO with new BoM + 2 Quantity to Produce
- Produce 1 product via the tablet view flow (i.e. complete instruction step + Validate 1 component in "Register Consumed Materials" step + Mark As Done)
Current behaviour:
Backorder is correctly created, but its workorder is missing the "Register Consumed Materials" step
Expected behaviour:
Step is correctly created
Note: same issue occurs with Byproducts having an operation_id (i.e. "Produced in Operation")
Issue is due to when _split_productions() first creates the backorders, they are created without move_raw_ids and move_finished_ids (see: _get_backorder_mo_vals()). When the backorders are created, they auto-create and auto-confirm their workorders. Since a quality point (e.g. operation step) exists for the workorder, the initial _action_confirm will _create_checks() for the quality point, but the "Register Consumed Materials" steps are created by the operation_id values in the move_raw_ids and move_finished_ids which haven't been set yet. This makes it so when the second _action_confirm() is called on the workorders (i.e. after their moves have been set) at the end of _split_productions(), the _create_checks() will be skipped because it assumes all the quality points have been created since one already exists.
Task: 2800975
Community PR: https://github.com/odoo/odoo/pull/87681
Enterprise PR: https://github.com/odoo/enterprise/pull/26437closesodoo/odoo#89486
X-original-commit: 67524eb948b7e122f33abf344b28b59bd81eb88d
Related: odoo/enterprise#26534
Signed-off-by: Tiffany Chang <tic@odoo.com>
The autoplay option for youtube videos in a .media_iframe_video snippet
does not currently work on mobile devices. This happens because the
autoplay param in the url is only considered for desktop devices.
Mobile autoplay can be forced by using the youtube js api, in the same
way as it is already done for background videos. Therefore, the common
code is extracted into a mixin, extended by both widgets.
opw-2607308
closesodoo/odoo#89439
X-original-commit: 83972aa28957414d53c69bb41ce36646891a829e
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: qsm-odoo <qsm@odoo.com>
When using a template with inline placeholders in the body, the Test
button will replace the placeholders, but they will remain in the final
body when the mass mailing is sent for real.
This commit fixes this issue by using the correct rendering engine for
the Test button too.
OPW-2819032
OPW-2828461
closesodoo/odoo#89346
X-original-commit: b0dcd2fa35d949dd722f1bc70401ceeb7f5d8231
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Paul Morelle <pmo@odoo.com>
Make SII menu more readable and user-friendly
Set l10n_es_edi_test_env = True by default
Task-2809043
closesodoo/odoo#89480
X-original-commit: d96c9a28badfdee3a56c29ce69822c7387f12872
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Laurent Smet <las@odoo.com>
When saving a description the one edited doesn't appear but the one edited
previously instead. This fixes this problem.
Technical note: the default description for a new event was the rendering of
a template. That template was shared between all the events and overridden each
time.
The solution was to strip the identity of the template while rendering it
making it a constant and preventing it from being shared between events.
This could be done by setting rendering_bundle to True in the rendering context
(unfortunately, t-ignore is not a legitimate attributes of template tag).
Note that the same fix [1] was done on `website_hr_recruitment`.
[1]: https://github.com/odoo/odoo/commit/f1ee633f26a78636fede3e2b600c801b5f474a50
Task-2781443
closesodoo/odoo#89520
X-original-commit: 5e8be9024b8fd1cdd7caf3cb711861a4a7bee2c8
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
The Italian edi system accepts utf-8 encoded documents, but actually the
contents of the fields have to be latin-1 encoded. Format-alphanumeric
should remove any non-latin1 characters and replace them with a ?
Several fields to are also truncated before the function is applied.
This is so that these fields better match the specification. This will
help to prevent edi rejections in the future.
A test is also included to test with a few lines that should / should
not be adapted in by the format_alphanumeric function. Along with the
addition of the test, the test partner italian_partner_a's is_company
field is changed to True, since the partner is a company. The expected
xml has been altered to match the changes to partner_a.
closesodoo/odoo#89494
Task-id: 2826424
X-original-commit: 712758fc2505abfa271636caaa8ba38436086f32
Signed-off-by: Josse Colpaert <jco@odoo.com>
Purpose
=======
Avoid calling _recompute_rank for users that are not affected by the
newly created/written ranks, by filtering users by karma_min
Task-2746929
closesodoo/odoo#89463
X-original-commit: 3a0562ea809b5ba40a66fa4a996424696320f91c
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Purpose
=======
Avoid sending lost of emails for new ranks rank for each user when
installing gamification module.
Emails are now only sent outside of module installation.
Task-2746929
X-original-commit: 5dc3b3ef794b78f18713b4bcf6254ab60d62eec4
Part-of: odoo/odoo#89463
Steps to reproduce the bug:
- Create a manufacturing order to produce “Table”
- Confirm and plan the MO
- Start the work order
- Cancel the MO
Problem:
- The work order is cancelled, but the timers continue to run.
- "Block", "Unblock" and “Unplan" button should be hidden when MO is cancelled
opw-2817842
closesodoo/odoo#89442
X-original-commit: 5682015958d03f4a65969afe3fce9b9b05e5b505
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
For an imap "PEC server" we will fetch mail and set \Seen flag according to
current value.
But the way imaplib was used seem to possibly cause an issue on some
particular mail providers.
Mailing RFC* gives example of adding flags with parenthesis around flag:
eg. "A003 STORE 2:4 +FLAGS (\Deleted)"
but we are sending these command wihtout parenthesis (which seems to be
working, but apparently not for some providers).
To fix this issue, we change how we use the API to do the same thing
than in fetchmail module that is a lot more battle tested (and from logs
is sending flags in parenthesis).
* https://datatracker.ietf.org/doc/html/rfc3501#section-6.4.6
fixing #89305
fixing #81443
opw-2714596
closesodoo/odoo#89379
X-original-commit: 7dd5437a65bd43a91d6ae7e2fb4f11f2f0b1476b
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
*: base_automation, iap, web_tour
Previously, when trying to create a custom dialog, one would need to
extend the base Dialog class and configure it directly on the class,
using separate templates for the body and footer as necessary. This is
very unidiomatic owl code, and it is much more natural to simply extend
Component, and use Dialog at the root of the template, giving it slots
and props to configure its properties and contents.
This commit changes the dialog API to work as described and adapts code
that uses it.
closesodoo/odoo#89113
Enterprise: https://github.com/odoo/enterprise/pull/26462
Related: odoo/enterprise#26462
Signed-off-by: Géry Debongnie <ged@odoo.com>
pedrambiria