When sorting records according to a many2one field in a list view
embedded in a form view, the js would sort according to their ids,
in a seemingly arbitrary order.
Thus sorting records according to a field with values in ("a", "b", "c")
could be sorted as "a", "a", "c", "b" instead of "a", "a", "b", "c".
We make the comparison on the name of the field instead.
opw 1838860
content_subtype was a parameter to message_post allowing to give plaintext
content instead of html content. It has been removed at 74d4b3902d. This
commit cleans some leftover bits referencing this now removed parameter.
... in session_storage.
The current action is stored in the session_storage (stringified),
so that it can always be restored on F5 (useful for dynamic
actions). Before this rev., it was stored with it's 'raw' context,
i.e. before its evaluation. However, when this context is an
instance of a CompoundContext, it is meaningless once restored.
So this rev. ensures that the action is stored with its evaluated
context.
Recently, rev. c0809dd41 removed a protection in the reload of
Kanban views with progressbars. This protection ensured that the
manual reload of the progressbars was only done when one of the
records of the Kanban view was updated (and not when a column, or
the whole view was).
However, removing it highlighted a bug linked to the manual reload
of progressbars, which messed up the list of ids in the
environment. As a consequence, for instance, if the user archived
the records of a column, and then opendc a record in form view,
it couldn't use the pager anymore.
Besides fixing this bug, this rev. re-introduces the protection,
and refines it to prevent 2 useless RPCs when the whole Kanban
view was reloaded.
opw~1841276
opw~1841342
Assume a one2many field inside a form, displaying field A in its
list view, and a field B in its (dialog) form view. Moreover, there
is an action button in the dialog, which updates the value of B.
Before this rev., B wasn't correctly reloaded when the button was
clicked, because the BasicModel reloaded the fields on the list
view (i.e. field A), whereas it should reload the fields in both
views.
This fix is twofold. First, we force the viewType to 'form' when
the record is reloaded, instead of the default ('list'), so that
fields in the form view are correctly reloaded. Second, when we
open the form view in the dialog, we add the fields of the list
view to the dict of fields of the form view, so that the form
is aware of those fields and can ask the model to reload them
(still without displaying them).
Fixes#24189
In the chart of account editor, which is an editable list with 2
contiguous monetary field, we could not change the first then move to
the second using the TAB key: the focus was not set on the input of the
second monetary field, and when it is, that input is destroyed and
recreated so the focus was lost
Before this fix, the user needed to hit TAB twice to move to the next
field.
After this fix, the user can navigate between fields monerary with TAB
When the focus is on a kanban card that do not have
oe_kanban_global_click or oe_kanban_global_click_edit when hitting the
ENTER key,
before this fix, the default action was to open the record of the card
after this fix, the action executed will be the action of the first
button or link of the card
if the card has the oe_kanban_global_click or
oe_kanban_global_click_edit class, the record still opens with ENTER key
Have a One2Many
The views of that o2m define two inline views: the list and the form
in the list view, put a field that isn't in the form and used in a domain
Try to add an item to the list
The form pops up
Fill in the data and save & close
Before this commit:
It crashed when evaluating the domain on a field using the field that is not in the form
After this commit:
Subviews share their fields in a special object on the parent record
In our case, the form view checks in that shared resource if the fields it is supposed to initialize
are there.
Hence, this flow doesn't crash anymore
OPW 1837511
closes#24350
The way the calendar view selected its form view was broken for two
reasons:
- any value given in the form_view_id attribute was kept as string,
which means that the string value would be sent to the server, and
this is not good.
- if no value was set, the calendar view then simply did a do_action
with the form view id set to false, which means that the default form
view is used. This is mostly ok, except when we are in the context of
an action with a form view which is not the default one. In that
case, we clearly prefer the form view from the action.
For example, before this commit, the form view in the timesheet
application (community) is not the same as the default form view on
account.analytic.line.
Note that this commit also adds a small tweak to the mock server to
better simulate errors like the web client does (in session.js).
Here is the story of the problem: back in 10.0, everything *seemed*
fine with button rendering except it was very messy duplicated codes.
The system was still not consistent:
-> In Header, button with:
no class -> btn-default
btn-primary -> btn-default btn-primary
oe_highlight -> btn-primary
btn-default -> btn-default
btn-link -> btn-default btn-link
oe_link -> btn-default oe_link
btn-danger -> btn-default btn-danger
some_class -> btn-default some_class
-> Not in header, button with:
no class -> no class
btn-primary -> btn-primary
oe_highlight -> btn-primary
btn-default -> btn-default
btn-link -> btn-link
oe_link -> oe_link
btn-danger -> btn-danger
some_class -> some_class
So, outside the header, the system seemed to not process anything except
transforming the oe_highlight class. In the header, the btn-default was
always added, except if using the oe_highlight class. The style is fine
for those, except for .btn-default.btn-link and .btn-default.oe_link
where the link class has no effect (which is fine as header are not
supposed to contain links).
In 11.0, the new views were introduced alongside websitepocalypse. The
new system led to:
-> In Header, button with:
no class -> btn-default
btn-primary -> btn-default btn-primary
oe_highlight -> btn-default oe_highlight
btn-default -> btn-default
btn-link -> btn-default btn-link
oe_link -> btn-default oe_link
btn-danger -> btn-default btn-danger
some_class -> btn-default some_class
-> Not in header, button with:
no class -> btn-default
btn-primary -> btn-primary
oe_highlight -> oe_highlight
btn-default -> btn-default
btn-link -> btn-link
oe_link -> oe_link
btn-danger -> btn-danger
some_class -> some_class
So, it worsened the header buttons by not processing the oe_highlight
class and adding the btn-default class in all cases. This is even
worse since in 11.0 .btn-default.btn-link do have a specific style and
thus not appear as .btn-default anymore. Those may be invisible "bugs"
though as .btn-link are not supposed to be in header and oe_highlight
is styled correctly in css. For buttons outside the header, a little
processing was added to add "btn-default" class for buttons which did
not specify a class (and oe_highlight is not processed anymore there
too).
In master, with the less2scss task, the system had to change again but
led this time to visible bugs:
-> In Header, button with:
no class -> btn-default
btn-primary -> btn-primary
oe_highlight -> btn-primary
btn-default -> btn-default
btn-link -> btn-link
oe_link -> btn-link
btn-danger -> btn-danger
some_class -> some_class
-> Not in header, button with:
no class -> btn-default
btn-primary -> btn-primary
oe_highlight -> btn-primary
btn-default -> btn-default
btn-link -> btn-link
oe_link -> btn-link
btn-danger -> btn-danger
some_class -> some_class
As you can see, the system is now the same for both header button and
normal buttons. The system is also better for all cases as it produce
only *one* *bootstrap* class for all cases. However, the problematic
case is the last one for header buttons: it did not receive the
btn-default class automatically. Even though this is the API for the
rest of odoo (dialogs, renderButton (old WidgetButton), ...), this is
a problem here as fixing this would require to add the 'btn-default'
class in every view which is using this case.
While waiting for a better solution, this commit is instead forcing
the btn-default class in that header case only (so only when a class
was mentioned but it did not contain any bootstrap btn type class).
So the new system gives:
-> In Header, button with:
no class -> btn-default
btn-primary -> btn-primary
oe_highlight -> btn-primary
btn-default -> btn-default
btn-link -> btn-link
oe_link -> btn-link
btn-danger -> btn-danger
some_class -> btn-default some_class
-> Not in header, button with:
no class -> btn-default
btn-primary -> btn-primary
oe_highlight -> btn-primary
btn-default -> btn-default
btn-link -> btn-link
oe_link -> btn-link
btn-danger -> btn-danger
some_class -> some_class
This commit also adds tests which will prevent the system to change
again without noticing it.
Closes https://github.com/odoo/odoo/pull/24443
Before this, the progressbar values were not updated (both count and progress)
after archiving all the records of a column.
Multiple things have been done here to update it.
Firstly, a optimization had been done to avoid reloading the progressbar when
updating a column ; this optimization was not correct due to this precise use
case. This will update the progressbar.
Secondly, the `aggregateValues` are reset when putting empty groups back in the
datapoint. This attribute is used to compute the counter if a `sum_field` is set
on the progressbar widget. It needs to be reset because the loop that computes
it won't iterate on empty groups.
Eventually, the mockRPC of the progressbar route was not taking the `group_by`
argument into account (probably a typo).
... by setting it 'btn-default', because users hesitate between
that button, and those in the control panel.
Task 32950
Co-authored-by: dbh <dbh@odoo.com>
Co-authored-by: aab-odoo <aab@odoo.com>
Rev. 374af56 changed the way 'button' nodes are rendered in basic
views (form, list, kanban). As a consequence, their 'name'
attribute wasn't transmitted to the produced html elements anymore.
However, this attribute is very convenient to debug views, and to
write selectors in tests. For instance, it broke the test added by
rev. 8d17a2a once forwardported in master.
This commit reverts 1ce5bea.
This feature has been removed in rev. odoo/odoo@e533085 but this commit
reintroduces it. It was considered as "too dangerous" for new users.
Instead of removing the feature, a confirmation request has been added to warn
the user about his potentially harmful action.
The same warning has also been added in List view when archiving records.
Task 60393
Co-authored-by: Mohammed Shekha <msh@openerp.com>
Before this fix, when going on the graph view from the dashboard view (
using the fullscreen button on dashboard), the focus is on the search
input, hitting the tab key creates a crash.
This fix gives a default implementation of giveFocus to the
abstractrenderer so there is no crash.
When doing several grouping quickly (or if the system is slow) on the
pivot view, we may try to display data that now doesn't corresponds to
the current selected groupBys.
This commit ensures that when we load data of the pivot view, we drop
the previous data loading that are currently being carried out.
Without the fix, the added test failed with:
TypeError: Cannot read property 'length' of undefined
because the test does:
- select one level of group by
- select two levels of group by
- resolve the first level of group by
- resolve the second level of group by
Without the fix, we would try to display the data for one level of group
by when the pivot view had two levels selected.
With the fix, displaying the first level of group by was discarded once
a second one was being requested.
opw-1825892
closes#24396
When a user creates a new column in a kanban view, leave the action and
comes back, the order is not preserved. With this commit, we force a
call to resequence to ensure that the order does not change.
The initial rev. odoo/odoo@2d3ecf2 that was supposed to handle this use case
was in fact only dealing with one command as default value for nested x2m, not
more.
The basic model can now handle multiple commands.
Closes#24241
and keep all those filters at last. (PR#20463)
e.g. If field used in color attribute of calendar view does not have value then such sidebar filters will not have string besides filter checkbox
in such cases we should set Undefined string and put all those filters at last in filter list
Currently we can see issue in calendar of manufacturing orders in db with demo data
Related to Issue #1778360
Co-authored-by: Mohammed Shekha <msh@openerp.com>
In some situations, it could happen that the action manager had a
rejected deferred representing the creation of a view, and was blocked
from doing any other interaction with that view.
For example, imagine that a read operation crashes for record 1 on the
model res.partner. If the user is on the kanban view and click on
record 1, there will be an error dialog informing him of the error.
However, if the user clicks then on another record, nothing will happen
because the action manager is blocked (only the form view in this case).
With this commit, whenever the view creation process failed, we also
remove the rejected deferred so the action manager will be allowed to
try again.
this.call('web.Notification', 'notify', params)
Display a notification at the appropriate location, and returns the
reference id to the same widget. Note that this method does not wait
for the appendTo method to complete.
@param {Object} params
@param {string} params.title notification title
@param {string} params.message notification main message
@param {string} params.type 'notification' or 'warning'
@param {boolean} [params.sticky=false] if true, the notification will stay
visible until the user clicks on it.
@param {string} [params.className] className to add on the dom
@param {function} [params.onClose] callback when the user click on the x
or when the notification is auto close (no sticky)
@param {Array<Object>} params.buttons
@param {function} params.buttons[0].click callback on click
@param {Boolean} [params.buttons[0].primary] display the button as primary
@param {string} [params.buttons[0].text] button label
@param {string} [params.buttons[0].icon] font-awsome className or image src
@returns {Number} notification id
this.call('web.Notification', 'close', notificationId)
Here is a scenario that could happen before this commit:
1. go to a list view with more than one record, say 3
2. click on the 3rd record to open the form view
3. the pager says 3/3
4. click on edit button
5. click on discard button
6. the pager says 1/3 (but the record displayed is still the same)
It is often necessary to restore the offset for the sub records, because
the number of pages in a one2many could have changed. However, it is
not a good idea to do that for the main record, since it interferes with
the usual flow of operations.
* test_main_flows
The style of a primary/link button is given by the
'btn-primary'/'btn-link' class. The old 'oe_highlight'/'oe_link'
class should still be supported in views but not rendered in the DOM.
The commit [3079415fb17232117b0d5059a23ae89232eaf5e8] allows the read_group groupby parameter not to be contained in the fields parameter. This makes possible the simplification made here. Similar changes could certainly be applied elsewhere.
Christophe Simonis