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.
The `additional_context` key was missing from the mock function of `load_action`.
This was causing an issue when testing a use case (the context was correctly
passed in Studio).
Url in the web client are supposed to open in a new tab. This was the
way it worked in v10.0 and was lost with the refactoring of the new
views.
We just reintroduce that behaviour with this commit.
Closes github issue #22389
A `default_get` for a x2many field can return a new list of commands for one of
its x2many field, like
[[0, 0, {
'groups_id': [[6, 0, [1, 2, 3]]],
}]]
where [1, 2, 3] is a list of existing ids.
This use case was not correctly handled by the BasicModel because
`_makeDefaultRecord` was not recursive.
Closes#22401
In a grouped Kanban view, when the user clicks on 'Load More' to
load more records of a given column, then opens one of those
records in the form view, and goes back using the breadcrumbs, the
formerly loaded records should be reloaded, so that the user does
not have to click again on 'Load More' to get to the position he
was previously.
This rev. increases the limit of the given column when the user
clicks on 'Load More' to force this behavior.
Before this rev., the group_by specified in the action context was
completely overridden by the group_by specified in the search view,
even if it was []. In other words, it was completely ignored.
Moreover, it was only took into account (before being overridden)
at the first load of a view, not at reload.
With attribute 'on_create="quick_create"' on the arch's root node,
kanban views open the quick create widget in the first column when
the user clicks on 'Create' (in the control panel), if the view
is grouped and if there is at least one column. However, this
column may be folded.
Before this rev., the quick create was inserted into the folded
column, which didn't look amazing. This rev. first toggles the
column before inserting the quick create.
Former code of list controller used the searchView of its parent,
which was the ViewManager. However, this has been changed by rev.
32b8cec53, where the ViewManager was removed, and the list
controller now has the reference of the searchView, so this code
had to be adapted. Tests have been adapted accordingly as well.
The Calendar controller made the assumption that the Dialog widget
opens synchronously, which isn't the case (for the first instance
actually), as it has to load its xml template. So it crashed as
the controller tried to focus the input inside the dialog, before
it was actually rendered.
Before this rev., an error occurred when the user changed a param
of the url when being in a client action. For instance, open
Discuss, go to 'Starred', then click on the 'Back' arrow of the
browser.
The error occurred because the code made the assumption that the
current action was an ir.actions.act_window.
Before this rev., it crashed when the user used the quick create
to create several records (very quickly, or on a slow network),
e.g. on crm.lead (there must be a date field on the kanban record
to reproduce the crash).
The crash occurred when the 'read' RPCs for the created records
return misordered. For instance:
1) 'name_create' record 1 (called and returned)
2) call 'read' for record 1
3) 'name_create' record 2 (called and returned)
4) call 'read' for record 2
5) 'read' for record 2 returns
6) 'read' for record 1 returns
At step 5, the kanban column was updated with the new state, but
this state already contained record 1, which wasn't fetched yet.
This rev. ensures that the created records are added to the state
once they are fetched and ready to be displayed, not before.
We would like to make the "no item found" screens more appealing.
Before this commit, it shows a small help tip in the top-left
corner of the screen, just below the "Create" button.
With this commit, these help tips have been replaced by onboarding
screens, which consist of a picture and some text below, both of which
are horizontally centered.
The texts have been slightly changed, so that they are shorter and clearer.
Considered modules:
(A)
account,
account_asset,
account_budget,
account_test,
account_voucher,
analytic
(B)
barcodes,
base,
base_automation,
board
(C)
calendar,
contacts,
crm
(D)
delivery
(E)
event
(F)
fleet
(G)
gamification,
google_drive
(H)
hr,
hr_attendance,
hr_contract,
hr_expense,
hr_gamification,
hr_holidays,
hr_payroll,
hr_recruitment,
hr_timesheet
(I)
im_livechat
(L)
l10n_fr_sale_closing,
link_tracker,
lunch
(M)
mail,
maintenance,
mass_mailing,
membership,
mrp
(N)
note
(P)
payment,
point_of_sale,
post_mercury,
pos_restaurant,
product,
project,
purchase,
purchase_requisition
(R)
rating,
repair,
resource
(S)
sale,
sale_timesheet,
sales_team,
stock,
stock_account,
stock_landed_costs,
stock_picking_batch,
survey
(U)
utm
(W)
web,
website,
website_blog,
website_customer,
website_event_track,
website_forum,
website_quote,
website_sale,
website_sale_digital,
website_slides
Introduce back part of `formatBinary` that was reverted with 7813a8e7.
When an image is unset, the value was `false` which would end up with a
bin_size of `NaN Bytes` which would end up displaying an error image
with source `data:image/png;base64,NaN Bytes`.
This commit get back a previous behavior so the bin_size when the
attachment does not exist is an empty string (so: '').
opw-805542
closes#22348
When creating a record with many default values, it could happen that
the number of ids returned by the default get (or onchange) exceeds the
limit for the form view.
For example, we can see the issue in the expenses list view. We can
increase the limit in the pager, to a value higher than 40. Then,
clicking on select all, then on 'Submit to manager' in the action menu
will result in a traceback.
The Submit to manager action will trigger a new action with a context key
'active_ids' with a large number of ids. After that, the web client
will execute the server actions, which will return a new action with a
context key 'default_expense_line_ids' with a bunch of ids. Then, it
will attempt to create a form view. This will call the
makeDefaultRecord method in the basic model. This method will generate
the commands for the one2many, for all ids, but will only load the 40
first sub records. After, it will attempt to apply the onchanges, with
some code that assumes that all operations of type 'ADD' correspond to a
local datapoint.
In this commit, we fix the code to properly work with operations of type
ADD with a res_id, but with no id. In that case, we simply generate a
command 'LINK_TO', since the value has not been changed.
opw 804370
When fetching x2manys in a x2many, the basic model did not properly sort
the internal data structure before fetching the data. This is usually
not an issue, except when we have an order which is different from the
order of the res_ids. In that case, it can cause crash in some
conditions, because the results from the fetchx2manybatched were applied
to the wrong datapoint.
To reproduce this issue, some specific conditions needs to be met. I
think that it is easier to refer to the test, instead of trying to
explain that.
In this commit, we properly sort the data at the correct place. Note
that this probably solves a bunch of other related issues, caused by the
fact that the internal structure was corrupted.
Cleaning dead code from these commits that have been reverted:
41fe7f9d1113d026b226b136b4477aaaf9f1f638#diff-54fd886cc58f994ad518ee72df4d3edeR50
2a5488619da22cfd901963dd141e722b195e82ab#diff-f96b339a9374f74489f1f98755e9787bL9253
41fe7f9d1113d026b226b136b4477aaaf9f1f638#diff-86d6d41b5bb7499bf055258d05549d59R3111
With these final changes, we hope to stop the many issues that have occured with
binary fields, from these commits:
255e8ca3d97813a8e71441fe7f9d112a5488619d
What remains is the format of binary fields in list views without widgets,
which shows the bin_size instead of the base64 string representation...
... Rest assured, the computation is in JS, so there are no 'bin_size'
shenaningans!
This rev. is the first part (out of 3) of the refactoring of the
ActionManager and ViewManager layer of the webclient.
The main changes are:
- there is no ViewManager anymore, its work is now handled by the
ActionManager itself, but isolated in a specific file ; this
eases a lot of things, as the breadcrumbs handling for example.
- the ActionManager code is converted to the new coding principles
and guidelines ; mainly, children widgets communicate with it by
triggering events up, and not by function calls anymore.
- the ActionManager layer is now testable, and a lot of tests have
already been written.
- the code in other addons has been adapted consequently.
What's coming next:
- introduce the 'AbstractAction' Widget, and make client actions
and view controllers inherit from it ; this widget will
implement a common API that could be used uniformly by the
ActionManager (e.g. restore(), canBeLeft(), renderButtons(),
getTitle()...).
- move the ControlPanel handling from the ActionManager to the
AbstractAction.
This rev. makes the Rainbowman stop listening to event
'clear_uncommitted_changes' on core.bus, as this event is about to
be removed (in a next commit). It was using it to destroy itself
when such an event was triggered (basically, when the current view
was left).
Instead, we removed the option 'click_close' as, when set to true,
which was the default, the rainbowman was destroyed as soon as the
user clicked outside the raibowman.
The idea is that when we click on either the green, orange or red part
of the progressbar the count on it's right changes to whatever the value
of filtered records should be.
As discussed with fgi and apr mass archiving has been removed in kanban
it has been judged too dangerous for the new users that won't be abble
to easily revert the archived records
Revision on 41fe7f9d11
This commit intended to reduce the network load when reading records with
binary fields. This was made possible by enforcing the contextual key
`bin_size` to be set for records with binary fields.
However, it is causing some issues (see #22222, #22231) which are:
- write with bin_size:true generates a traceback
- read/search_read with bin_size:true breaks some images
on some views (e.g. base.view_partner_form)
Since the problems outweight the gain of these changes, we revert them.
Field widgets now have a key 'context' that let them
extend the context of the dataPoint (e.g. list).
In particular, widgets on binary fields enforce the contextual
item {bin_size: True}, so that the server gives the size of the
binary field as its value, instead of its content.
This change on binary fields reduces network load when accessing
a view with binary fields.
Revert partially 255e8ca3d9
Removed widget 'download_link', as it was a sub-version of widget 'binary':
it did the exact same thing (representation of binary fields by means of a download link)
in a much better-looking way (download icon + filename as text of the download link,
instead of just a download link with text "Download").
Also, the values of binary fields might be already a human-readable binsize (e.g. 2.52 MBs),
instead of its plain textual string representation in base64:
The contextual parameter 'bin_size', when set to true, does not download the data of binary fields.
As a consequence, the server provides the sizes of the binary, instead of their value.
For kanban views with attribute 'on_create="quick_create' set on
their root node, clicking on 'Create' in the control panel should
open the quick create widget in the first column if the view is
grouped and if there is at least one column displayed.
It was working as expected, except when there were no record yet.
This was because the kanban controller used the 'state.count'
attribute of the state (which indicates the total number of records
in the group), whereas it should have used 'state.data.length'
(which is the number of columns).
Before this rev., when quick creating a record in a grouped kanban
view, the quick create widget wasn't automatically re-opened, which
didn't allow the user to quickly create several records in a row
(without clicking each time on the '+').
This desired behavior had been broken by rev. 1d34e26, which aimed
to properly reload the kanban column when a record was created
(e.g. column counter, progress bar...).
When we have a form view with a one2many with an onchange, and with
lines which contains a x2many, and more lines that the limit (so more
than one page), and the read is not in the same order as what is
displayed because we have a widget=handle, then we might have a problem
when we delete one of the lines, if the onchanges tries to change the
x2many.
This is due to the fact that the order of the basicmodel datapoint is
not preserved by the various operations going around. I think that we
may still have a few other issues of this type, but it is actually quite
difficult to establish.
In any case, this situation is now properly handled.
opw 804530
Christophe Simonis