We have a new runbot server which is quite slow. Because of this, it
takes too much time to run this unit test suite (for comparison, one of
the last build by the main runbot takes 126s).
This is necessary for now, until we use chrome headless or something...
Do not prefetch unnecessary fields during the uninstallation of modules.
Previous to this commit, prefetching of unnecessary fields would cause server crashes
on some modules that add a field on ir_model_fields.
i.e. website_form
Before this commit, when trying to edit through the website editor the product image, it was in fact the product variant that we edited.
This commit corrects it and when an image is displayed, the model it comes from is reliable
OPW 767539
closes#19168
Before this commit, a message received through the contact us form did create a Lead, but any notification was impossible (even if a user was a follower of the relevant sales team.
This was because the default sales team is integrated in the values for create in models.py, which mail_thread can't see, but needs in order to notify
This commit corrects the behavior which now converge with standard lead creation by adding the default sales_team earlier in the values for create
OPW 762651
closes#19180
As in a7985a5ab the SO could be in another company than the linked task
and this should not hamper creating / modifying timesheet lines in the
task company that happened since 71bb9a09.
opw-34138
closes#19234
When the last selected category or search criteria in eCommerce had
no products(No product defined), the website category tree was not
clickable.
opw:767021
... sometimes.
When a dialog is destroyed, the last opened dialog (the one which
is just below), if any, is focused. This allows to close it
directly by pressing ESC. For an unknown reason, this was done in
a setTimeout (delay 0).
The problem is that the setTimeout made some JS tests fail
randomly, when a test ending by closing a dialog was executed
right before a test using a many2one inside a dialog. When this
happened, the second test failed sometimes because its dialog was
focused (because of the previous test) while waiting for the
autocomplete dropdown to open, triggering a blur event on the m2o
input, and thus making jquery autocomplete aborting the search,
and the opening of the dropdown.
- Enable several shippers
- Enable Paypal acquier
- Buy a product on the eCommerce, go to payment page
- Change the shipper
While the page is reloading, the user has time to click on the 'Pay Now'
button.
opw-748467
Archived products still published on the website will trigger a
traceback when accessed (the link might still exist in a search engine
results).
opw-767740
Use case:
- a tax of 10%, computation method: percentage of tax included
- a account_reconciliation_model with an amount of 90%
- make a statement of 1.31 (or something weird when it comes to digits)
- reconcile it with a counterpart
- prefill that counterpart with the account_reconciliation just created
- push on reconcile
Before this commit, the amount that was computed was not rounded, resulting in making unbalanced account_moves (by 0.001)
This was invisble since the display of monetary is rounded
After this commit, the rounding is done according to the currency's parameters and produces correct move_lines
OPW 751881
This rev. fixes several issues with the sorting of dataPoints of
type list in the BasicModel.
First, only 'static' lists (i.e. x2many lists) must be sorted
client-side, and results of search_read RPCs must remain unsorted
as they are already retrieved sorted from the server.
Second, editable and non-editable x2many lists don't behave the
same with respect to sorting (we reproduced in this commit the
behavior of saas-15). With editable lists, the edited rows are
unsorted, except if the user explicitely ask for a sort (by
clicking on a column header), until the form view is saved. With
non-editable lists (as for x2many kanban), the sort is performed
directly when a record is created or updated (as the edition is
done from a dialog).
The FieldMany2ManyTagsEmail requires that the records in the
relation have an email address set. However, it didn't take into
account the changes that might have been done on the field's
value (i.e. the check wasn't applied on subrecords that just had
been added to the relation).
Regular employees are added to the timesheets user group
so they can access to the Timesheets modules.
Requiring timesheets users to be HR Officer would almost mean to
require all employees to be HR officer, which is not the case.
The above is the result of the revision
a806f96fa2
Before, the timesheets user group was the
timesheets officer group, and it was the only
group for the module timesheets. There
were no timesheets manager or user group.
This group implied the HR Officer groups,
but it made sense as it was the Timesheets
Officer group.
Now that it is the timesheets user group,
it doesn't make sense to imply
the HR Officer group.
Before this rev., it crashed when the user typed a date (actually,
the last character of a date) in the search view (e.g. in
Accounting > Customer Invoices).
Commit #71bb9a09f is wrong in case you write on several timesheet at the same time.
Self is multi, when you have more than 1 timesheet, we need to check for each,
if one is of type delivery
Complement of commit b0d498c11d
The delivered quantity displayed on the "Delivery Slip" should use the
same UOM than the "Ordered Quantity".
opw-766914
Make sure '.o_invisible_modifier' table-cells are forced back to
`display: table-cell` to keep correct alignement. Indeed using the
`initial` value forced them to `inline` instead (creating some
obvious visual bugs in some cases).
The problem occurred on form views with an x2many field with a
default value containing CREATE commands, i.e. when opening such
a form view in create mode, the x2many field is pre-filled with
some (non-existing yet) subrecords.
If the user then edited those subrecords, and then clicked on
'Save' to create the main record, an 'UPDATE' command was sent
alongside the 'CREATE' one for the x2many, and the id of the
'UPDATE' command was a virtual id (as the subrecord didn't exist
yet), and it crashed.
This could happen in MRP:
- Enable lots in Iventory
- Choose a product which is a component of another (through mrp bom)
- Set this product as tracked by lot
- Set this product inventory quantity to 0
- Create a new manufacturing order for the product for which it is a
component
- Click on "Check Availability"
- click on Produce: the many2many already contains a subrecord
- edit the lot field of that subrecord
- click on 'Record Production'
Géry Debongnie