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.
hr.recruitment.report is not necessary anymore as it can be replaced by
classic pivot and graph views on hr.applicant model.
Applicant has been slighty modified to ease reporting
* adding group_operator average on both days to computation;
* adding group_operator average on working hours computation;
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
When a message is posted through the chatter and creates a new partner
the issue is now updated so that the partner field is correctly set to
the newly-created partner.
Chatter on issue now uses the reload option so that the view is reloaded
after posting a message. The user therefore sees that the record has been
updated accordingly.
This commit removes document count on project kanban view. Indeed it
does not add much valuable information and bloats the kanban cards.
In order to keep the kanban card order, it was required to adapt all
inherited views. The order is 'task', 'issue', 'rating', 'timesheet'
and 'forecast'.
It also uses a read_group to better compute task count, by the way.
* Remove filter tag
* Use color attribute on the view who add a filter/legend
* Filter is automatically added when 'avatar_field' option is used on a
field tag, and the default template display the avatar.
* Can overwrite the template (add tag template who contains qweb with
<t t-name="calendar-box">...</t>
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
Activity types are currently hard to find and define. In this commit we
add a menu under project configuration to access generic or project
related activity types (task, issue).
This commit is an improvement considered as an usability fix, therefore
targeting stable version.
The goal is to prepare the removal of
'portal' module.
- demo portal user is moved into base
- 'is_portal' field on res.group too
- remaining security rule are moved to base too
- mail template is moved to website_portal
Currently timezones were not or incorrectly taken into account in resource
computation. Indeed complexity comes from attendances being expressed in
naive timezones valid for all users, whereas dates and leaves are computed
into UTC. Computation should always be done in user timezone so that there
are no overlapping days and all time intervals are correctly computed.
A new timezone field is added on leaves to know in which timezone they
were originally encoded. Indeed putting them in naive user timezone
require its original timezone, not the current user timezone, as those
can be different.
This commit also contains code cleaning in resource to be a bit more
pythonic, simplify method parameters and offer a more simple api to
other modules.
Eventually code field is removed on resource as it is not really necessary
for resources. It is explicitly added on workcenter model who use it.
Old methods are still present since a long time and are deprecated since
saas-3. This compatibility layer adds unnecessary complexity to the module
API. Those methods should now be removed. Some renaming is also performed
to ease resource api understanding, notably to better differentiate
internal methods from other methods.
All addons are updated accordingly.
Companies now always have a default calendar configured. All methods in
resource module should therefore be able to use a real resource.calendar.
This commit removes the computation based on a pseudo 8-17 calendar
given as weird method parameters.
Project is updated in order to use the company calendar by default.
Previous commit was cleaning the orphan and fuzzy translations of all main translations.
This commit does the same for all regional languages (that are not on Transifex).
To keep these files small, keep only the translated strings.
Fixes#14937
Some languages were published on Transifex in v9 but no longer in v10.
These languages were still using the outdated .po files
In some of these po, there were some fuzzy translations that were incorrect
(e.g. 'POS Order %s' - 'Kassa ostud', missing '%s')
These were not erased as still using the old translations.
Regenerate a correct .po file based on the new .pot and remove fuzzy
translations.
Fixes similar issue than raised at #14937
The depends for an issue inactivity_days expects a set create_date but
this may not be the case (when creating the record for example with the
field create_date in the form view).
opw-702532
Christophe Simonis