Currently, while trying to share the survey with 'one page per section'
layout, if the survey has only questions and no sections, a warning is
raised that says 'You cannot send an invitation for a survey that has
no questions'. It is misleading because in this case, what you do not
have is atleast one section with question(s).
This commit fixes the warning message for 'one page per section' type
of survey and gives clear idea to the user about what is missing.
TaskID-2611996
closesodoo/odoo#74694
X-original-commit: 381d18888d81f6797004c718fee5dbd9706b3122
Signed-off-by: awa-odoo <awa-odoo@users.noreply.github.com>
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Steps to reproduce:
- Install Inventory and Studio modules
- Go to Inventory -> Products -> Products
- Open Studio
- Click on Reports tab
- Select `Product Routes Report`
Issue:
Traceback is raised.
Cause:
No 'product_id' provided in data while getting report values.
Solution:
If no `product_id` key or value in data, set `docids` (or an empty
list if no docids) as product_id and set 'warehouse_ids'
to an empty list.
opw-2619142
closesodoo/odoo#74937
X-original-commit: de6b1636818423b2d2b82f900c3b30515af73279
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Signed-off-by: bon-odoo <nboulif@users.noreply.github.com>
Issue:
In an action, if we add to the context a key `search_default_x_ids`
(who is a many2many field) with an array of ids as value, it will
display/use only the first value in the search bar.
Cause:
If filter-type is 'field' and it's an array, it will take the first
value.
Solution:
Take first value of array only if field-type is a `many2one`.
Inspired by Odoo v13.0
opw-2596345
closesodoo/odoo#74936
X-original-commit: 1083bd204a10c9ec1708ba09e85d50fcba8ba8af
Signed-off-by: Julien Mougenot (jum) <jum@odoo.com>
Signed-off-by: bon-odoo <nboulif@users.noreply.github.com>
Remove read access on `ir.model`, `ir.model.fields`, `ir.model.fields.selection` and `ir.model.data` for employees.
To access such records, the code must use the helpers (`_get`, `ref`,...) instead of CRUD operations directly.
Simplify the helpers to ir.model.data that were public and redundant.
self.env.ref is encouraged instead but with the slight drawback that `ref` makes a call to `exists()` (`_xmlid_lookup` can be used if this wants to be avoided).
Part of task-id 8203
closesodoo/odoo#69120
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
If you use firefox and have set cookie to be deleted when you close
firefox, server worker are nuked which cause an error to be shown in
website_event_track:
https://bugzilla.mozilla.org/show_bug.cgi?id=1429714
With this fix, the error is handler and shown in the console instead of
as a traceback to the user.
opw-2556734
closesodoo/odoo#74890
X-original-commit: 8e81db2515dbed196433f2127591384f2e23bfaa
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
The attribute lang was set in the template website.website_configurator.
This is not needed. This commit therefore remove this code.
task-2602521
closesodoo/odoo#74931
X-original-commit: d65efdb9896664cba132a08fe85dad6baa348f3b
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
When the user selects text, the editor compares its closest block type
with a pre-made list of text types (eg. p, h1...).
In case of a match, the 'active' class is applied on the relative
toolbar component.
This commit will extend the comparison list adding text styles that were
initially missing (= the code, h4, h5 and h6 tags were never marked as
active).
Related to task-2496339
closesodoo/odoo#74925
X-original-commit: 1f1157c7e5c2df1bf318ad3a32e7030c969f5261
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
the data dom:autoMoreMenu:adapt was added, so that the external
code can update the menu directly when needed
closesodoo/odoo#74920
X-original-commit: 7283bc5b07ae489d3ece926e2860c26c3d891d59
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
- A typo has been introduced by the PR https://github.com/odoo/odoo/pull/61035
This forbids to display the "Waiting For bill" tag on the portal
page for the purchase orders.
closesodoo/odoo#74888
X-original-commit: 0b9d9ff95d2ee9a72b10ddff006399a054bfa56c
Signed-off-by: Toufik Benjaa (tbe) <tbe@odoo.com>
This module allows users to be notified by email when a product out of
stock comes back in stock. For that they can add it to their wishlist
and select the appropriate option.
We show out-of-stock warning in all case whatever the show availibility option.
You cannot custom you 'in stock' message ot free message.
Spec of Pde and Fp
Part of https://github.com/odoo/odoo/pull/68221
task-2458165
closesodoo/odoo#68221
Related: odoo/upgrade#2405
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Co-authored-by: Kersten Jeremy <jke@odoo.com>
Co-authored-by: Younn Olivier <yol@odoo.com>
Some return values were missing on cartHandlerMixin._addToCartInPage and
WebsiteSale._submitForm, therefore it was not possible to wait for their
promises to be resolved.
task-2458165
Part of https://github.com/odoo/odoo/pull/68221
Coupons and promotion programs can now be shared by creating a link that can
directly be used by the customer.
Using the link, the system will try to apply the coupon/promotion to the
customer's order.
If this can't be done, the error will be shown to the user, for instance
"A minimum amount of 1000$ is required to get the free ipad".
That coupon/promotion will then be stored in session and the system will try
automatically reapply it when something is added to the cart.
task-2489749
closesodoo/odoo#69053
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Co-authored-by: Romain Derie <rde@odoo.com>
Co-authored-by: Jeremy Kersten <jke@odoo.com>
Co-authored-by: Tom De Caluwé <tdc@odoo.com>
How to reproduce the problem:
- Install the repair App
- Repairs -> Create (a Repair Order) (and activate the debug mode)
- Change the Location Field to something else (than the usual default WH/Stock)
- Open Developer Tools -> Set Defaults
- For Defaults, choose "Location = [the changed Location]", "All Users" -> Save Default
- Create a new Repair Order: the Location is not set to the default we set earlier through the Developer Tools
Cause of the problem : an Onchange method was overriding the default Location
Solution : it will now check, in the onchange, if the change is necessary, before overriding the default.
opw-2545876
closesodoo/odoo#74871
X-original-commit: 9877ad1599513338c5333d3a728edb8d6ebcac26
Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>
Previous fix commit 5e34a02 was too aggressive in when it would delete
the move_finished_ids. In certain use cases it would result in no
move_finished_ids and a corrupted MO:
Steps to reproduce:
1. Create a new MO
2. Save the MO (do NOT confirm)
3. Update the qty to product_qty (qty to produce)
4. Confirm + Mark As Done
End result: "qty to produce must be positive" error whenever MO was
attempted to be completed and MO can never be completed.
To fix this, we split out when the move_finish_ids. They should all
be deleted ONLY when the product to produce is changed. Unfortunately to
cover all cases, we must always wipe the moves whenever the product is
changed (e.g. when changing the product twice with the original product
being the final saved value, we have no way of knowing to keep the
original move_finished_ids due to onchange only being able to check
against the last saved value, not last selected value).
Additional test + test update done to support preventing this
catastrophe in the future.
Part of Task: 2618962
closesodoo/odoo#74859
X-original-commit: fa468782f4a52334fd055fb5cd11e2c62ddd6f9d
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Signed-off-by: Tiffany Chang <ticodoo@users.noreply.github.com>
When getting the remaining days before the deadline of an activity, the
module applies the TZ offset on the deadline date. This leads to
incorrect data.
To reproduce the error:
(Need crm)
1. Configure your computer:
- TZ: America/Anchorage (UTC-8)
2. Log in DB
3. Ensure user's profile has the correct TZ
4. Create a lead
5. Schedule an activity A:
- To Do
- Due Date: tomorrow
6. CRM > Sales > My Activities
Error: The deadline of A is "Today" instead of "Tomorrow"
To get the days difference, the module computes the current date in
user's TZ. Then, it takes the deadline value and applies the offset
between UTC and user's TZ to this deadline value. Eventually, it
compares the two dates.
Here is the problem: the deadline is a date, not a datetime. As a
result, when applying the offset, if the user's TZ is a "negative" one
(UTC-...), it will change the date to the previous day.
For instance, suppose current date is 2021/08/06. In above use case, the
deadline is 2021/08/07. When comparing the dates, the deadline
(2021/08/07 00:00:00) becomes 2021/08/06 16:00:00 (because we are
UTC-8), thus the module will display "Today".
We shouldn't add any offset on a date field.
OPW-2448835
closesodoo/odoo#74858
X-original-commit: 549f0a11deb700dc6a65a3fbff94a889b9b1f278
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Adrien Widart <adwid@users.noreply.github.com>
If we have a reconciliation model having a rule using a regex, we are extracting
the balance from the label, but we should not raise an error in case the regex
is matching an incorrect float value, and just set a zero balance instead.
closesodoo/odoo#74853
X-original-commit: a8d65794cfe6c7c64e03b13b8cbaa52a67b25b70
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Alex Tuyls <alt-odoo@users.noreply.github.com>
Purpose
The aim of the current task is to adapt the design of this new widget to the
list and kanban views.
SPECIFICATION
Kanban
when there is only one record set in the m2m field, display it like a
many2one_avatar widget when there are two or three records set in the m2m
field, display the avatars next to each other when there are more than three
records set in the m2m field, display the first two avatars, then a grey circle
with +X in it (where X is the number of records beyond the first two), when
hovering the +X avatar, open a tooltip with the list of the remaining records
the display order of the records is the same as the order in the m2m field
the avatars behave like in the other avatar widgets (i.e. darkens on hover and
clicking on it opens the chat) except the +X avatar that does not darken or has
a cursor:pointer; on hover and is not clickable
List
same specs as for the kanban view, with the difference that the widget displays
up to five records instead of three when the widget is editable display it like
the current formview version of the many2many_avatar_user widget (i.e. tags
with avatars)
task-2563591
closesodoo/odoo#72166
Signed-off-by: Simon Genin (ges@odoo) <ges@odoo.com>
Problem: The journal dashboard show wrong values for the late invoices.
Background details: The filter for the "Late" invoices is not in sync with the sql query in the dashboard python code. The filter searchs for the invoice_date_due field while the sql searchs for the date field.
closesodoo/odoo#73992
X-original-commit: f1e9e756b8806aca92fda4d528fd0b23842e967a
Signed-off-by: William André (wan) <wan@odoo.com>
A traceback occurs after the following operations:
1. Go to Accounting-> Reporting-> Invoice Analysis
2. Open Pivot view
(the pivot view is grouped by ["invoice_date"] (for rows) and by ["product_categ_id"] (for columns))
3. Click on "Flip Axis"
4. Select filter "Invoices"
5. Close row header "Total"
This happens because at some point `this.data.rowGroupBys` and `this.data.colGroupBys`
happen to point to the same object (they are both equal to the action group_by):
At step 2, rowGroupBys is set to be the action group_by (loading the model).
At step 3, colGroupBys is set to be rowGroupBys (and thus the action group_by).
At step 4, rowGroupBys is set to be the action group_by (reloading the model).
So that the step 5, just before the traceback, removes the group by "product_categ_id"
from `this.data.rowGroupBys` and thus `this.data.colGroupBys`.
This causes a problem when generating the pivot table.
The fix to that problem (and to some similar problems) consists
to never equalize `this.data.rowGroupBys` with some other fixed groupby
(action group_by here).
opw-2511057
closesodoo/odoo#74792
X-original-commit: 1e66fd9e9888e75d8952d8812458d806f05dcf8b
Signed-off-by: Mathieu Duckerts-Antoine <Polymorphe57@users.noreply.github.com>
Co-authored-by: Andrea Grazioso <agr@odoo.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
The "View Bookmark" button is used to set URL parameter to be able
to jump to bookmark by copy pasting the generated link.
As there is no way to copy this, this feature is useless in our case.
closesodoo/odoo#74833
X-original-commit: 652461aed59aa97e48f0a8934316cdb846afd769
Related: odoo/enterprise#20131
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
At the moment, it is possible to archive a journal for which some
entries are still waiting to be auto-posted in the future.
Add a constrains to avoid make sure that it is no longer possible,
since it shouldn't.
Task id #2585454closesodoo/odoo#74690
X-original-commit: 850eb5100d6405d3a7293e06910a1c5355fdb8d8
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Signed-off-by: Nicolas Viseur <vin-odoo@users.noreply.github.com>
No need to keep it, it's useless and can confuse translators
closesodoo/odoo#74782closesodoo/odoo#74832
X-original-commit: 40c74e686f23c10e35000be583716d0c093ce3b3
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Steps to reproduce
- On a DB with german localization and SKR04 chart
- Accounting > Configuration > taxes
- Select Steuerfreie Ausfuhr (§4 Nr. 1a UStG) or
Steuerfreie innergem. Lieferung (§4 Abs. 1b UStG)
Issue
The tag l10n_de.tag_de_intracom_community_delivery doesn't appear
opw-2545462
closesodoo/odoo#74828
X-original-commit: 21d02671fce48ef0a7ac1c70602613852819b50c
Signed-off-by: William André (wan) <wan@odoo.com>
That ID was removed with c8c8eb3d56, but the JS code is expecting to find
this ID inside the DOM to increment the flag counter.
Courtesy of @dwa-odoo
Spotted while working on task-2167561
closesodoo/odoo#74819
X-original-commit: 2e3f78569e2bb2e0cd2ad9271b1877a43a8c4abb
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Signed-off-by: Romain Derie <rdeodoo@users.noreply.github.com>
When the Product Price precision is greater than the currency precision,
it can lead to incorrect data
To reproduce the error:
(Enable debug mode)
1. Settings > Technical > Database Structure > Decimal Accuracy, edit
Product Price:
- Digits: 3
2. Create a PO
- Add a product:
- Quantity: 12
- Unit Price: 0.001
3. Save, Confirm, Edit the PO:
- Qty Received: 12
- (Note that the total is $0.01)
4. Create a bill:
- Add the PO to the field "Auto-Complete"
Error: The unit price is $0.000 and so does the total
The rounding of the unit price should be based on the Product Price
precision, not the currency precision.
OPW-2601867
closesodoo/odoo#74813
X-original-commit: 1123856c77cce4b69059b63c2bcbb382c7f0719e
Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>
Signed-off-by: Adrien Widart <adwid@users.noreply.github.com>
In the "view" service, there is a cache s.t. we don't do the
load_views rpc each time we enter an act_window action. However,
before this commit, we never did cache hits because we modified
(in place) the "views" key inside the action, which is used to
generate the cache key.
closesodoo/odoo#74783
Signed-off-by: Bruno Boi <brboi@users.noreply.github.com>
Mitul Shah