PURPOSE
=======
When you close a payroll (employees), there are often a lot of document
linked. Archiving an employee should archive the contract, cancel future
leaves, archive the private address
Specification
=============
Add departure date (hr):
- Add a Date field to both hr.departure.wizard and hr.employee. In
the wizard, the field is required.
- In toggle_active() method in hr.employee, set departure_date to
false when unarchive the employee.
- If user has a current running contract, a user error will raise if
user enter a departure date earlier than the start date of the
contract.
Add checkbox to set a closing date on hr.contract (hr.contract):
- In the hr.departure.wizard, set the departure date to be the end
date of runing contract. Set the states of all draft contracts to
"cancel".
Add checkbox to free car (hr.fleet):
- In the hr.departure.wizard, set end_date to
fleet.vehicle.assignation.log, if there is no end_date or end_date >
departure_date
- Go through fleet.vehicle, find records with dirver_id to be the
employee, set it to False.
Add checkbox to archive private address (hr):
- when the private address not link to a internel user, set
employee.address_home_id.active to Flase
- unarchive it after the employee unarchived
Add checkbox to cancel future appraisals (hr.appraisal)
- find all appraisals link to the employee and state in
['new', 'pending'], set their state to 'cancel'.
Add checkbox to cancel future leaves (hr.holidays):
- only consider leaves are not in state ['refuse', 'cancel'],
find leaves with to_date > departure_date, set their state to
'cancel'.
PR #42526
Task 2153106
Related: odoo/enterprise#7471
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
In Employee / Work information / Responsible: there is a lack of
information on the "help message" The objective is to change text
in the help message by the ones below:
Field "Coach":
-Employee responsible of this employee.
-The "coach" has no specific rignts or responsibilities by default.
Field "Time Off":
-User responsible for approving "time off" of this employee.
-If empty, the approval is done by any administrators or approvers (determinated in settings/users)
Field "expense":
-User responsible for approving "Expenses" of this employee.
-If empty, the approval is done by any administrators or approvers (determinated in settings/users)
TaskId :2168330
closes odoo/odoo#43467
Closes: #43467
Related: odoo/enterprise#7778
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Open Employees>[DEMO]. Go to HR Settings and generate badge id
Now go to POS Settings, enable "Login with Employees". Now open
the session and login by scanning the [DEMO] employee badge.
The badge will not be recognized, this is caused by the fact that the
badge is 8 digits randomly generated, while the parser recognize
cashiers only if the barcode has a prefix of 041.
Fixed the badge id generation, and adjusted the length to other barcodes
in the system
opw-2151942
closesodoo/odoo#43228
X-original-commit: 90bcda64ba6058169b48ff8214e7c2a98eb9a0f8
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
When we add a user to employee, we can have problem with leave,
expense or coach manager. It's due to those compute fields.
closesodoo/odoo#40795
Related: odoo/enterprise#6865
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Current activity types master data cannot be unlinked through a quite harsh
override of unlink using xml id existence, introduced at 2602642a78.
Some of them are real master data, other could be unlinked if users want it.
Finally custom activity types may cause errors when removed if used in some
side models like server actions or automated actions.
To allow more flexibility we remove the removal constraint and implement
a fallback mechanism. It is implemented in mail.activity.mixin when calling
activity_schedule(xmlid, ...). If the given xmlid is not found
_default_activity_type() specifies the default activity to use. It can
be overridden in modules if some specific behavior is wanted.
e.g.
def _default_activity_type(self):
"""Define a default fallback activity type when xml id not found
only used in in activity_schedule() for now.
"""
try:
return self.env.ref('mail.mail_activity_data_todo')
except Exception:
return False
In this commit we also
* restrict deletion of activity type (hr.plan and ir.actions.server);
* fallback on default activity type if xmlid ref not found in
activity_schedule;
* correct calls to activity_schedule and replace some manual creation calls
by activity_schedule;
Task ID 1961156
PR #39013
Related: odoo/enterprise#6238
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Co-authored-by: Victor Feyens <vfe@odoo.com>
Co-authored-by: Michaël Mattiello <mcm@odoo.com>
Make some fields editable in multi edit.
Some onchange are tranformed in compute fields.
id=2078674
closesodoo/odoo#39711
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Before this commit:
Private email and phone are related of partner 'address' fields.
But the phone was read-only and the email is editable.
After this commit:
As phone and mail are related, they are read-only. We must edit
them on the partner of Address field.
close#38518closesodoo/odoo#38872
X-original-commit: ed6fb25ca0671a520c9d003a58eefefcf93dbc1a
Signed-off-by: jbm-odoo <jbm-odoo@users.noreply.github.com>
Since there are message_post overrides using the form `def message_post(self,
**kwargs)` in some modules, this method is intended to be invoked with keyword
arguments only.
This commit enforces this behavior. Calls such as `message_post("body")` will
fail regardless of which addon is installed, forcing users to use
`message_post(body="body")`.
It also fixes a message_post override in hr, and applies the same
mechanism to message_notify, and _message_log.
closesodoo/odoo#33306
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Move and adapt gantt unavailability related methods (
_get_work_interval() and _get_unavailable_intervals() ) from
hr.employee to resource.resource. This move allows the unavailability
to be generated for users without related employees (like in FSM in
enterprise).
Task-2069861
closesodoo/odoo#36785
Signed-off-by: Jérome Maes (jem) <jem@openerp.com>
Currently, parent_id is defined on hr.employee. This field
as an onchange defined.
But the inherit of hr.employee.base in the leave module
adds an onchange('parent_id'). The onchange method is never
called because the onchange in hr.employee does not call super
(which it's not supposed to do because the parent model
does not have the parent_id field).
To fix the issue, parent_id and all its onchange methods
are now defined on hr.employee.base
There are too many image sizes. Since they are stored resized this takes time to
generate when saving a new image, it's more rows on the attachment table, more
files on the disk, ...
64px is close enough to 128px that it can be removed without a big impact on
download size.
It will even reduce download and number of requests when both images are
displayed because now only one has to be downloaded and then benefit from cache.
The difference between the two is typically around 1.5kB which is negligible
these days, especially when the request overhead is around 0.5kB already, not
even taking into account other factors such as latency.
If a 64px image must absolutely be returned, it is still possible to pass the
size parameters to the image route. But the current guideline is to handle
resizing in the views when necessary.
Views
=====
- remove width and height attributes when existing CSS rules are overriding them
(eg. `.oe_kanban_avatar` in the right context)
- add CSS rules instead of width and height attributes when possible
- use `object-fit: cover;` where width and height are forced to avoid distortion
of non-square images
- for products, use `object-fit: contain;` instead, keep ratio but without crop
- add new CSS rules where the expected size was max 64px*64px before due to the
image size itself
- remove `img-fluid` where using size classes to avoid conflicting rules
task-2060865
closesodoo/odoo#36147
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
We should avoid reseting the manager_id on the employee when there is no
manager defined on the department
Also updates the department form view in order to display the fields
better
closesodoo/odoo#37028
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Only one employee per company and per user is allowed.
Based on the company the user is logged in, "My profile"
should redirect to the employee profile of the current
company.
If the user has no employee in the current company,
"My Profile" redirects to the simple "Preferences" screen.
Currently, it always redirects to the employee in the user's
main company (`user.company_id`)
This issue is a consequence of a5b6f31 which uses the context
to know the current company instead of `user.company_id`.
Specification
=============
Un-store the employee_id field on the res.users model.
To achieve this, we need to implement a _search method for this field.
That way, each time we try to access to the employee_id value, the
returned employee depends on the context.
Purpose
=======
It happens a lot that we access to the employee timezone to compute
presence states, leaves, ...
Instead of sudoing all those accesses, it looks better to expose this
data in the public profile.
closesodoo/odoo#35811
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
The color field is necessary to be able to display some fields
(many2many_tags) and used in the kanban views
closesodoo/odoo#35216
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
closesodoo/odoo#35462
Signed-off-by: Romain Libert (rli) <rli@odoo.com>
This branch is the combination of several optimizations in the ORM:
* store field values once in the cache: the cache reflects more
faithfully the database, only fields that explicitly depend on the
context have an extra indirection in the cache;
* delay recomputations by default: use method `recompute` to explicitly
flush out pending recomputations;
* delay updates in method `write`: updates are stored in a data
structure that can be flushed efficiently to the database with method
`flush` (which also flush out recomputations);
* make method `modified` take advantage of inverse fields to inverse
dependencies;
* filter records by evaluating a domain on records in Python;
* a computed field with `readonly=False` behaves like a normal field
with an onchange method;
* computed fields are computed in superuser mode by default.
Work done by Toufik Ben Jaa, Raphael Collet, Denis Ledoux and Fabien
Pinckaers.
closesodoo/odoo#35659
Signed-off-by: Denis Ledoux <beledouxdenis@users.noreply.github.com>
When the many2xxx field relates to a model where company_id is required, set
this domain [('company_id','=',company_id.id)]
When the company_id field of the related model is not required, set this domain
['|',('company_id','=',company_id.id),('company_id','=',False)]
When setting the domain on a field which is in the treeview of a xxx2many field
evaluate against the company_id of the 'parent'.
Some constraints have been added on sereval models. Take a look at the complete
specification for more details.
TaskID: 2024446
Closes: #35266
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Improve the usability of the employees profile / "My Profile"
TaskID: 2048672
closesodoo/odoo#35587
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Currenty if the self edit setting is deactivated, a user has to be
hr_user in order to change its employee image through the employee
profile.
The problem is that if the image on the employee is currently
not set, we should copy it through the employee profile whatever the
setting value
closesodoo/odoo#35542
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
PURPOSE
SMS are a powerful marketing tool. For instance it is perfect to announce a
sale or to communicate a coupon code, to welcome a new customer in a fidelity
program, ...
Purpose of this task is to integrate SMS sending in batch in mass mailing. It
will use same mailing objects but sending SMS instead of emails. Some metrics
and flows will have to be slightly updated at the same time.
SPECIFICATIONS
Limit use of templates to models that are really capable of sending
SMS. Templates are now available on models that inherit from mail.thread
and effectively have fields used in SMS sending.
Technically this is done through a not stored field on ir.model that is
searchable. SMS sending capabilities is based on
* having fields holding phone numbers, as defined on mail.thread in SMS;
* having fields holding partners, as defined on mail.thread in SMS;
This implied some code rewriting notably about finding default SMS
recipients on a given model, in order to have fields instead of directly
returning partners.
LINKS
Task 1997464
PR #34424
Original SMS addition: Task 1922163 (4287481)
Currently, a simple user no longer see fields protected
by groups in his profile.
When retreiving the view arch, `sudo()` is used to bypass
the group protection.
But since commit 1e6c3be, `.sudo()` no longer changes the user.
Hence, groups are still checked for the simple user.
To fix the problem, the view arch should be retrieved with
a user with all groups (SUPERUSER). This assumes that
SUPERUSER has effectively all groups.
closesodoo/odoo#35486
Signed-off-by: Romain Libert (rli) <rli@odoo.com>
The `private_email`, `last_check_in` and `last_check_in`
fields were added by e9d9898 to the
profile view but not in `SELF_READABLE_FIELDS`.
A simple user was therefore not able to read the field and
access his profile.
To avoid any similar oversight in the future, a test is added
to ensure a simple user is able to read all fields in
the profile view.
This attribute is misleading as it is insufficient to correctly upgrade
the database. It only renames the column in the database, but other
operations are needed, like updating the corresponding `ir.model.fields`
record (and its xmlid). The default values and the translations are also
lost during the upgrade.
Moreover, this feature was misused. It was:
- left on fields during multiple versions.
- used on reports (SQL views). This would be ok if the feature was
complete, but, as is, it was useless.
- kept unchanged after a second renaming of the field (which can happen
versions later the first rename).
- used, even when the meaning of the field changed. i.e. the field
`archived` has been renamed to the classic `active`, but the value
in the database should be switched.
The following models are already using big images, or they might need big images
in the future:
- partner
- hr employee
- shop category
- lunch product
- gamification badge and karma rank
PR: #34925
image_original => image_1920 (now resized to 1920)
image_big => image_1024
image_large => image_256
image_medium => image_128
image_small => image_64
image replaced by image_1920 (when writing) or by image_1024 (when displaying
what was previously the big size)
+ add new intermediate format:
image_512
PR: #34925
Purpose
=======
On a many2many targeting the hr.employee model, if the user has no
access rights to the hr.employee model, clicking on a record of the
many2many will lead to a traceback.
Specification
=============
It's because load_views, called by the web client, will try to load
the form view on the hr.employee model. Overriding the method to
load the public employee form view instead if the user has no read
access is sufficient to solve the issue.
We could have overriden the methods fields_view_get and fields_get,
but it doesn't seem necessary yet.
closesodoo/odoo#34724
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
- On the HR module, the field `parent_id` is added on `res.users`.
The issue here, is that `res.users` inherits the fields from
`res.partner` where `parent_id` is already defined.
This causes issues when trying to read the parent `res.partner`.
Issue found by @rrahir
closesodoo/odoo#34059
Signed-off-by: Toufik Benjaa (tbe) <tbe@odoo.com>
Purpose
=======
1/ Robustness & security: right now it is not easy to understand and do something
clean in term of security (hr people vs employees, private info vs public). A
HR officer doesn't know if he can write something on the chatter. Currently, a
note will be visible for all the employees who have access to the employee form
view for example.
2/ In term of business, it makes sense to let a hr manages payroll stuff (contract,
employees private information, ... and other employee see public information
(résumé and work information)
Specification
=============
Introduce 2 new models:
- hr.employee.base (AbstractModel): This represents the basic skeleton
model on which the shared fields and methods between the public and
the private employees models.
- hr.employee.public (_auto=False): This is a sql view based on the
employee values, readable for an internal user (i.e. an employee).
The model hr.employee is not readable anymore for an employee.
There are now 3 ways to access the employee data:
1/ From the hr.employee views. HR officer access rights are required
2/ From the public profile. The public data for an employee are accessible
but can't be modified.
3/ From the 'My Profile' menu. A classic employee can access its own
data from there, and can modify them.
Purpose of this commit is to clean some bits of code, notably calls to
message_post/log as well as notification methods. It will ease performance
improvement work.
Small optimization: account: read content after extension check
Parameter cleaning
* use message log with kwargs instead of args;
* remove message post after hook useless parameters;
* remove _notify_email_recipients useless message parameter;
* remove message_notify useless send_after_commit parameters;
* remove message post params matching default values;
Other improvements
* remove message_post commands support for partners and channels;
* only calls message_post with ids list for channels and partners. We
don't support mix of ids and command anymore to simplify code;
* remove support of private discussion in mail.thread adding partners
as recipients, as there is no use anymore;
Related to task 1943901
Linked to PR #32404
yhu-odoo