There is a bit of magic in the kanban with many2many: the widget many2many_tags
is automatically set on many2many fields.
Since the previous commit, the `color_field` needs to be explicitly stated
in the options for the tags to be colored.
In kanban views where tags were previously colored, we thus have specified the
widget and the color option.
Since the previous commit, the `color_field` needs to be explicitly stated
in the options for the tags to be colored.
The previous behaviour (always read the field `color`) was leading to server
warnings if the field was not present on the comodel.
Thìs commit set the `color_field´ for every many2many_tags on fields that have
a `color` field on the comodel.
In Python 3:
* various builtins and dict methods were changed to return
view/iterable objects rather than lists
* and the separate Python 2 view/iterable builtins and methods were
removed altogether
This is problematic when using these items as list (which the happens
repeatedly in Odoo), but more viciously when iterating *multiple times*
over them (which also happens, which I've messed up multiple times while
writing this, and which is a pain to debug even when you've just created
the issue).
Convert all code using these to semantics-matching cross-version
helper functions to get the LCD behaviour between P2 and P3, and
forbid the builtins via lint.
issue #8530
- Default gender is male
- Default marital status is single
- Move some fields from the contract to the employee (permit number, visa number, visa expiration date)
Currently applying a color to a kanban item applies it to the whole
card. This creates usability issues as the content is not dynamically
updated to match the chosen color.
This commit proposes to apply the color only to the header and let the
card content standard. It helps designing cards that are always usable
and readable.
It is currently not clear what adresses and tabs in employee form view
are about, especially concerning public, work and private data. This task
improves the labeling of the home address (private one) and public and
personal tabs (work and private actually).
Extract setting the employee's parent when changing the department manager.
This allows customizing the way the managers are handled easily in extension
modules.
Closes#16490
This commit introduce a full redesign of all JS views. We started
basically from scratch. The goal was to unify all the various views
under a common framework, to make them testable, to make then usable in
different conditions (in studio, or in the frontend), and to make our
lives easier.
Some important points are:
- we introduced new coding guidelines (camelCase, 80 chars width, ...)
- we have a brand new testing framework (still QUnit based)
- kanban view moved to the web addon
- calendar view (formerly web_calender) moved to web as well
- the tree view was removed
- all new code should be documented
We hope that this code is the start of a new era for the Odoo web
client, we want to have a high quality codebase, well documented, well
tested, well designed.
Work done by the framework team: mostly aab, ged, chm, dmo, qsm
This commit introduces a new widget specific to employees. It is used
to display an org chart centered on the current displayed employee.
Two levels of managers as well as subordinates are displayed.
It is contained in its own module and its installation is available from
hr settings.
Thanks to Stefano Rigano <sri@odoo.com> (@stefanorigano) for design and UX
implementation.
No technical or functional change. Only reorganizing fields to better
understand the model. Future commits will change a few fields in this
model and this commit prepares it by classifying a bit them.
Currently check of alias security is directly embedded in mail.thread
routing method. In this commit we move this check in the mail.alias.mixin
class itself. Doing this allows models to extend or improve the behavior
depending on how inheriting models use aliases.
As message_post is defined on mail.thread abstract class its api.returns
is not automatically added on overridden versions of the method. This
commit add missing api.returns on all overrides of the method.
Those fields are never used anywhere. Moreover attendance module can be
used to track employee log in / log out and compute its attendances.
Let us therefore remove those fields.
The bank account didn't appear when selecting SEPA credit transfer in ACCOUNTING>PURCHASE>PAYMENTS
to refund an employee. The bank account is taken from partner set with the field home_address_id.
So the account holder have to be set on the bank_account_id of the employee with the home_address_id.
opw:702881
Rev. 36f6f26 changed the format of the returned list of employees.
Javascript is expecting an array containing the array of employees,
each employee being a dict with keys id, name, email. But from rev.
36f6f26, it returned an array of employees, themselves represented
by an array containing their id, name and email.
As the format changed, the Javascript mention mechanism never used
the prefetched employees, and always fallbacked on an RPC to fetch
suggestions amongs all partners.
Christophe Simonis