One could set the attribute `default_order` in the view arch
(like 'name,id desc'). The records should then be sorted accordingly.
This feature was not implemented in the new views.
This attribute should work on both basic views and embedded views (x2many).
The former uses the `sort` argument in `search_read` while the latter is
sorted client-side.
There is however a potential issue with the latter: as the order is done
client-side with records received by the server, if there are more records
than the limit, the server will send records without any order. The client
side order will thus be done on a fraction of the records.
This attribute is used to determine one can create a new column in
the kanban view.
Before this commit, it was always true and not specified in the
controller `activeActions` (which was causing a bug where the
no content helper was displayed instead of the column quick create).
The controller was also always initiated with false so the column was
only available after an update.
The third argument of kanban_image should be the id of the record and not the
image `raw_value`.
In this case, we want to display the image field of the current model.
The commit e07f27d has wrongly changed the fallback for one2many raw_value from
an empty array to `false`. This modification brokes a lot of templates where we
assume that the value is always an array.
This commit restores the previous behavior with the fallback on [].
The template `wizard_checkout` uses the `website_sale_order` to render the checkout process pages
But this values isn't passed to the template on these staps:
- /shop/checkout/
- /shop/address/
Purpose
=======
Address management is not clear. If you use the eCommerce, you can set 2 different addresses (billing / shipping) in the checkout process while the related access right group is not activated (group_sale_delivery_address). So you don't see such dates in the backend, which leads to potential conflicts with customer (if the delivery address is different).
Functional spec
===============
- Hide shipping stuff in checkout if option is not activated:
- When eCommerce is installed, group_sale_delivery_address should be activated automatically.
- If you uncheck it from user access (already it is disable in sale settings) , it has to disappear in both the bakend AND the frontend.
With this commit, we try to improve the way navigation is done in the
list view. In particular, we want to make sure that pressing TAB on the
last editable cell move the cursor to the next line (and create a new
line if necessary).
Also, we add a few tests for keyboard navigation (it was almost not
tested before this commit, and while working on this commit, it was
broken at some point).
Graph tooltips (found in accounts and sale/crm's dahsboards) are now
rendering a custom template in order to display more relevant and
coherent information about the graph.
When we unselect a line in a one2many list, we ask for all fields to
commit their changes (because many fields are debounced, so we may not
know their current last value). This is good, except that it could
trigger an extra field change event, which may in turn trigger a second
onchange.
We solve this issue by improving the _setValue method and delegating the
comparison to a new _isSameValue method.
It is particularly relevant for field types such as integer, which are not
stored as a string.
When multiple clicking fast (and with the server not too fast), we could
end up with an error (eg. "Cannot read property 'controller' of null").
Something has been done previously to improve this when switching
between views in: fc8a4b5e. This commit do something similar to limit
multiple click on kanban records (doing it as in 26f91c429).
note: master equivalent of 8f1cc2fa (which is for 10.0 up to saas-15)
opw-705329
closes#16775
This widget is supposed to be used in list views only (it allows
to re-order the rows by drag-and-dropping them).
Since the new views, the field widgets are shared between all
views, whereas before, each view had its own list of widgets
(and the handle widget was a list view widget).
So if one specifies widget='handle' in a form view, the handle
widget will now be instantiated, whereas before it was ignored.
This rev. fixes two templates making use of the handle widget in
form views.
Suppose that there is a many2many (list) field in a form view,
and there is a many2many (e.g. many2many_tags) field inside the
list.
In edit mode, if the user adds a record in the relation, this
record and its relational data should be fetched.
Before this rev., the relational data wasn't fetched, so the
many2many_tags couldn't be displayed correctly.
* added some accounts, cash based taxes, DOM-TOM country group...
* improved sale/purchase journal creation for french companies by making sure they have a dedicated sequence for refunds
Steps to reproduce:
1. Create two products A and B that require a serial number
2. Create a product C with no trcking
3. Create a BOM for a A with two components B an C
4. Create a MO for A with qty > 1
5. Check availabiltity and produce the first A
6. Record the SN for the first assembly
Bug: When producing the second assembly, it was not possible to
record the SN for the components.
opw:741316
Problem: the update of custom models/fields is not fully transactional, and may
potentially lead to an inconsistent database. An other problem is creating two
custom fields by writing on a model: if the second one fails, the first one has
been committed without notice. Retrying the request will give an unexpected
error (duplicate field name).
Solution: never commit in the middle of a request. If the changes have an
impact on the registry, then mark it as invalid (with a new flag), and signal
registry invalidation after everything has been committed. If the request
fails, reset the registry. Both registry and cache invalidation are handled
the same way.
When multiple clicking fast (and with the server not too fast), we could
end up with an error (eg. "Cannot read property 'controller' of null").
Something has been done previously to improve this when switching
between views in: fc8a4b5e. This commit do something similar to limit
multiple click on kanban records (doing it as in 26f91c429).
opw-705329
closes#16698
Before this commit, it was possible to edit something in an editable
list view, then press the DOWN key, then enter some other values. With
the DOWN key, the focus is supposed to move to the line below, so we
save the current line, in the current state. This means that the edit
coming after are simply lost (well, just not saved nor displayed).
What this commit does is simply disable all control elements in that
situation. This prevents uncomfortable situations from occurring.
Before this commit, the filtering brought by commit ca989b6 did not work when
no email_to was present. Which is the case for mass-mailings based on
res.partner records.
OPW 728321
Closes#16745
Issue: 741582
This bug happens when you click multiple time quickly on 'run scheduler' button
or if you call 'run reordering rules' and then 'run scheduler' rapidly
It could create duplicate PO or MO.
This happens because the run_scheduler function free the lock while it should
not. ProcurementSudo was created with the old cursor that contains the lock and
the record set that search returns also contains this cursor. The run will call the record set with the bad cursor and commit the lock instead of the wanted
behavior.
This commit creates the ProcurementSudo with the new cursor that does not
contains the lock.
Before this commit, when a kanban view was grouped by a selection field, the
column were named with the raw value of the selection instead of the display
string.
Furthermore, fix the fact that when the column title was 0 or False,
'undefined' was displayed instead.
- Fix the toolbar behaviour since there is no more dataset in the widget.
- Improve the communication beetwen the controller and the toolbar.
- Move the code linked to the document upload in the right file.
- Adapt the tests to mock the search_read done by ´document´ addon
- Adapt the mock server to be able to give a custom toolbar action
- Create 5 PO with 40 lines each for Partner A
- Create an invoice
- Add each PO thanks to the field "Add Purchase Order"
The process takes more and more time for each PO.
Most of the time is spent in the recomputation of the secondary fields
(in the `onchange` method of "models.py"). The root cause is the cache
invalidation due to the relational fields recomputed as superuser by
default.
opw-740485
This commit proposes to allow to automatically generate timesheet lines
when an employee is on leaves. Project and task used for timesheeting
is globally configured on the company. Holidays type choose whether to
generate timesheets or not and take the company default configuration.
When an HR officer validates a leave request, analytic lines will be
generated for each day off. The unit amount will be based on the working
calendar of the employee taking the leave. Generated timesheet lines are
attached to the project and task configured on the holidays type.
Configuring timesheet lines generation at holiday type level allows to
tune the use of leave requests. You may have for example "home working"
holiday type that should not generate timesheets while "legal leaves"
should.
Before this commit, when the user modified the dashboard, it was not always visible without refreshing the web client
For example, display the current dashboard, then go to another view and add an extra view in the dashboard, then go back to the dashboard.
The reason is that the dashboard layout is actually stored in the arch of a form view, and that arch is cached by the data manager.
This is why each change to the dashboard arch requires that we clear the cache.
OPW 740739
Closes#16691
Martin Geubelle