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
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'
When the external button of a many2one field is clicked, the
related record is opened in a dialog. When the user clicks on
'Save' in this dialog, a 'reload' event is triggered to reload the
parent view (the one in the background), as the display name might
have changed.
However, when there is another many2one field in the opened dialog,
and if its external button is clicked, there are 2 opened dialogs,
and thus 3 nested form views. If the user clicks on 'Save' in the
third one, only the direct parent view must be reloaded (the one
in the first dialog).
Before this rev., the 'reload' event wasn't stopPropagated, so it
was handled by the view in the dialog, and by the one in the
background, which produced a crash.
This could happen for instance in Sales Order, edit a sale order
line, click on the external button of the product, in the dialog,
click on the external button of the category, edit some field and
click on 'Save'.
Closes#19052
Before this rev., when the user pressed 'TAB' in the last cell of
the last row of an editable list with attribute create="0", a new
line was added to the list, thus totally ignoring the attribute.
Now, it goes back to the first cell of the first row instead, as it
was before the new views.
Closes#19053
Before this commit, when the shop was in multi images, the main image was not refreshed when changed in the back end.
This was because of the ?unique parameter that was computed on the product variant image. Hence, when the product image changed, the variant image did not, the hash neither, and the image wasn't refreshed
This commit fixes this by adding an option to the qweb.field.image
OPW 765287
closes#19133
Before this rev., when the value of a field with widget='domain'
was false, the search_count RPC made to display the number of
records matching the domain crashed, and the widget displayed that
the domain was invalid. This rev. adds a fallback on [] when the
domain is false.
The problem is present because there are more than 1000 variants for each
product. For display, the price of each product is recalculated (instead
of looking only at the last product)
opw-766897
In grouped list view, when a pager is clicked inside a group, a
'load' event is triggered to reload the data with the new offset.
The event is handled by the list's controller.
However, when the list is in the modal, the event must be stop
propagated by the controller of the modal, so that it doesn't go
up to the controller of the view displayed behind the modal. It
happens for example by reproducing the following steps:
- go to Lunch
- add a line
- search more products
- group by vendor in the modal
- unfold a group
- click on the pager (the group must contain more than 80 records)
Before this rev., it crashed because the controller of the form
view tried to handle the event.
Before this commit, a list containing a handle widget would only display
the handles associated with non-zero integer values. This is due to the
fact that unset fields are hidden in Odoo, while a field is by default
considered 'defined' if its value is truthy.
We override the isSet method for the handle widget to always return
true. This tells the handle widget that the associated integer value is
always defined, thereby ensuring that the handle will always be shown.
The field 'display_name' is automatically added to the list of
fields to fetch when fetching a record. Before this rev., its
value was also sent alongside the fields in the view for onchange
RPCs. It shouldn't: only the fields in the view should be sent.
It produced a weird bug in the res.partner form view: open a
contact (company), add a sub-contact, save -> the display_name of
the contact was then '' (and 'Contacts' was displayed in the
breadcrumbs instead of the display_name of the opened contact).
This is because 'display_name' was sent to the onchange, which
returned '' as value (because of another bug python side). So as
it's value changed, when saving, the new display_name was sent to
the server (even if this field was actually readonly).
Before this rev., we also always fetched 'display_name' when
fetching list of records (read or search_read). This wasn't a bug
per se, but it might be a computed field, and it isn't necessary,
so we stop fetching it in that case if it isn't in the view (as
it was done in saas-15, before the new views).
The problem occurred in form view, in edit mode, when the user
did some changes in the form, and then clicked on 'Log or schedule
an activity'. When validating the activity, the fields mail_activity
and mail_thread were reloaded but all changes were discarded in the
process.
This rev. ensures to reload the requested field without discarding
the changes.
Also add a lost functionality, when coming from payment view, pass account_move_line id to the context so that it is directly opened as a proposition in the reconciliation widget. If a matching line is found for that payment, also propose the matching line.
Since 9.0, the button "Automatic reconciliation" is just used for the reconciliations
of bank statements. But the button appeared in manual reconciliation because the
qweb view "manual_reconciliation" extends "reconciliation".
The button must be invisible in this case because this feature is not implemented.
opw:767309
Before this commit, create a contract which expire in 2 months.
The cron will check all contracts that have a date_end >= tomorrow.
All contract with a end_date will be close.
Now we check all contracts that have a end_date <= yesterday and close it
Before this commit, when the amount of rows was above xls format threshold (>65535), the xlwt library threw an obscure Traceback to the user.
We now test the amount of rows before even calling the library, raising a more helpful message to the user
OPW 767319
closes#19035
A regular employee is allowed to delete an expense reported already
approved. This should not be possible, only an officer could do it.
Fixes#19044
opw-767549
Denis Ledoux