The previous code used to create its own args array
for the search_read method, replacing the one that
was originally given to it.
This lead to silent errors since positional arguments
to this function were completely ignored in the case
of search_read.
I took this commit as an opportunity to improve a
bit on the current state of these rpc helpers.
Namely, the basic args/kwargs priority is the following (top-to-bottom):
- kwargs defined in the rpc call
- kwargs defined in the kwargs key of the params kwarg of the rpc call
- positional arguments are passed as is
For read_group and search_read methods, the priority is the following:
- kwargs defined in the rpc call
- kwargs defined in the params kwarg to the rpc call
- kwargs defined in the kwargs key of the params kwarg of the rpc call
- positional arguments are passed as is
For the /web/dataset/search_read controller, only the params kwarg is
supported, resulting in the following priority:
- kwargs defined in the rpc call
- kwargs defined in the params kwarg to the rpc call
- positional arguments are passed as is
If both a kwargs and a positional arg is given for the same parameter,
it will be sent as is to the server which will crash with a typical
"got multiple values for keyword argument" TypeError. However, in the
MockServer however, we give priority to kwargs over args in this case.
Please note that I also chose to remove unnecessary default values so
that the ones actually used are the ones from the server, not the ones
that were duplicating those in the rpc js file.
Widgets which manipulates their dom in _renderEdit were left out
from the previous implementation since this processing was done
only once when the widget is rendered the first time. If the
widget regenerates a new input upon reset for example, then it
would lack the idForLabel.
When enterprise is installed, the rendering of these widgets on
extra small screens is different, thus breaking these tests. We
need to force the test to run on normal screens.
- Some fields were simply missing on templates, making impossible to give them a value on chart template installation.
- Added a real link between account.reconcile.model.template and its chart template instead of using account_id.chart_template_id
- Added tests for checking the consistency of those objects in the future.
Before this commit, when we moved from one line to the next, we did not
wait for the unselectRow to end. This means that if the read (from the
unselect row) completes after the default_get, the list renderer was not
in a coherent state (currentRow was set to null), which could (and did)
cause a crash.
This was found by pressing the TAB key a few times, and editing some
values.
Also, we slightly improved the logging in the mock server. Before this,
the responses from the mock server did not show from which route it came
from. But in this test, we specifically make sure that the rpcs
complete in a different order, so it was not really optimal.
Since the new views, the editable list view lost some behaviors. These
behaviors were indeed implemented in the form controller/renderer but
as the new editable list view does not use an inline form view, these
behaviors had to be implemented in the basic controller/renderer.
For this to work, the list editable renderer had to be changed as it
was doing work that should be done by the controller.
The problem is even more complex because the x2m fields are using a
list renderer but not a list controller. So moving code from the
renderer to the controller obviously broke the x2m fields. Right now,
the problem is solved by catching renderer events and forwarding new
ones to the form controller (which handles the x2m specifically).
The initial goal of this commit was to share the validation of records
on save. Indeed, the fields were marked as invalid in the form view but
not in the list view. Also, before the new views, the editable list
view had different behaviors if they were used for a x2m field or not.
As these behaviors are making sense, this commit tries to restore them.
Basically, what we want is:
- When a record is saved (form view save or list view line leaving),
the invalid fields are marked (in red), the names of the related fields
are notified to the user and the record is not left.
- When a record is discarded (form view discard or list view discard),
the user is asked to confirm if the record is dirty before making the
record readonly.
- When a record is discarded, if the record is a new one, then the
record should be abandoned (removed as if never existed). In the form
view this induces to go back in the history and in the list view, to
remove a row.
- For x2m fields, the notification of invalid fields is not triggered
but the user is instead asked if he wants to discard the changes made
to the row (indeed, this replaces the list "Discard" button, as non
existent for x2m lists).
- ...
Saving, discarding, marking the fields as invalid and other behaviors
are thus now shared behavior of basic views.
The management of the dirty flag has also been moved to the model
as it was handle by the controller for the form view but by the
renderer for the list view. Now this flag is directly managed in the
basic model (the model can have changes thanks to the `_changes`
property but not be dirty (this is the case for creations)).
This change however created a problem. The view manager is currently
keeping asking if there are changes to discard at each action which
might lead to leave a dirty record (appswitcher / url change / ...).
It however did not discard anything as leaving if the user is ok with
it will lead to an implicit discard. However, as the view manager might
ask for this discard multiple times by second, the controller was
marking the record as not dirty the first time but without discarding
the changes. This is more complex to do now, as the dirty state is
part of the model and that the renderer should match the model data.
To solve this problem, the view manager now actually discard changes
explicitely when asked to. Even though this had been optimized to not
cause any rerender in some cases where it is not needed, this could
cause some performance decreasing. However, this makes some cases more
logical (opening the app switcher on a dirty form view then going back
to the form view by hitting the "go back" button left the form view
untouched although the user asked to discard it). This solution will
be improved with the view manager refactoring.
This commit is also making use of the `commitChanges` system which had
been implemented for HTML fields. Indeed, these fields cannot know
about all of their changes, so when hitting the save button, we asked
those fields to commit their value. Using this system is a great way
to make the `isValid` method of x2m fields synchronous. Indeed, before
this commit, the method was sometimes asking the user if he wants to
discard an invalid line before save. That case can be handled by the
x2m `commitChanges` method: we consider that saving the lines of x2m is
an operation that has to be done before considering the save, so we ask
all the x2m fields to do so at that time. Also, the system was broken
since a recent commit: we indeed protected the changes - save order
with a mutex but unfortunately, the `commitChanges` method was part of
the save and the changes it triggered were not able to be considered
because of this mutex. This had not been detected by tests as there is
not current way to test html fields.
- fix access rights issue when viewing events:
Previously, with an attendee token, you could have access
to all events by simply changing the id in the url.
Now an extra verification is made to check if the attendee is
related to the event.
- fix small mail template display issue
- raise sequence of "Actions" submenu in the technical settings
(to allow insertion of submenus between Email and Actions)
The FieldTimezoneMismatch was redone, but an error was done after the
last code review. With this commit, we fix the mistake (a function is
properly called) and improve the test to make sure we catch such a
regression later.
Trash icon does not take account of the option on the tree tag
Before this fix: The delete option on the tree tag is not taken
into account in the widget
Before this rev., there was a traceback when grouping a list view
by a, e.g., many2one field, and then by a selection field. It
crashed when formatting the title of the group, because the type
of the grouped field was incorrectly determined (it selected the
type of the inner grouping level, not the current one). For
instance, it tried to format a many2one like if it was a selection.
When switching between records, the active tab of the previous
record is made active on the new record.
However, before this rev., this was done without checking that
this tab is still visible on the new record (there may be an
invisible attrs that makes it invisible), so it happened that
the active tab was actually invisible.
This was for instance the case when switching between stock
pickings, as the first tab ('Operations') is sometimes hidden.
This commit actually fixes a few problems:
1. the _visitChildren method in the basic model was not following the
changes, only the data, so it was not correct (for example, the isDirty
method was wrong for relational data, when no other change was done)
2. new records could not be discarded, because they had no data in their
data key. What we do here is to add a savePoint, so it is safe to
restore them (it caused a crash)
3. the save method was not properly following children when it was
called with the option savePoint=true
4. when the user tried to discard a form view, in an action with only a
form view, it was redirected to the previous url (via the history_back
action), instead of simply discarding the current form view
We changed the field on which 'My requests' filter is applied from
'owner_user_id' to 'technician_user_id' because a normal employee who
has requests only see the ones he owns, and the responsible of
requests should be able to easily see the ones he's assigned to.
As the reporting on maintenances by team is already available through a
filter on requests and just show the pivot view, we added the the menu
item 'Reporting' and a link in kaban record of maintenance team to
redirect to the pivot view.
This commit modify the kanban card for maintenance requests/team:
For maintenance request:
Kanban view:
- Move the star priority from right to left
- Add the text 'request by' before the field owner_user_id
- Add the field for the technician with the text 'responsible'
- The image is the responsible and not the owner anymore
Forw view:
- Change the label for name from 'Subject' to 'Name'
- Change the placeholder for name from 'Maintenance Subject' to 'Maintenance Request'
- Request date field is read only and set to the date where the request is created
- Close date is read only and set when the request is in a done state
- Category is invisible if the related equipment has no category.
- Disable creation and opening maintenance team from the form view.
For maintenance team (dashboard):
- To Do button filter requests on their state
- Team name link to maintenance requests belonging to the corresponding team
Technically, there are just basic changes in the view.
This commit changes the maintenance team:
-In the form view -> replace Category name by Team name
-Replace the partner by a many2many with users
-Display the from view instead of editable list view of teams
In the model, the partner field is replaced by member_ids.
However this field is never used except in the form view.
The feature added is a count of todo request that has no schedule date.
It will also add a link in the team dashboard that redirect to all
mainenance requests without a scheduled date.
The count is computed in the existing function '_compute_todo_requests'.
It will count requests that are not done and have no scheduled date.
This commit also modify the view and add the default filter 'unscheduled'
(created by a previous commit) for the action
'hr_equipment_todo_request_action_from_dashboard' which opens the maintenance
request for the active team.
This commit add the following feature :
Add the responsible and the owner of the maintenance request as
follower.
This commit creates a new method that adds as follower the responsible and/or
the owner. This method is triggered in the create and in the write if they
are modified.
It will not remove old responsible or owner from the chatter.
When fetching record, `bin_size` needs to be passed in the context
to notify the server to send the `bin_size` and not the whole base64
of binary fields.
Before this rev., if concurrent calls to 'read_follower' were
performed, it might happen that the read followers appearead twice
in the follower dropdown.
This was for example the case when validating an invoice: the
customer was listed twice as follower.
Note: in this particular case, the record shouldn't be reloaded
twice: this is another bug to adress.
Moves back the mobile rendering part of the FieldStatus to
enterprise, alongside all other tweaks to improve the UX in mobile.
This part had been moved to community inadvertendly in the new
views branch.
This commit proposes to store the complete name of a product category.
It is formatted like parent.name / name, recursively. Storing it and
using it as a rec_name allows to search products belonging to a category
or its child categories without having to rely on a strange hack of
name_get and name_search.
Searching on products having a category containing "all" will get results
from "all" category as well as "all / saleable", and so on.
The sequence set by function next_by_code for a company must be
either defined for this company or witn company specified on it.
In the other cases, the sequence "NEW" is used.
With courtesy of @odony
opw:728554
Critical improvement,
`:)` was making a laughing guy that could be considered as mockery.
This smiley is way more friendly and should improve support feedback by at
least an order of magnitude better, maybe two.
Closes#16672