In Calendar views, the displayed period should be written in the
breadcrumbs (e.g. in month mode, '(February 2017)'). This has been
broken by rev. 7b6056a0b5.
Before this commit, phantomjs was crashing when some code manipulates
window.getSelection (such as the composer input in discuss or in the chatter).
This commit lets us mock window.getSelection in tests that need this function
in order to work properly.
Another benefit of this commit is the possibility to simulate the state of
window.getSelection in our tests, which enables tests on the composer that
were not possible before (e.g. making sure that mentions and emojis are
correctly rendered in the input, after the user clicked on them in the dropup
menu or the bottom bar.
Before this rev., an issue occurred on grouped editable list views
that became ungrouped after a reload (i.e. when the grouped part in
the search view was removed). In this scenario, the click handler
outside the list used to leave the edition wasn't bound (because
the list was grouped at the beginning, and thus not editable). So,
it was impossible to leave the edition, even by clicking on 'Save'.
Fixes#23061
From a recent action manager refactoring (https://github.com/odoo/odoo/commit/32b8cec5361174c92c45a4975d4e02f1fb448aa2),
the attribute 'views' in viewOptions is now structured as follow:
viewOptions: {
action: {
views: [{
viewID: 1,
type: 'list',
}],
}
}
instead of this:
viewOptions: {
action: {
views: [[1, 'list']],
}
}
The pivot view was not updated correctly, so now it should be correct.
When executing an act_window action, the ActionManager has to
determine whether or not the first view of the action is a form
view (typically, when this happens, this is also the only view of
the action, and most of the time, it is displayed in a dialog, i.e.
the action's target is 'new'). This ensures that the control panel
is correctly shown/hidden, that form buttons are correctly rendered
and displayed at the right place, and so on.
Before this rev., it uses the view_mode to do that, but there is no
guarantee that the view_mode is even defined (for instance, actions
returned from python methods don't have to define it), so from now
on, we use the 'views' attribute instead, which must always be set.
When onchange RPCs return a command 4 (LINK TO), the res_id of the
record to link is given, and the BasicModel has to read the fields
in the view for that record. When one of those fields is an x2many
(for instance, displayed with widget many2many_tags), the
subrecords in the relation must be read as well (at least their
display_name).
Before this rev., this last part wasn't done by the BasicModel, and
as a consequence, the many2many_tags widget was always empty, even
though there were records in the relation.
Same thing applied to reference fields, but this is way more
uncommon.
This rev. ensures that x2manys and reference fields are correctly
fetched in this scenario.
Before this commit, there is an issue with one2many lists with records that
have been created on 'default_get': if the record has a required field that
is empty, when the user clicks on this empty required field and then somewhere
else, the record is removed from the list.
The cause of this bug is that these records have invalid field changes, here
the required field that is empty. As a consequence, it checks whether the
record is "new", and if so, removes it visually from the editable list.
(Note: a record is "new" when it is not stored in DB).
This behaviour is expected when discarding records created from "Add an item".
However, that is not intended for records that have been created as default
items of the list. These records are still considered as "new" items, because
they are not stored in DB, but they should stay in the list on discard.
This commit solves the issue by making an additional check before assuming
that the record for which we discard changes comes from "Add an item":
if the record in the list has been created before user interacts on the list
(in other words, the record has been added in the list when the user accesses
it), then we should not remove the record from the list, even though the record
has some invalid fields from the savepoint (e.g. empty required).
opw-806650
* account, board, hr_holidays, mail, sale, website_sale
Small fixes on nocontent onboarding screens.
Initial commit: https://github.com/odoo/odoo/commit/a87d761fdbf345ada5dc93e0a686b08a0f5a0417
Details:
- list: centered;
- pivot/graph: centered + empty folder face;
- Dashboard app with nocontent helper;
- Discuss inbox/starred: centered without neutral/smiling faces;
=> no faces because it's too much with animated
rainbow man when emptying the any of the boxes.
- hr_holidays: fixed onboarding screens;
- (technical) dropped obsolete 'o_view_nocontent_container' style;
- manual reconciliation 'nothing to reconcile': centered + inside form sheet;
=> renamed account's o_view_nocontent to o_view_noreconciliation,
so that it doesn't use the style of views.less.
- kanban: nocontent helper above the columns (if any);
- texts "no order to upsell"/"abandonned cart" paragraph split in two.
Create a new column in Project, add a record and then hit 'Archive Records' : a
traceback occurs.
When creating the new column, the `groupedBy` attribute on the datapoint is set
according to the parent list datapoint, which makes no sense as the records are
not grouped inside the column.
The mentioned attribute is now removed as the records cannot be grouped inside
the column.
Server actions return an action to execute, or false. When they
return false, an 'ir.actions.act_window_close' must be executed,
such that the current dialog closes (if any) and mostly, the
'on_close' handler is executed, which ensures for example that the
current view is reloaded.
The case where server actions return false has been broken by rev.
32b8cec53. It produced tracebacks in several models, when clicking
on some actions in the 'Action' dropdown. For instance, in lunch,
go to Configuration > Products, open one in a form view, and click
on 'Lunch: Archive/Restore products' in the Action dropdown.
This commit fixes a problem of usability. By the past if several dialogs were opened
(e.g. after having clicked on several one2manys) and a user would click on a many2one in a dialog,
a new view was charged but the dialog was kept open so that the change was unnoticed.
This behavior has been changed. Now all dialogs are automatically closed in such a situation.
Fix over this commit: https://github.com/odoo/odoo/commit/02ec09cb1c3e2d7bc7968f40c18f2208d7f3f498
In mobile, when discuss is installed, there is a traceback.
This is a consequence on an issue with JS services, where some of them
are not registered in the service provider.
For instance, the webclient (the service provider) was instantiated before
chat_manager (a service), so it was not aware of this service.
To solve this issue, service providers now listen on newly registered services.
Also improving deployment of JS services by not relying on topological sort.
In the tests environmnent, we don't want img and iframe nodes to
perform RPCs when they are inserted into the DOM. For img nodes,
we prefixed the src attribute by '#test: ' as soon as they were
inserted into the DOM. Unfortunately, this didn't work as expected:
an RPC was done to fetch route '/web/tests?' (i.e. the tests page),
because everything after '#' in the url isn't sent to the server.
This rev. completely removes the src attribute of img nodes, and
set a 'data-src' attribute with the original src attribute's value,
so that it can still be checked in the tests.
Tests using this attribute have been adapted accordingly.
In the tests environment, we listen to the 'DOMNodeInserted' event
to remove the src attribute of img and iframe nodes as soon as they
are inserted into the DOM, so that they don't perform RPCs.
However, this listener was bound in the create(Async)View, and
createActionManager helpers only. This rev. moves it to the
addMockEnvironment helper which is more global, and basically used
by all tests.
Moreover, we now listen to the 'DOMNodeInserted' event on the body,
instead of on the widget, as it may happen that some content is
inserted into the DOM outside the widget itself (e.g. dialogs are
appended to the body).
Before this rev., the aggregates values displayed in the footer of
list views were formatted according to the field type, and the
field's widget was ignored, whereas it should be used by default.
For instance, if the 'float_time' widget is set on a float field,
the sum should be formatted as FloatTime as well.
Closes#22724.
Before this rev., the list of selected records wasn't correctly
reset when the list was reloaded (e.g. when coming back using the
breadcrumbs). In the UI, the records weren't selected anymore, but
in javascript, the list of selected records wasn't empty. As a
consequence, the aggregates were wrongly computed, and always
displayed 0.
Closes#22725.
Since the <widget> tag is not used anymore in any of our views, it was
not really properly supported. In particular, the form widget was not
notified when the state of the form view has changed, which makes it
very difficult to actually do any useful work.
With this commit, we make sure that the widget method 'updateState' (if
it exists) is called with the new state whenever it changed.
This should allow developers to do useful work without having to work
around the issue. Note that this is not really a perfect solution, since
the updateState methot may or may not have been implemented.
I think that we need some kind of ViewWidget abstraction, which could be
used to have a better and more complete API for widgets in a basic view.
And AbstractField could inherit from ViewWidget.
Rev. dbdd742 introduced the 'baseMode' parameter of field's nodes
in the BasicRenderer. Its purpose is to encode the generic mode
of the field, regardless of its readonly modifier (i.e. in form
views, the baseMode of all fields is the mode of the renderer and
in list views, the baseMode of all fields is 'readonly', except for
fields in the row being edited, whose baseMode is 'edit').
Unfortunately, when the value of the readonly modifier of a field
was 'readonly', its baseMode was changed from 'edit' to 'readonly',
which shouldn't, as the baseMode's value should not be affected by
the modifiers.
This produced a bug when a field had a readonly modifier, as once
its value became true, the field was rendered in 'readonly', and
whatever the value of the modifier afterwards, it always remained
in 'readonly'.
The rev. ensures that the baseMode is no longer impacted by the
value of the readonly modifier.
Closes#22729
Purpose
=======
Add the possibility to easily attach a document on a record. That could be used for to attach receipts on expense for example.
Specification
=============
Add a new widget (AttachDocument) to allow attach document from mobile/web directly on record form
After attaching document it will call action given on widget, that action will be a method name on given model
Before this rev., it might happen that the parent of BasicModel instances
wasn't correctly set to the Controller instance. It was actually set to the
ActionManager instance, which is never destroyed. So when this happened,
the BasicModel instance wasn't destroyed when it's controller was.
Before this rev., it might happen that the parent of BasicModel instances
wasn't correctly set to the Controller instance. It was actually set to the
ActionManager instance, which is never destroyed. So when this happened,
the BasicModel instance wasn't destroyed when it's controller was.
This is a small correction of odoo/odoo@3aad756 ; a traceback occured when ESC
was pressed in a list view with modifiers.
The `confirmChange` was done on the parent datapoint (of type list) which has no
attribute `evalModifiers`.
`confirmChange` is now called on the record datapoint. Note that for x2m, it
means that all modifiers linked to the parent record won't be re-evaluated (but
this wasn't probably intended as this is a bit overkill).
Closes#22718
A traceback was occuring when downloading the pivot view without data.
The export function expects the attribute `main_row` set on data, which
is defined in `_prepareData`. The latter wasn't called because of the `return`.
Closes#22728
Models concerned are 'ir.ui.view', 'ir.actions.act_window' and
'ir.filters'.
The DataManager's cache is invalidated at each create, update and
unlink operation. This cache stores actions (results of calls to
/web/action/load route), views (results of load_views RPCs) and
filters (fetched alonside views).
This rev. thus spares the user from reloading the webclient after
performing such operations on these models to see the changes in
the interface, as he only has to replay the action to see the
changes.
A traceback occurred on the Intrastat list view (Accounting >
Reporting > Management > Intrastat), when the user clicked on a row
of the list. This action only specifies 2 view modes: list and
kanban. When a record is clicked, the ActionManager tries to open
that record in a form view. As the view isn't in the action, this
request should be ignored. Before this rev., this case wasn't
correctly supported.
The issue adressed by this fix was observed by a problem with a missing
onchange. The situation only happens when we have a one2many in a form
view with an onchange in a field in the list view, and the arch of the
list view is not inline. In that case, the onchange was not properly
triggered.
There are two causes for this bug:
- the BasicModel does not exactly receive the same data when loading a
record in a one2many with a non inline view. More specifically, there
is a confusion with the fields/viewFields in that case. This is done
because the postprocessing of the fields is slightly different when a
sub view is not inline (not ideal situation, we should fix it btw)
- when it construct a subrecord, the BasicModel did not use the correct
fields value, when there was a subview. More specifically, it used
the view.fields (which does not contain onchange informations) instead
of the view.viewFields (which contains processed/view specific
informations, including the onchange data.
This commit fixes the second issue, because this is clearly a bug, and
it actually fixes the problem. The first issue is actually okay,
because we already have a difference of behaviour between the main view
and sub views (in the first case, we have the fieldget information, not
in the second case, so the processing is already a little bit different
anyway)
Notes:
- This bug was discovered only because we added a test in 11.0, which
was forwardported and broke in master. The breakage occured because
of a recent refactoring in master which moved the arch processing
inside the views and out of the data manager.
- It is good that we discovered this bug, but I want to say that it really
sucks that forwardports are done, break the master/saas.11.2, then I
have to fix it in emergency, and it completely break my own
schedule...
wip
wip
Before this commit, it was not possible to display a help message in a
kanban view, if it is grouped. This is an issue, from an onboarding
point of view. Imagine a new user, creating a project. After it
creates a few columns, it is not clear what to do.
With this commit, we display the nocontent help message in a grouped
kanban view, if the user is not currently creating a new column. This
allows the user to focus on its work, by working in phases: first, he is
prompted to create project column, then when he decides that he is done,
the user interface shows the nocontent help message, which guides
her/him to the process of creating a task.
This commit improves the JS code of the mail module,
which comes maily from the new coding guidelines
and the addition of "JS services".
JS services are important objects that do not fit
well in the component tree, such as chat_manager
or ajax.
The benefits of JS services are improved readability
of the code, reduced coupling, and more testable
modules. In particular, discuss was hard to
Summary of the changes:
- ClientAction has been renamed into Discuss
- Clear instantiation of chatManager
- New coding guidelines in most mail modules
- JS Services can interact with each other
- Chat Manager and Window Manager are services
- Window Manager renamed to Chat Window Manager
- bus.bus is now encapsulated in Bus Service (a service)
- The test infrastructure has been tweaked with JS Services
- Chat Mixin has been removed
A future improvement would be to translate some 'trigger' into 'trigger_up'.
From a form view (say Bill of materials)
Edit the form
Click on a bom line
Click on the external button that makes the product form pop up
change the order of suppliers on that product
Before this commit, a JS traceback was raised
This was because the changing object was not present in the localData that the Model object holds
or more accurately, it was not the **right** model object that was targetted
and this was due to the propagation of the resequence event
After this commit, no error is thrown, and the resequencing works as expected
OPW 807196
This commit add a help message in the column to indicate that pressing
escape will discard the current column creation. Note that some JS had
to be added to make the message disappear when the input is no longer
focused. The reason is that the create column widget may still be visible when
the input is no longer focused (for example, because the user clicked on
the fake records, or clicked on the example link)
The goal of this rev. is to improve the user onboarding on the
Project app: when the user creates a new project, he is now guided
to properly configure the stages of its project.
To do so, we added a new mechanism in the Kanban view, allowing to
define examples of processes that can be used in the corresponding
view.
The style of the ColumnQuickCreate widget has also been changed.
Part of task #38740
This rev. improves the QuickCreate widget for grouped Kanban views.
It allows specifying in the Kanban arch a form view xmlid, e.g.:
<kanban quick_create_view="some_form_view_xmlid">
...
</kanban>
When this attribute is set, the referenced form view is loaded and
rendered inside the QuickCreate widget. A real FormView widget is
instantiated, meaning that all form view mechanisms are available
in the QuickCreate (modifiers, default_get, onchanges, widgets...).
Task #27475.
Record quick create can be cancelled by pressing ESC, so this rev.
ensures that the same behavior applies for the column quick create,
for the sake of consistency.
In Less, the size_class XXS is defined and used in media queries.
This rev. adds it in JS for sake of consistency.
Code in addons comparing the size_class needed to be adapted due
to the new XXS size_class.
Moreover, we now use the helper 'config.device.isMobile' everywhere
we should, instead of manually comparing the size_class.
Finally, we changed the way the config.device has to be specified
in the test environment. From now on, only the size_class should be
set, and the isMobile flag is computed automatically.
Christophe Simonis