When a payment method is created, the field check_sequence_id is defined
only at the time of the create (_create_check_sequence). This method
fails since the check_sequence_id is not created yet.
X Application(s) becomes just Application(s) on the kanban card in order
to be coherent with other kanban views
When computing a job documents, do not include documents from already
hired employees, only applicants in the pipe.
The settings views are now using radio buttons which are using labels.
These were set to bold by bootstrap. Now force font-weight normal for
labels which are not labels inside an oe_form_group_cell_label (field
main label).
Writing frequently to master data, and particularly to res.users
records is dangerous because it can temporarily delay/abort
concurrent transactions due to FK locking/serializability
heuristics. (Even with PostgreSQL 9.3+)
The `login_date` field updated when a user is authentiocated
is still useful but better handled in a separate table that
exclusively receives independent INSERTs (no UPDATE/DELETE).
This minimizes the chances of transactional conflicts.
This commit moves the login_date info into a separate
`res.users.log` table for this purpose, replacing it
with a related field. The user and login date info are
automatically handled by the magical fields (create_uid,
create_date) in `res.users.log`.
The related field must not be stored because that would
create the same problems as the original field.
In order to cleanup redundant entries in res.users.log
the 'auto-vacuum' cron job used for TransientModels was
extended to be a generic "internal data vacuum cleaner",
and now takes care of this as well.
The code for updating last login and vacuuming was split
up into smaller methods to make extensions easier.
Fixes#8585Fixes#8590
Like view manager containers, client action containers needed the
overflow:auto property to compute their correct height inside their
flex context. This also allows client action as the reconcilation in
accounting to not care about their height.
The calendar has now a minimum height so that it appears bigger in
mobile. In mobile the height cannot be computed to maximum because
the webclient has not 100% fixed height. The height has been set
so that in appears maximum on a 720p android mobile on chrome at
the time of this commit.
The calendar is now also resizing itself correctly after a window
resize.
Before this commit, it was impossible to scroll the calendar
horizontally if needed. Notice that the solution breaks the full
calendar layout and require JS scrolling so that the events are
still positionned correctly.
In this test, we set the incoming picking type not
to require any lots. The outgoing picking requires lots
and should convert the stock without lot into stock with lot.
When a new field has to be computed for the first time on existing records,
mark that field as todo, invalidate it in cache, and perform all recomputations
at once at the very end.
The display of next actions has been slightly cleaned. Indeed some links were
displayed only in edit mode, and the order was strange.
Also moved code beloging to crm.team into the right file instead of having
2 overrides in the same module. Also cleaned its code.
Instead of using 2 security groups to make sure
internal pickings are not shown in the dashboard
when not in multiple locations,
picking types are deactivated when the warehouse
is one step in/out and not in multiple locations.
That way it will work the same for other kanban views.
The colors of the kanban view are also changed.
Useless now that rev f26988c allows the use of asset.
Also, it was partly used to retrieve the content of the
`report.style` template that was removed by rev c9492f8.
The preferred way to add local style and stylesheets is to add them
directly in the assets.
- now possible to archive lost reasons. Indeed some reasons may become
unrelevant after some time.
- updated access rights on lost reasons: manager can create / update them
salesmen can only use them
- add archived filter
Since commit 78cc0b95f4, there was no more
way to invoice the actual price of a shipping (after the transfer).
In order to make that available again, we introduce a new field on the
sale order. This field automatically detects whether a sale order
contains a "delivery" line or not, at sale order confirmation
(action_confirm).
When the delivery order is processed, the actual shipping cost is thus
repercuted on the sale order if and only if the shipping price was not
"forced" at the sale order confirmation.
(and a few refactoring to avoid copy-pasting code lines)