Refactor resource calendar and resource mixin:
- add a required timezone field on models 'resource.calendar' and 'resource.resource';
- resource calendar attendances are now computed in the timezone of the resource
or the calendar;
- improve API of 'resource.calendar' and 'resource.mixin';
- avoid other modules from using the implementation methods of 'resource.calendar';
- refactor implementation of 'resource.calendar' to make it more efficient.
a696f84f1f adds a few extra fields to the
Private information tab of the employee form. As a result, HR personnel
and employees could reasonably expect these fields to be protected in
the same manner as the other private fields. Make it so.
Cherry-Pick of odoo/enterprise@533db05b5eFixes#18610
Add some private information on the employees like:
- Certificate: Bachelor, Master, Other
- Place/Date of birth
- KM Home/Work
- Emergency Number/Contact
- ...
Also move some already existing private information from hr_contract to hr.
The reified view on the res users will be dropped in the following commit.
The previous commit adds support to define each group as a computed field on the res users.
This commit defines:
- A boolean field for each 'isolated' res.group, i.e. a group in the hidden category.
- A selection field for each 'Application' res.group, i.e. a group in a application category.
Example:
- The group to manage pricelist in sales becomes a boolean field
- The groups project user/manager become a selection field
This commit refactors mail.thread message_subscribe method. It is done for two
purposes. First one is to optimize performance by using the new followers
computation methods introduced recently. Second purpose is to clean the API
of message_subscribe to make it simpler to use.
This commit splits message_subscribe in two main parts :
* _message_subscribe is a private method calling the follower new
subscription methods and updating the record set;
* message_subscribe is a public wrapper on _message_subscribe that adds
access rights checks;
Simplification comes by removing message_subscribe_users that was a
shortcut to message_subscribe. Having a method to subscribe partners and
channels is sufficient as we would like to avoid bloating the public API
of mail.thread. A force parameter is also removed from message_subscribe
as this implementation detail can be induced in the computation.
Various addons using the removed methods are updated in order to use the new
subscription API. They have the same functional behavior.
This commit has a great impact when subscribing several followers. In a more
general way all code using message_post is also optimized as posting a message
generally implies subscribing followers. It also improves activity use as
posting a message and subscribing new followers are common process in
activities.
Commit 78ac6de52d refactored methods checking alias security on the
routing found for a given destination address. Indeed if a routing is found
linked to an alias a security check is performed according to the restriction
defined on the alias itself.
HR module adds the 'employees only' restriction. A bug has been introduced
in the mentioned commit concerning employees-based aliases. Indeed a condition
on having a recordset has been added (self.ids, changed to record.ids at
20d8025036). This condition is actually not necessary as checking the
email author is linked to an existing employee has nothing to do with the
alias being linked to a record or creating new record.
This may causes issues notably using employees-restricted aliases in
expense application. Indeed you could use aliases to create new expenses
for employees and you could have issues with this condition.
This commit is linked to task ID 1829860 and ID 35093. Closes#22960 .
Purpose
=======
Currently both 'Married' and 'Legal Cohabitant' are considered as the same thing.
We should separate these 2 marital status to have a more accurate information.
HR employee model automatically adds the employee's user as follower of
its own employee profile. It has been done at 8ab3e5d2a1 probably
when working on gamification and twitter-like employee profile. In that
use case adding the employee's user as follower was required to be able
to discuss on the employee form view. It is also a requirement to be sure
he receives news about received badges.
Since then however employee profile has been set as private and internal.
It is used only for HR purpose which is coherent with the model and the
business flow of various HR modules. Moreover it has never been really used
as intended in gamification or as a twitter-like profile. It seems therefore
not necessary to automatically add followers to this record.
If required, any message_post can add the employee's user in the recipients
if its attention is required on some message. It required only to set the
target users's partner in the partner_ids parameter of message_post that
is propagated to the message creation and notification.
An override of notification process can also be removed. It seems people
wanted to add the user to its profile but without notifying him. Let
us remove all that crap.
Finally the CTA button to (un)follow employees directly from the kanban
view is also removed for the same reasons as state hereunder.
Posting on users is not supported anymore. It was implemented in a time
we thought having a twitter-like behavior in Odoo was a good idea.
Posting on users was redirected on its related partner in mail. It was
redirected on its related employee in hr. It does not make sense anymore
as employee are records with limited access and partners used for other
purpose than discussing notably in accounting.
Now that we have chat channels it makes no sense to have this kind of
behavior still implemented. Let us remove it. No functional change
should occur with this commit.
Before this commit, when having a simple employee (group employee) accessing the form view
of hr.employee, there was traceback because the field is_address_home_a_company was not in the view
This is because of commit 2d777d5
which restricted this field to the group_hr_user (Officer) in Python
When the view itself is not group-restricted
The JS loads everything from the view but puts invisible=1 on sections that have a group
The field, in our case, is forbidden before that and is not loaded, whereas the domain in which it is used is loaded
After this commit, the view loads correctly, while avoiding leaks as intended
OPW 813721
A few fields present in the "Private Info" tab of the Employee form did
not have the corresponding `groups` attribute.
This could cause access rights problems.
You could try to check followers on a model not inheriting from mail alias
mixin. In that case current code would check followers on a void mail
alias mixin record, meaning no followers found. Instead we now
differentiate the class method from the method checking record properties.
The name field is a stored related on the resource.resource record.
The name on the resource is required.
If no name (and no resource_id), the creation fails as trying to create a
resource without name (non-null constrain)
Force in the view to indicate to the user that a name is required but without
adding the constrain at the database level.
required=True on the fields adds a non-null constrain on the SQL column but the
related values are populated *after* the INSERT so it would fail depending on
the given values (e.g. a resource_id value but no name)
Fixes#20126Closes#20128
* account, hr, hr_recruitment, maintenance, mrp, sales_team, stock
Adaptation of https://github.com/odoo/odoo/commit/a79d83e436e5e965d59663d4a06a0f8a62d8f694 for saas-18 new colors.
Also change back all color defaults to 0 instead of 1 (see
mentioned commit: they were changed from 0 to 1 as in saas-16
the color was applied to kanban headers which had to be gray
(the old color 1) by default).
Also add default violet color for 'Customer Invoices' and 'Vendor Bills'
dashboards.
Now that we're closer to switching to P3 for good, these helpers have
outlived their usefulness, and mostly add noise.
All remaining dict.iter*() or dict.view*() must be converted to the
normal keys(), values() or items() calls.
Whenever the result is likely to be used for more than the scope of a
loop, or when the dict needs to be modified during iteration, the calls
must be wrapped in a ``list()``, to protect the new P3 semantics.
Those cases are very exceptional.
Also removed some dead code or improved the API to remove unnecessary
conversions.
* StringIO removed from stdlib, replace with io
* try to correctly handle BytesIO/StringIO (one is for bytes the other
is for text)
* fix base64: Python 3 removed bytes-encoding and bytes-bytes
codecs (via #encode) so replace all calls to str.encode('base64'),
also b64encode is a bytes->bytes conversion so attempt to properly
handle that
issue #8530
* Add a warning on the employee form view when the home address has a
company linked
* Get email, phone number and mobile number from the application
form when creating an employee from there
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 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.
Yannick Tivisse