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
Before this commit, if the user created a line (thanks to the create
button) then deleted it, the rows were in a broken state which made the
list edit the wrong line on line click (it opened the next one). This
was due to row indexes which are kept as data on rows: they were not
updated on row deletion. This commit simplifies the code by getting rid
of this indexes data and instead compute those when necessary.
Since the account is a mandatory field, we raise an clear error is no
account is defined.
This is necessary when running an automatic reconciliation on the POS.
The POS uses a try/except to avoid any error, but in the case of an SQL
error, the cursor is invalidated, so the transaction fails.
opw-741677
Yannick Tivisse