If you want to de-activate the multi company ir.rule, those checks will
still raise an error.
Task 2198433
closesodoo/odoo#47291
X-original-commit: 12a81a3a5265cbd18f5c00ab439cd1486696521b
Signed-off-by: lul-odoo <LucasLefevre@users.noreply.github.com>
This commit takes advantage of modern JS syntax (like Fetch API, arrow
functions) to shorten the `odoo.reloadMenus` function's implementation.
Original implementation of this function was in commit 8a28cc22fd
PURPOSE
Try to move from onchange / default_get to stored editable computed fields.
Behavior should be the same (computed or set by user), with support of
create / write / onchange field update without additional code.
SPECIFICATIONS: GLOBAL RULES
Update classic fields updated in some cases by onchange and/or default methods
by fields with store=True, readonly=False. It means their value comes either
from manual user input, either from trigger based computation.
Remove onchange and default_get when possible, leading to an unique computation
method and clearing fields definition.
Also clean some fields definition inconsistencies, notably required fields
that should instead be correctly computed or default that have no real meaning.
SPECIFICATIONS: OTHER COMMITS
Perform some light code cleaning before updating fields.
Keep some explicit onchanges:
* onchange partner on registration: required as UI flow is a bit different
from automated code update;
* onchange track boolean on event: allow to simplify fields dependencies;
Rename event type default_registration_max to seats_max to match
naming.
Improve event type data and demo
See sub commits for more details.
LINKS
Task ID 2089156
Community PR #42911
Upgrade PR odoo/upgrade#912
Related: odoo/upgrade#912
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Purpose is to have matching names between event type and event to ease code
understanding.
LINKS
Task ID 2089156
Community PR odoo/odoo#42911
Upgrade PR odoo/upgrade#912
Currently website_menu boolean field is not copied when copying an event. It
comes from an issue related to duplicating website menus. It seems real issue
has been fixed at 1a8993e0cb . Current copy=False on website_menu is a wrong fix
due to some mismatch in forward-port. We can therefore copy website_menu
again.
LINKS
Task ID 2089156
Community PR odoo/odoo#42911
PURPOSE
Try to move from onchange / default_get to stored editable computed fields.
Behavior should be the same (computed or set by user), with support of
create / write / onchange field update without additional code.
SPECIFICATIONS: GLOBAL RULES
Update classic fields updated in some cases by onchange and/or default methods
by fields with store=True, readonly=False. It means their value comes either
from manual user input, either from trigger based computation.
Remove onchange and default_get when possible, leading to an unique computation
method and clearing fields definition.
Also clean some fields definition inconsistencies, notably required fields
that should instead be correctly computed or default that have no real meaning.
SPECIFICATIONS: WEBSITE_TRACK(_PROPOSAL)
Keep an explicit onchange for tick / untick of website_track_proposal. Indeed
otherwise you have a loop of dependencies between website_track and
website_track_proposal
* untick website_track: website_track_proposal = False (done in _compute_website_track_proposal)
* tick website_track: no effect
* untick website_track_proposal: no effect
* tick website_track_proposa: website_track = True
It would be complicated to write in computed fields, as they depend on each
other, on cache and current values, ... It is therefore simpler to keep an
onchange: when ticking website_track_proposal set website_track as True in
interface.
LINKS
Task ID 2089156
Community PR odoo/odoo#42911
PURPOSE
Try to move from onchange / default_get to stored editable computed fields.
Behavior should be the same (computed or set by user), with support of
create / write / onchange field update without additional code.
SPECIFICATIONS: GLOBAL RULES
Update classic fields updated in some cases by onchange and/or default methods
by fields with store=True, readonly=False. It means their value comes either
from manual user input, either from trigger based computation.
Remove onchange and default_get when possible, leading to an unique computation
method and clearing fields definition.
Also clean some fields definition inconsistencies, notably required fields
that should instead be correctly computed or default that have no real meaning.
LINKS
Task ID 2089156
Community PR odoo/odoo#42911
RATIONALE
Manual onchange is necessary because you spot an issue (or customer complains).
Automatic update through computed feild is only there to try to add missing
pieces of information but cannot decide which is the correct field value to keep.
SPECIFICATIONS
Keep an explicit onchange on partner_id. Rationale : if user explicitly
changes the partner in interface, he wants to update the whole customer
information. If partner_id is updated in code (e.g. updating your personal
information after registeration in website_event_sale) fields with a value
should not be reset as we do not know which one is the correct one.
How it should behave as following
* computed fields based on partner_id should only update missing
information. Indeed automated code cannot decide which information
is more accurate;
* interface should allow to update all customer related information
at once. We consider event users really want to update all fields
Tests are added to ensure behavior is not modified without notice.
LINKS
Task ID 2089156
Community PR odoo/odoo#42911
PURPOSE
Try to move from onchange / default_get to stored editable computed fields.
Behavior should be the same (computed or set by user), with support of
create / write / onchange field update without additional code.
SPECIFICATIONS: GLOBAL RULES
Update classic fields updated in some cases by onchange and/or default methods
by fields with store=True, readonly=False. It means their value comes either
from manual user input, either from trigger based computation.
Remove onchange and default_get when possible, leading to an unique computation
method and clearing fields definition.
Also clean some fields definition inconsistencies, notably required fields
that should instead be correctly computed or default that have no real meaning.
SPECIFICATIONS: REQUIRED FIELDS
As computed fields are computed after create required attribute cannot be
respected without computing them beforehand. That is why we have some custom
code to compute required fields if not given at create and update the creation
values accordingly.
SPECIFICATIONS: MAIL SCHEDULING
Mail scheduling on event type is modified in this commit. Previously checking
the use_mail_schedule radio button had no effect on event_type_mail_ids field.
It is now reset if unchecked. It is therefore coherent with use_ticket and
event_type_ticket_ids field behavior.
LINKS
Task ID 2089156
Community PR odoo/odoo#42911
Co-Authored-By: Thibault Delavallée <tde@odoo.com>
Co-Authored-By: Michaël Mattiello <mcm@odoo.com>
In order to keep things organized, let us move some models in their own file
and rename some test files. Some odd methods are relocated to better follow
guidelines. Dead code is removed because we do not like dead code.
LINKS
Task ID 2089156
Community PR odoo/odoo#42911
- Purpose is to include orders that have no lines
in the sales report for consistency
- In report, 'Quotation' filter shows quotation which
is in 'draft' or 'sent' stage.
task-2122948
Closes- #42662
Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>
Issue
- Install Sale
- Create SO
- Add a note line with a very looong word
- Print PDF
No line break, table is expending out of
the visible report.
Cause
There is no line break CSS rule
Solution
Use word-break: break-word; in order to
break line without cutting words.
OPW-2195984
closesodoo/odoo#47272
X-original-commit: af8fb786a9569562cefb7d8ea63454cddc04cd44
Signed-off-by: Jason Van Malder (jvm) <jvm@odoo.com>
Since 13.2, the cards cannot contain an overflowing element anymore as
we needed to enforce 'overflow: hidden' for the border-radius option.
Note: this commit adds data-vxml="001" on the snippet. This will allow
users which have already added the card version of the snippet in their
website to receive a notification that the snippet is deprecated once we
will have implemented that system (in progress).
task-2208802
closesodoo/odoo#47228
X-original-commit: 220ec38e7538389279eb2dce9c897052d680ea1a
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
No default url on countdown's urlpicker anymore. Only a placeholder.
Also redirect to homepage if no url.
Part of: https://github.com/odoo/odoo/pull/46640
task-2210358
closesodoo/odoo#47235
X-original-commit: a0d983e94e3681a3f3e55cc445defc1ec862c606
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
The urlpicker was not closing properly when a value was selected.
Part of: https://github.com/odoo/odoo/pull/46640
task-2210358
X-original-commit: 6f722d919cd650d5c0b1b9c4a878fd519267c348
- Create 2 companies A & B
- Set the website in A
- Set the user in both companies, main company being A
- Create a SO template in company B
- Click on "Design Template"
An AccessError is raised because:
- `slug` accesses the `display_name` of the template which is in company
B
- the `allowed_company_ids` is set to company A in [1]
A solution could be to always set:
```
context['allowed_company_ids'] = request.env.user.company_ids.ids
```
But the side-effects could cause other issues.
Therefore, we handle the `slug` manually.
[1] https://github.com/odoo/odoo/blob/af411b866aa2052c01168342f8f05ae3dabad83e/addons/website/models/ir_http.py#L203
opw-2194103
closesodoo/odoo#47249
X-original-commit: 0bcfffd291aceb74a5260a49d2fa3032f511dba1
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Purpose
=======
We don't have the description of the payment terms in the online SO
even if we get it on the report.
Specification
=============
Fix the bad usages of t-field on the website quote.
task-2186685
Closes- #46815closesodoo/odoo#47116
X-original-commit: 0f622ae61dcbb454b5d7a4124dfcc5187085a64d
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
purpose of this commit is to change the field type
of min_quantity from int to float on product pricelist
object
task:2165208
closesodoo/odoo#45792
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
When passing a default field chain to ModelFieldSelector, the page data is
not set correctly for the relational field. To understand the issue :
- login to v11 enterprise all db branch in runbot (debug mode recommended)
- create a mass mailing, add subject, select 'Contact' in `Recipients` field
- click on domain selector and select 'Company' from ModelFieldSelector popover
- click somewhere else to close the popover
- again open domain selector and observe the popover
Current behavior : fields of `Contact` are visible in the page even thogh
`Company` is selected in the ModelFieldSelector
Expected behavior : fields of `Company` should be visible
This commit fixes the issue by correctly pushing the page data
in ModelFieldSelector.
task - 2058702
closesodoo/odoo#47231
X-original-commit: 5746c2705c324b124445f38ead4f75624b3f99e3
Related: odoo/enterprise#9124
Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>
Steps to reproducethe bug:
- On an existing product P, add alternative products under the eCommerce tab
- Go to the website
- Check that the compare button is enabled on the main shop page
- Turn off comparison button in the list under customize menu
Bug:
The compare button is still available on the alternative products of P.
opw:2201874
closesodoo/odoo#47230
X-original-commit: 9bf0d15ff4e1fcb9d7003d06f7e904cc9421b13b
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Before 13.0, the "Payment reference" column was linked to the 'ref' field.
In 13.0 it is linked to "invoice_payment_ref".
So the field reference was not visible in the list view
opw:2201763
closesodoo/odoo#47195
X-original-commit: 6acba443bd4e81c07eb5f4f48e1b4e554b4c5d13
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Let FEC report be generated by users having access to
full accounting feature or who are Accountants.
Task: 2210808
X-original-commit: 89fd50e47dcd4c6fda9342fce872283c18dc39b1
Let's assume a form view with a boolean field and a one2many field,
displayed for instance with widget many2many_tags. There is an
onchange on the boolean field, which populates the one2many, e.g.
[[5], [0, 0, {display_name: 'name', other_field: 'value'}]]
Before this commit, only the display_name was sent to the server on
save, because 'other_field' is unknown by the webclient.
Similar situations occurred with one2manys displayed as lists, and
onchanges returning values for fields that aren't in the list.
These situations probably didn't exist in Odoo yet, but a pending
task on website event adds one.
This commit ensures that all values returned by the onchange for
the x2many subrecords are sent back to the server when the user
saves.
closesodoo/odoo#46807
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
This commit fixes two issues that occurred in the following
situation: in a form view, have a one2many field F1 displayed as a
list, that contains another one2many field F2, displayed with
widget many2many_tags (in the list), and with a list in the form
(in the dialog). In the dialog, the list of F2 displays a
field, say 'name', which has an onchange that sets 'display_name'.
Moreover, there is an onchange in the (main) form view, that
populates F1 and F2, for instance, it returns something like: {
F1: [[5], [0, 0, {
F2: [[5], [0, 0, {
display_name: 'xxx',
name: 'xxx',
}]]
}]]
}
1) If the user opens a related record in F1, and adds (in the
dialog) a related record in F2, then validates the dialog, the
newly created record in F2 isn't correctly displayed in the
many2many_tags (the display_name is `false`), i.e. the onchange
hasn't been applied.
2) If field 'name' in F2 in the list is required, the new record
can't be saved, even if the user enters a correct value.
In both cases, the reason is that we use the incorrect viewType in
datapoints: as we don't specify that we specifically want 'list',
the 'default' one is taken, and we thus use the fieldsInfo of the
many2many_tags, which only knows field 'display_name'. As a
consequence, onchanges aren't correctly applied (issue 1), and
fields aren't correctly reset (issue 2).
Issue reported on task 2189529
When x2many fields are displayed with widgets like many2many_tags,
there is no limit on the number of related records to fetch and
display. In this case, the 'limit' attribute on the datapoints is
undefined. This could lead to weird issues when the limit is used
in computation, e.g.
var index = list.offset + list.limit; // = NaN
There are several occurrences of the above examples in the code,
which can be observed in specific scenarios, e.g. the one encoded
in the test. In this scenario, when the bug occurs, new records
added to editable list views are inserted on top (even if the list
is editable="bottom"), but the edited row is the last one.
Issue reported on task 2189529
Let's assume the following scenario in a form view:
- have a one2many field, say fieldA, displayed as a list,
containing another one2many, fieldB, (no widget, thus
displaying 'n record(s)')
- the one2many list is not editable, so there is a sub form view,
displaying fieldB as a list, and in this list some random field,
say fieldC, is displayed
- have a random field on the main form view, with an onchange to
populate the one2many
- set that random field s.t. the onchange returns something like
fieldA: [[5], [0, 0, {fieldB: [[0, 0, {fieldC: 'value'}]]}]]
- there is now a record in fieldA's list, displaying '1 record'
as value for fieldB
- click on that record to open it in a form view (dialog)
- in the dialog, in fieldB's list, we expect to have a single row
displaying 'value' as value for fieldC
Before this rev., it crashed when opening the record in the dialog,
whether the form view was inline or not.
The crash occured because fieldB was already in the list view, so
datapoints already existed for it (a list datapoint, and record
datapoints for records in the relation, in our example one record
datapoint). However, those datapoints didn't have the fieldsInfo of
the form view. When opening the form view, we added the fieldsInfo
of the form to the datapoint of the record we opened, but we didn't
recursively apply the fieldsInfo to its children. As a consequence,
when rendering the list view for fieldB in the dialog, we haven't
the information about fieldC, and it crashed.
Note that if fieldB wasn't present in fieldA's list view, it worked
fine because datapoints didn't exist before we opened the record in
the dialog.
Task 2120235
When installing website_sale_coupon, you are forced to install sale_management,
it shouldn't be the case.
Task Id : 2192587
closesodoo/odoo#46416
Related: odoo/upgrade#861
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
This commit moves the product search input snippet options from a modal
to the option side panel.
Part of #45176
task-2189645
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Remove aggregation from `message_format `and `_message_read_dict_postprocess`.
There should be no functional change in this PR.
Purpose
=======
The existing code working with "tree" for aggregation and doing explicit "read"
or "search" for related fields does not seem necessary since the ORM of v13.
Considering that it adds complexity to the method, if its original purpose is
not necessary anymore, it would be better to change it.
The notable changes of the ORM that would justify this task are:
- single cache, shared between current user and sudo (which is called a lot in
those methods and might explain why the "tree" mechanism was put in place
originally)
- m2o and o2m being kept consistent with each other, which allows accessing o2m
through fields directly (instead of having to use "search" to ensure getting
consistent data)
Explanation
===========
Doing "read" or "search" could be counter-productive if the data are already in
cache because using those methods will lead to a query no matter what.
The ideal way is to simply access the fields through the records.
As for the "tree" and aggregation in general, the prefetch is automatically
taking care of that when iterating.
task-2180311
closesodoo/odoo#43841
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Currently, when clicking on the systray activity action icon and click on any
record from the activity, kanban or list view, not redirecting to its form view.
This commit adds the form view for that action and now click on record will
redirect to its form view.
task-2198480
Closes https://github.com/odoo/odoo/pull/46877closesodoo/odoo#47208
X-original-commit: 3fd30316c0af9a6ca2ea4962f2e2f832e68dee54
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Prevent unexpected loss of context.
closesodoo/odoo#47194
X-original-commit: d6299de8c83d56fc5e05ba0efd8558c4e5b21572
Related: odoo/enterprise#9111
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
- Active 'Round Globally'
- Create the tax:
Amount: 21 %
Tax Included
- Create the following invoice:
Line 1: qty 1.0, price 11.90
Line 2: qty 1.0, price 2.80
The Taxes amount should be 2.56 since we apply a 'Round per line' logic
in case of included taxes.
opw-2181486
closesodoo/odoo#47175
X-original-commit: a55bc67f0797f412c3bd82074c3f8f5d1497bce2
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
This commit removes an unused and undefined variable that raised an error when
the user tries to answer a mandatory char_box question.
Oversight of commit: 0675d68afb
Task 2212021
closesodoo/odoo#47174
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
How to reproduce
================
You must have
- a form view with a one2many list
- in this one2many list add a column of a reference field
How to reproduce
1. open the record associated to the reference field
2. edit this record in the form modal view
3. click on save
-> Traceback
Bug
===
In `basic_model` the attribute `localData` become inconsistent
because of the method `_fetchReferenceData`.
We want to store the ID of the parent and not the all dict.
closesodoo/odoo#47171
X-original-commit: af411b866aa2052c01168342f8f05ae3dabad83e
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
from `message_format` and from `_message_read_dict_postprocess`.
The reading and initial formatting is done by `_message_read_dict_postprocess`,
which has been renamed more simply to `_message_format` due to its new goal.
This makes the methods easier to follow and does not increase the query count.
It actually reduces it when the data were already in the cache, by not always
reading them again.
Part of task-2180311
PR: #43841
This makes the method easier to follow and does not increase the query count.
It actually reduces it when the subtype data were already in the cache, by
not always reading them again.
Part of task-2180311
PR: #43841
in `message_format` and in `_message_read_dict_postprocess`.
This makes the method easier to follow and does not increase the query count.
It actually reduces it when the notifications and tracking data were already in
the cache, by not always reading them again.
Part of task-2180311
PR: #43841
in `_message_read_dict_postprocess`.
This makes the method easier to follow and does not increase the query count.
It actually reduces it when the attachment data were already in the cache, by
not always reading them again.
The `has_access_to_model` is removed and replaced by `sudo` because:
- from portal everything is sudo so it's pointless to check access on top of it
- from backend, it's almost impossible to trigger the case, and it's not like
returning is_main True would leak any sensitive information to an employee
Part of task-2180311
PR: #43841
It was partially tested already as part of some other performance tests, but
this new test will cover more specific cases of `message_format` and
`_message_read_dict_postprocess`.
The goal is to ensure the performances are not made worse by the following
commits, or even to be able to notice when they are made better.
Part of task-2180311
PR: #43841
Similar to what is done for the other tests, mute unnecessary log such as
`odoo.tests: skip sending email in test mode`.
Part of task-2180311
PR: #43841
Lucas Lefèvre