Since rev. https://github.com/odoo/odoo/commit/ebd17217c4e7e9ff06d97028de64fb2fc44d6266
the attribute `_editionViewType` has been introduced to use the modifiers from the correct
one2many view type.
This attribute wasn't correctly populated if multiple one2manys were imbricated. The
first view type (form in the test case) was set for the second one2many even though
the view type was list. This was due to the `visitChildren` function use that browses
through all levels (and not only the first one).
To reproduce the bug before this rev. you could try to create a new survey, add a
question (one2many) then select multiple choice and add an answer (one2many editable).
In grouped Kanban views, the list of res_ids of the displayed
records may change for several reasons:
1) 'Load more' is clicked for a column
2) a record is moved from a column to another
3) a record is moved inside a column (resequence)
4) a column is moved
5) a column is (un)archived
6) a column is (un)folded
7) a record is created/destroyed directly from the Kanban.
When this happens, the environment must be notified of the new
list of res_ids (the order matters). Before this rev., this wasn't
the case. As a consequence, when a record was opened in a Form view
after one of the 5 operations above, the pager could display
unexpected values.
Note that before the new views, cases 2, 3 and 4 weren't handled,
and case 7 already worked before this commit.
The problem occured when opening a record from a grouped list or
kanban view. In the opened form view, the pager was sometimes
incorrect. This was because the list of ids wasn't correctly
updated when groups were opened/folded.
Up to this revision, clicking on 'edit' in a record with an existing pad
and discarding the changes straight away caused the pad content not to
be displayed.
The root cause of this issue is twofold:
- a hack tricks the model into thinking the pad URL has changed by
replacing it with an object yielding the URL when JSONified;
- the pad never affects the 'dirtiness' of a record and BasicModel only
actually discards changes when the record is dirty.
When a user clicks on discard, the model does not actually discard the
changes, thereby leaving the web client into thinking the pad URL is the
object mentioned above.
We fix this issue by requiring that the model always discard changes
when clicking 'Discard', regardless of whether the record is dirty.
In fact, the lines we changed were no longer correct since the
introduction of 'doNotSetDirty' (see
https://github.com/odoo/odoo/commit/72ed3a1), as a record could be
changed without being dirty. This commit thus also ensures that such
records are also properly discarded.
Before this commit, it was not possible to copy the contents of a
multiline text field in read-only mode in Firefox without losing all
line breaks in the process. This is due to a bug affecting div tags
(see https://bugzilla.mozilla.org/show_bug.cgi?id=1390115) in Firefox.
This commit ensures that the text in a text field is surrounded by a
span (as opposed to div) tag.
Note that spans were used in saas-15, so we are in fact simply undoing
the change to divs introduced by the new views.
As mentioned in
https://github.com/odoo/odoo/commit/a752e7d1458b1d689a028fcf89b582ae74333d49,
a resize after the first render is necessary to prevent overflow issues
with fullCalendar. As changing the date would rerender the calendar, we
also need to trigger a resize then.
From this revision onwards, a resize event is triggered every time the
calendar has finished rendering its events.
Unfortunately, I was not able to write a meaningful and successful test
(I encountered PhantomJS-specific issues). I also removed the test for
https://github.com/odoo/odoo/commit/a752e7d1458b1d689a028fcf89b582ae74333d49
because it always passed regardless of whether the fix is applied.
The traceback was caused by an occurence of this.dataset, which was left
out in the new views refactoring (this.dataset has been replaced by
this.record).
Sometimes, a default_get returns a create command for a one2many,
with a dict of values containing value 'false' for a many2one. This
is strictly equivalent to the case where the many2one field isn't
in the dict of values, but we have to handle both cases, and before
this rev., we only handled the latter one.
This happens for example in Sales > Leads (must be activated in the
Settings) > in the list view, check several leads > in 'Action',
click on 'Forward to Partner' > crash.
The value for one2many fields returned by default_get may be a
list of commands, or directly a list of ids. These cases were
correctly handled. However, it seems that the value can also be
false, and when this happened, it crashed. For instance, go to
Sales > Leads (must be activated in the Settings) > in the list
view, check several leads > in 'Action', click on 'Convert to
Opportunities' > crash.
Let's assume the following situation: we have a one2many field
displayed as a list in a form view. The list isn't editable, so
when a subrecord is clicked, it is opened in a form view in a
dialog. In this form view, there is a relational field X that is
not in the list. In the main form view, there is a field with an
onchange. When its value changes, the onchange returns a new
value for the one2many: a command 5 (delete all), and a command 0
(create) with a dict of values containing a value for X. However,
as X is unknown as long as no subrecord has been open in the dialog,
the value for X can't be processed (we don't know the type of X,
so we don't know how to process the value).
Before this rev., when this happened, we discarded the value of X.
This caused an issue for example in the Quotation form view (with
website_quote installed):
- create a new Quotation
- set PartnerShip Contract as quotation template -> the onchange
returns two 'create' commands for the order_line one2many
- click on one of the two subrecords in the one2many -> error.
This rev. ensures to keep changes on unknown fields. We keep them
unprocessed, and once the form view is opened, we process and
apply them.
Since the revenue computation is an automatic system
action, it should be done in sudo(). This avoid access
error.
Indeed, if a company creates and confirms a SO, a task
can be created in another company project. Logging
timesheet from the project company is thus impossible
since the user can not access SO line of the origin
company.
Adding sudo() seems better than givin read access
to 'all' so line for timesheet user.
When deciding to prefetch records (getting records from the cache with
no value for the field being fetched), if the field was computed
`determine_value` would just get all records, not limited by the normal
prefetch limit; for large recordsets this would generate gigantic
prefetch lists for records we may not need at all.
Fix by applying the `PREFETCH_MAX` limit to records from the cache as is
done in `_prefetch_field`.
Complementarily, when traversing related fields the prefetch
environment would be lost and every record would get an empty prefetch
environment, so the values would ultimately be read one by one.
Example: select (search) 1000 product.product records, access a
related field (e.g. categ_id) in a loop, on the first iteration the
system would first read 1000 templates, then it would read each
categ_id individually, resulting in >1000 SQL queries rather than the
~2 we would expect.
Fixes#18511
A form view record may be saved even if the record is displayed in
readonly (e.g. when a button in the form view is clicked). When
this happened, if there were an html field with html_frame widget
in the form, it crashed (e.g. in Email Marketing > Mass Mailings >
open one > click on Test Mailing).
Commit 7cd2f6370 (in 10.0) recently added attribute special='cancel'
on the 'Cancel' buttons of the Settings views in Odoo. The attribute
wasn't really supported in this case by the old web framework, so
this commit also slightly adapted it, and made it reload the whole
webclient when such a button is clicked.
This commit now needs to be forwardported in saas-16, so we have to
handle the case in the new views as well. Before this rev., it
crashed, because the BasicModel tried to reload a new record (the
one of the Settings form view), so basically it performed a 'read'
RPC on a virtual ID like 'virtual_123', and the server didn't really
appreciate.
This rev. handles the case where a new record is reloaded, and
simply performs a 'default_get' instead of a read. Bonus point:
with the new views, we don't have to reload the whole webclient.
IE11 seems to be always using cache when doin an XHR request with the
same GET request.
It can be changed in several ways:
- returning a header: "Cache-Control: no-cache"
- altering the GET request with a nonce
- using the POST method instead of GET
to solve it, in this change the HTTP header is added on the response.
opw-752270
closes#18787
Before this rev., when the user opened a form view
containing a pad widget, with a pad url already configured,
a dialog directly popped asking "The record has been
modified, your changes will be discarded. Are you sure you
want to ?".
This is because of an unconventional behavior of this
widget: the field actually encodes an url, the one of the pad
to display. When the user saves, a write is forced so that
the server can retrieve the pad's content and store it in DB.
To force the write, the widget always notifies a fake change
on the url. However, we don't want this change to trigger
the confirm dialog. With this rev., this fake change doesn't
make the record 'dirty'.
*account_asset
When a button of type 'action' is clicked (execute a given action),
special keys must be set in the context (active_id, active_ids and
active_model). They must be computed regarding the record containing
the clicked button, i.e. if we are in a modal, it must be the id
and model of the record displayed in the modal.
Before this rev., we always sent the id and model of the record
displayed in the background (i.e. the id and model of the url).
This caused a bug in MRP that could be reproduced as follows:
- open a manufacturing order in form view
- click on edit
- click on one of the line of the one2many, and click on the green
icon to edit a product
- click on the update product quantity button on top of it
- the product field must be correctly filled, which was not the
case before this rev.
Date fields have magic grouping methods to specify how to group on
them like date:month, date:weeks, date:days for example. It needs
to be handled properly since date:month is not a valid field name
but date is.
Steps to reproduce the issue:
- Go to Sales/Dashboard
- Click on My Pipeline
- Group by "Creation Month"
Basically, this can be triggred from any view which has a search
view which defines a group using the magic date grouping methods.
Backport of 0de067cae9
(and 9b8bc5e5a1)
Rev. c5bd509274 attempted to improve the
pad sync mechanism when merging records (tasks), but failed to consider
the case where the pad_url field is not set yet.
This happens at create(), due to the chicken-and-egg problem with the
pad URL depending on the record ID, and therefore set *after* creation.
Ignoring the sync when the URL is not yet set should be enough, as the
URL generation method also takes care of that first sync.
Rev. c5bd509274 attempted to improve the
pad sync mechanism when merging records (tasks), but failed to consider
the case where the pad_url field is not set yet.
This happens at create(), due to the chicken-and-egg problem with the
pad URL depending on the record ID, and therefore set *after* creation.
Ignoring the sync when the URL is not yet set should be enough, as the
URL generation method also takes care of that first sync.
This commit is not retro-compatible with existing database.
Moreover, the underlying issue (opw-757039) has been fixed via commit
baca743cc0.
This reverts commit 8510c0ce37.
Before this commit, when creating a pos_order_line_pro_forma, which inherits from pos_order_line but in a different table, the create confused an overriden field (order_id)
When pos_blackbox was installed, pro forma lines would search for an pos_order instead of a pos_order_proforma upon their creation
This commit allows an inheritant of pos_order_line to use the super.create function
OPW 745685
Closes#18755
Steps to reproduce the bug:
On an empty database, install the sale module
-Activate product variants : Sales > Settings > Check Products can have
several attributes, defining variants (Example: size, color,...)
-Activate advanced pricelists : Sales > Settings > Check Advanced pricing based
on formulas (discounts, margins, rounding)
-Activate the developer mode
-Go to the product.templates list : Sales > Products
-Go to the debug menu > Edit TreeView and add the price field in the view
-Go to the debug menu > Edit Action and add the value 'uom': 1 in the context field
-Search for a pricelist : Type the name of an existing pricelist, then go to the pricelists
proposal, open the list of proposed pricelists, and select the pricelist
Bug:
The wrong value was sometimes displayed in the price field. To be more exact, the displayed
value for each product.template was the price of the product.product that has the same id.
If a product.template has an id which doesn't exist in the product_product table,
this product disapears from the list.
opw:762663
Steps to reproduce the bug:
-On an empty database, install the sale module
-Activate product variants : Sales > Settings > Check Products can have several attributes, defining variants (Example: size, color,...)
-Activate advanced pricelists : Sales > Settings > Check Advanced pricing based on formulas (discounts, margins, rounding)
-Activate the developer mode
-Go to the product.templates list : Sales > Products
-Go to the debug menu > Edit TreeView and add the price field in the view
-Search for a pricelist : Type the name of an existing pricelist, then go to the pricelists proposal,
open the list of proposed pricelists, and select the pricelist
Bug:
A traceback was raised.
opw:762663
In the main_flow_tour, we edit a related record of a many2one in a
one2many. A modal is displayed and we make some changes. We
then click on 'Save' in the dialog. The next step is to add a new record
in the one2many, so we click on 'Add an item'. However, we didn't
wait for the modal to be closed before clicking, which is actually not
possible in practice (because of the modal backdrop).
This made the tour fail when run from the browser, since commit
c300e5e, which produces a redraw of the line containing the
many2one that has been edited.
This rev. ensures that we wait for the modal to be closed before
adding a second record.
A `currency_id` field on a `hr.expense.sheet` only makes sense if all
expense lines are in the same currency. It is very likely to not be the
case, so don't format the total amount.
In master, the fild should simply be completely removed.
opw-761098
When a replying to an email, the matching alias should first verify access
via the parent record if exists (i.e. check on the project instead of
on the issue itself).
The new "My Activites" filter introduced by rev. 87e457158e
should not be in the same group of the search view as other activity
filters (Overdue/Today/Upcoming), otherwise they are combined with OR
instead of AND.
This is particularly misleading when coming from the Sales dashboard, as
the "Overdue" button of "My Pipeline" will lead to a list of
opportunities with "My Activities OR Overdue Activities", showing *all*
opps with overdue activities, not just yours.
When creating a customer invoice with description/reference with more than
64 characters, the description was cut to generate the name of the account move
lines. But it's possible to create an entry with more than 64 characters as name
by the interface. The limitation is deprecated.
opw:760316
Martin Geubelle