Following the removal of read access on ir.model (odoo/odoo#69120),
the mail.activity.type model was not accessible to non-admin users due
to the res_model_id many2one field.
Before this commit, a project user could not access the Activity Type
menu.
Convert it to a selection field with the selection values being
computed in sudo.
closesodoo/odoo#74981
Related: odoo/enterprise#20214
Related: odoo/upgrade#2734
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
This field is a non-sense. By using the same logic, it should be added
to any low level model.
Replace the check by a simple verification of presence of an XMLID.
A more generic opt-in solution should be integrated into ORM.
Partially revert commits 0db0e66e96 and
bbd64c22ab.
See #29257odoo/enterprise#3550closesodoo/odoo#31778
Signed-off-by: Christophe Simonis <chs@odoo.com>
Purpose of this merge is to update main addons and set activity types used
for automated activities as master data. This means they cannot be removed.
Indeed those activity types are used in business flow to generate activities
and removing them may break some flows.
This commit is linked to task ID 1907970 and PR #29257.
Purpose
=======
We need to use an international word to define holidays and leaves, rename everything into Time Off.
Employees needs a good dashboard and leaves summary
Specification
=============
1/ Add a new dashboard: https://balsamiq.cloud/sm5j0d/pg5w04r
Create a new dashboard with a calendar and a summary of all time off and time off request
2/ Rename leaves into Time Off everywhere
3/ Improve general usability
TaskID: 1916871
closesodoo/odoo#29634
Purpose
=======
- A manager could want to follow only home working of its own department
- A HR officer could want to follow only sick leaves of all dpts.
We have to improve what people follow and how they follow it in the leaves module
Specifications
==============
Subtype on department
---------------------
In department form view, right now, people can follow approvals
Instead we should have some generic and specific subtypes depending on the leave type
For instance, a HR Officer wants to follow only sick leaves and a manager only home working
Following mechanism
-------------------
Remove first / second approval subtype differences
if a leave type is not linked to a specific subtype, consider only classic
people follow it (employee and assigned HR people / manager)
Link leave type to subtypes, with some by default (i.e. home working, ...), not mandatory
When creating a leave type, link it to the department to be able to
activate the subtype for only one department.
This commit improves leave request and allocation management through a
better integration of activities and addition of automated activities.
Several things are done in this commit :
* leave and allocation models do not inherit from mail.activity.mixin.
This commit adds the inherit so that HR users and managers can now
schedule and manage activities on leave and allocation requests. This
will help them in their daily job;
* automatic activities generation is added for leave and allocation.
Activities are generated for approval and second approval. They are also
automatically set as done when validating or unlinked when refusing or
resetting to avoid bloating users with unnecessary activities;
* a menu to configure activity types is added. Indeed HR managers should be
able to see and configure activity types related to their job;
* filters are added to be able to use the systray and to filter the kanban
view based on activities
Having automated activities allow to replace some messages and tracking
that were implemented to warn people of leave and allocation to approve
or validate. This commit therefore
* simplifies the tracking as only approved or refused state now trigger
a subtype;
* removes to approve and to validate subtypes on leave and allocation
model as well as their parent subtypes on the department. This allows
to simplify chatter a lot in hr_holidays app;
It is simpler to have data split by main model or application like we
already do for models and views. It allows to easily have an overview
of data a module holds.
As we will work on mail related data like adding activities or tweaking
subtypes and templates, having them all in a single file and not lost
between other data helps finding and working with it.
This commit only moves code. No functional change should occur.