[IMP] hr_*: introduce the employee profile
================================
## General Purpose
We want an 'Employee profile' gathering every data about an employee.
The main form view is modified to become this employee profile.
A user can also see his own profile through the Preferences menu.
The new profile replaces the current Preferences view if the `hr` module is installed and the current user is linked to an employee. The Profile will show the employee of the current company.
A user should be able to see and edit his own profile.
*Problem*:
Many fields on hr.employee are protected by `groups="hr.group_hr_user"`.
Therefore, a regular user cannot see or edit those fields.
This protection must be bypassed to allow read/write access to the regular user's own data.
A similar mechanism already exists for `res.users` (for Preferences)
The better (least worst) solution found is to reuse this mechanism by adding related fields on `res.users`.
Pros:
- Don't change security access on hr.employee
- Don't implement yet another custom security layer, risking to add new security breaches
- A lot of fields are added by other modules on hr.employee.
It would have required to integrate them with the custom security layer.
- Fields added by other modules on the user's preferences view (normal view, not the profile)
are automatically included in the employee's profile view.
- Allow the hr.employee form view to be different than the user profile accessible
through the Preferences menu.
E.g. add custom buttons only relevant to the logged in user such as "Request a leave".
Cons:
- Each field from hr.employee that you want to appear on its profile
must be added as a related field on res.users
- Those related fields must be added to user's preferences view (duplicate views)
- They also must be added to `SELF_[READABLE | WRITABLE]_FIELDS`
Note:
When the front-end loads the views it gets the list of available fields for the user (according to its access rights). Later, when the front-end wants to populate the view with data, it only asks to read those available fields. However, in this case, we want the user to be able to read/write its own data, even if they are protected by groups (groups are kept on the related fields on res.users). The front-end need to be made aware of those fields by sending all field definitions.
## Changed modules
### hr_attendance
Adds a stat button to this employee profile showing the number of hours worked last month.
Remove the Boolean computed field `manual_attendance`.
This field is just a shortcut to add/remove the employee's user in the "Manual Attendance" group.
The checkbox is confusing on the employee's form and this should be done through the normal group management screens.
### hr_presence
Display the presence status on the employee kanban template.
The status is a colored chip which can be green (present), orange (to define) or red (absent).
Currently, the presence status is only computed when accessing the report view. As this commits displays it on the employee kanban, it should be updated more frequently.
The state should not be updated every time the kanban view is loaded since the computation is a bit heavy. Instead: add a cron to update status every hour.
-> The status is accurate on the report view (status is still updated
when loading the view)
-> The status in accurate at 1 hour on the kanban view
### [ADD] hr_attendance_presence
Bridge module between `hr_attendance` and `hr_presence`.
This PR integrates `hr_presence` module in the employee profile and adds the presence status on the employee kanban view. But `hr_attendance` adds at the same place a similar status icon for checkin/checkout.
This bridge module makes the status from `hr_presence` invisible as `hr_attendance` should be the main presence control mechanism.
Also, this commit adds the ability (through a new setting option) for `hr_presence` to take into account checkin/checkout to determine the presence status.
### l10n_be_hr_payroll
integration with employee profile
[ADD] hr_skills: Introduce a new module for employee resumé and skills
=======================================================
Purpose
-----------
Consultancy companies need resumé and skills of their consultants.
For big projects, they often need to send them to their customers.
These information are also useful to statistics.
Specification
-----------------
### New models
#### `hr.resume.line.type`
Types of resumé lines. e.g. *Experience*, *Education*, *Hobbies*
#### `hr.resume.line`
It is a line in the resumé of an employee.
#### `hr.skill`
Name of a skill. e.g *French*, *Python*, *Piano*
#### `hr.skill.type`
Skills can belongs to a particular type. A skill type has skill levels associated.
e.g. *Languages*, *Dev*, *Music*
#### `hr.skill.level`
Levels available for a particular skill type. Each level has a label
and a progress (between 0 and 100) associated.
e.g. *Intermediary (20%)*, *Advanced (85%)*, *Expert (100%)*
#### `hr.employee.skill`
These are skills which employees have. It links an employee with a particular skill
and level.
e.g. Mitchell has an *Intermediary* level in *Python*
### Access Rights
Only a `hr_user` can create/edit `hr.resume.line.type`, `hr.skill`, `hr.skill.level`, `hr.skill.type`.
If employees are allowed to edit their infos (setting), they can also create/edit `hr.resume.line`,
`hr.employee.skill` for themselves.
### UI
Resumé lines are displayed, grouped by type, in a new 'Resumé' tab in the employee
form. Resumé lines can be reordered (handle widget)
Emloyee skills are displayed in the Resumé tab, grouped by skill type.
[IMP] hr, hr_holidays, hr_expense: Change onchange parent_id behaviour
=========================================================
Purpose
-----------
When the manager (parent_id) of an employee changes, it doesn't always mean that other responsibles (Leave responsible, expense responsible, coach) should also change.
Specification
-----------------
When changing the employee's manager, the leave responsible, the expense responsible and the coach should be changed only if the field was not set or if the responsible is the previous manager. In that case, they should be set to the new manager. Otherwise, it means the field was most probably set manually and it should be left unchanged.
Task 1913089
--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
closesodoo/odoo#30502
General Purpose
===============
We want an 'Employee profile' gathering every data about an employee.
The main form view is modified to become this employee profile.
A user can also see his own profile through the Preferences menu.
The new profile replaces the current Preferences view if the hr module is installed
and the current user is linked to an employee.
A user should be able to see and edit his own profile.
*Problem*:
Many fields on hr.employee are protected by groups="hr.group_hr_user".
Therefore, a regular user cannot see or edit those fields.
This protection must be bypassed to allow read/write access
to the regular user's own data.
A similar mechanism already exists for res.users (for Preferences)
The better (least worst) solution found is to reuse this mechanism by adding related fields on res.users.
Pros:
- Don't change security access on hr.employee
- Don't implement yet another custom security layer, risking to add new security breaches
- A lot of fields are added by other modules on hr.employee.
It would have required to integrate them with the custom security layer.
- Fields added by other modules on the user's preferences view (normal view, not the profile)
are automatically included in the employee's profile view.
- Allow the hr.employee form view to be different than the user profile accessible
through the Preferences menu.
E.g. add custom buttons only relevant to the logged in user such as "Request a leave".
Cons:
- Each field from hr.employee that you want to appear on its profile
must be added as a related field on res.users
- Those related fields must be added to user's preferences view (duplicate views)
- They also must be added to SELF_[READABLE | WRITABLE]_FIELDS
Note:
When the front-end loads the views it gets the list of available fields
for the user (according to its access rights). Later, when the front-end wants to
populate the view with data, it only asks to read those available fields.
However, in this case, we want the user to be able to read/write its own data,
even if they are protected by groups (groups are kept on the related fields on res.users).
The front-end need to be made aware of those fields by sending all field definitions.
hr_attendance
=============
This commit integrate attendance in the new employee profile.
It also adds a stat button to this employee profile showing
the number of hours worked last month.
Remove the boolean computed field 'manual_attendance'.
This field is just a shortcut to add/remove the employee's user
in the "Manual Attendance" group.
The checkbox is confusing on the employee's form and this should
be done through the normal group management screens.
hr_presence
===========
Display the presence status on the employee kanban template.
The status is a colored chip which can be green (present),
orange (to define) or red (absent).
Currently, the presence status is only computed when accessing
the report view. As this commits displays it on the employee kanban,
it should be updated more frequently.
The state should not be updated every time the kanban view is loaded
since the computation is a bit heavy. Instead: add a cron to update
status every 15 minutes.
-> The status is accurate on the report view (status is still updated
when loading the view)
-> The status in accurate at 15 minutes on the kanban view
[ADD] hr_attendance_presence
============================
Bridge module between hr_attendance and hr_presence.
This commit integrates hr_presence module in the employee
profile and adds the presence status on the employee kanban view.
But hr_attendance adds at the same place a similar status icon for
checkin/checkout.
This bridge module makes the status from hr_presence invisible as
hr_attendance should be the main presence control mechanism.
Also, this commit adds the ability (through a new setting option)
for hr_presence to take into account checkin/checkout to determine
the presence status.
l10n_be_hr_payroll
==================
integration with employee profile
The Live chat history was taking too much space and was hard to read.
The goal here is to display more information on the screen.
The pictures and padding are then reduced.
Note that kanban view is not a solution in long term.
At it does not allow to squash messages per user (if consecutive
messages from same user at close interval of time).
As the thread widget will be reviewed by discuss team in a
near future, we keep this at the moment and will integrate the
new thread widget later, mainly to be able to squash the messages.
Task ID : 1913869
Closes PR #30343
When embedding the livechat on an external website, we used to make JSONP calls.
As the support of JSONP calls has been dropped, we now use the CORS mechanism
instead.
Revision on https://github.com/odoo/odoo/commit/a669d89565ad9904d07886b00665e3940ce04665
The commit above changed the template of the Discuss app in order
to add some features, such as the channel "quick search".
The livechat module extends Discuss app to support livechats. However,
the commit above didn't update it correctly. As a result, pinned
livechats were not shown in the sidebar.
This commit fixes the issue, so pinned livechats should now always
be visible in the sidebar.
closesodoo/odoo#30738
Before this commit, when livechat operators had chats in the
Discuss app and reload their page, they could loose some
pinned livechats.
This problem only occurred on livechat conversations when both
users are authenticated. Any two-user channels should always
be pinned by default, which is the case for internal chats.
This logic was applied on channels with type `chat`, but this
is ignored with livechats because they are channels of type
`livechat`.
This commit fixes the issue by defining internal chats and
livechats as `chat`. Any chat conversations are automatically
pinned when a message is posted, including livechats.
Note that before this commit, the livechats were visually
pinned in the Discuss app, although the server did not consider
them as pinned. The client-side code always assume conversations
are pinned, which is why a page refresh looks like a loose of
previously pinned conversations.
opw-1919327
closesodoo/odoo#30200
Before, the name of the channel was not always matching the real channel operator,
as a second random was made on operators.
This commit fix this.
Task ID : 1918350
Closes PR #29570
To avoid having to configure the livechat channel when testing on runbot,
the admin is already set as operator of the livechat channel.
Task ID : 1912056
Closes PR #29020
Ignorant fools have been saying for more than a decade that <table> elements
should not be used for layout.
Once again, Odoo proves them wrong. You just need the right css.
opw 1914139
closesodoo/odoo#29498
In order to facilitiate the configuration of a livechat on the website,
the first livechat channel that was demo data from im_livechat
is now set as data. Website is now using this first livechat channel
instead of creating a new one and using it.
Task ID : 1912056
Closes PR #29020
*: tools, web, website, website_forum, mail, im_livechat
This commit refactors ir_http to make it more readable
and flexible.
Move the resize function of web/image to odoo.tools
Co-authored-by: XavierDo <xdo@odoo.com>
Co-authored-by: Antony Lesuisse <al@openerp.com>
closes: #28563
task: #1908896
The utility classes `Timer`, `Timers` and `CCThrottleFunction`
were only used by the feature 'is typing...', thus all those files
were in the same folder.
This commit moves the utility classes in a dedicated folder,
and introduces a folder for thread mixins, in preparation for
future features on threads that will be implemented as mixins.
With this commit, the UI for "is typing..." notifications
has changed.
** before **:
In Discuss & chat windows, "is typing..." notification bar
at the bottom of the thread, inside the conversation.
** after **
In chat windows, animated '...' next to conversation name.
In Discuss, animated '...' next to conversation name in sidebar,
and text below the composer.
Task-ID 1881001
Before, the duration and time to answer where computed based on the
mail channel creation date and
- the first message date from operator (for time to answer)
- the last message date (for duration)
But as the mail channel can be created long ago before the first message,
the result was not really representative.
Now, we are basing the computation only based on the messages.
Time to answer : first message date from operator - first message date
Duration : last message date - first message date
It allows, with the add of the second join on mail_message,
to simplify the extraction of those two indicator by removing the long
subselects.
Also, we fix the nbr_message in operator by adding the missing distinct.
Special mention to @jem-odoo who clearly did (almost) all the work :
This guy is amazing ! After a long and mature reflexion,
he finally put all his mighty power to enhance thoses reports
to give the users a wonderfull experience full of flowers and
peacefull sun, but also fast as a energized rabbit superhero !
Hail to him ! The One, the Only, the Chosen..
If you see him around the corner, please give him all your love
and gratitude ! Voilà voilà..
Task ID : 1895998
Closes PR #28283
To avoid that people know the complete name of the support members
(for privacy purpose), a username can be used.
Users have the opportunity to set and modify their username in
their user preferences.
If the username is not set, the complete name will still be used.
If the username is set, it is used for the discussion title, the
name of the message sender, the name of the team members in the
channel statistics. All of this, only in the livechat context.
Task ID : 1895998
Closes PR #28283
As in super, we add uuid and message if channel is public
we have to exculde the public channel to add the same in a livechat case
Also, _channel_message_notifications is a bit rewritten to remove useless
code. Indeed, notifications will always be filled in as
_channel_message_notifications is only called by _notify that ensure that self
is not null and that message is singleton. In super, the notifications will then be
filled in and in override, no need to check if notifications is not empty.
We take the message dict from notif to avoid calling message_format a second time.
Task ID : 1895998
Closes PR #28283
This commit adds more precision about ratings per operators for a
specific channel. Only the operators that have been rated on the last 100
feedbacks have their statistics displayed. The other operators that did not
worked (or have not been rated) on the last 100 feedbacks are still displayed
but are flaged as 'Not rated yet', so we still can see who is working on this
channel.
Task ID : 1895998
Closes PR #28283
By adding a livechat_operator_id on the mail.channel, we ensure that,
even if the operator of the discussion is removed from the operators
of the livechat.channel, we can still know who was the operator,
at the time of the discussion.
In that way, we can still keep the history of the former assigned operator.
[IMP] im_livechat : simplify channel and operator reports
As Operator_id is required for livechat channel,
we can assume that if livechat_operator_id is not null,
then it's a livechat channel. also, as we have the partner_id
stored in livechat_operator_id field, no need to join
partners and users tables anymore to get the operator
of the channel.
Task ID : 1895998
Closes PR #28283
Adds some indicators in channel report in order to use them in the new
enterprise livechat dashboard. Those indicator are added here to re-use
directly the channel report view. It allows the users to use also those
new indicators in the existing reports.
- No answer indicator
- Days of activity indicator
- Day number indicator
- Country of visitor :
This makes able to see from which country comes the visitors
and make statistics with it.
If no GeoIP server are installed, or if the country is not found,
or if visitor is logged in but has no country configured, the country
si set to 'Unknown'.
Also, align sessions and operator report title on menu name
Task ID : 1895998
Closes PR #28283
Before, if the visitor was logged in, anonymous name = user.name.
But if we use anonymous name field even if visitor is not anonymous,
we cannot know, in stat e.g., if the session was really made with
an anonymous visitor or not as the field is always filled in.
Now, if the visitor is not anonymous, we use directly the user.name
but we do not fill in the anonymous name. So that if anonymous name
is null, we know afterwards that the session was made we a real
anonymous visitor.
Since the anonymous name is empty if visitor is logged in,
we cannot use anonymous_name anymore to get the title of the session window.
Task ID : 1895998
Closes PR #28283
Impacted modules: im_livechat, project and rating
This commit restricts the access to some method of the rating API. Indeed,
some of them are internal business and should not be called from anywhere
to avoid breaking the rating flow.
This commit also rename some method to fit guidelines. This should not
bring any functionnal changes.
Task-1903565
No functionnal changes are done in this commit. Even
the period of rating to take into account to compute
livechat channel satisfaction (introduced at
5b60e05ce4)
stays the same, but use the parent mixin mecanism.
Task-1903565
This rev. introduces robust helpers to use in the JS tests suite to
interact with DOM and components, and starts using them (almost)
everywhere.
All the helpers are exposed though testUtils.js.
There are 2 kinds of helpers:
1. Assertions
-------------
* assert.containsNone, containsN, containsOnce check that the DOM
(or a specific part of the DOM) contains a `selector`. It
generates a correct error message automatically.
ex: assert.strictEqual(form.$('.o_form_editable'), 1, "msg");
-> assert.containsOnce(form, '.o_form_editable');
* assert.isVisible, isNotVisible check that the DOM has an element
visible or not. They also check that the element is actually in
the DOM (before most tests didn't verify this).
* assert.hasClass, doesNotHaveClass, hasAttrVAlue, check specific
properties of a DOM element, and also validate that it is
applied on a single existing DOM element (before most tests
didn't verify this).
ex: assert.notOk(form.$('button').hasClass('btn-primary'));
-> assert.doesNotHaveClass(form.$('button'), 'btn-primary');
2. Utilities
------------
The goal of the utilities is to centralize the definition of many
standard components and interactions, ensuring that when we
refactor the JS framework, we do not need to change all the tests.
Existing mock utilities (addMockEnvironment, intercept, path,
patchDate, unpatch and fieldsViewGet) are moved to
'testUtils.mock.*'.
Existing DOM utilities are moved to 'testUtils.dom.*'.
New dom utilities are created for opendDatePicker, click,
clickFirst and clickLast. Helper `click` verifies that there is
exactly 1 element visible in the DOM you click on, `clickFirst`
and `clickLast` verify that there are more than one element on the
DOM.
ex: form.$('button').click();
-> testUtils.dom.click(form.$('button'));
New Form utilities: (testUtils.form.*)
clickEdit, clickSave, clickCreate, clickDiscard, all clicks on
the control panel buttons of the form.
`reload` reloads the form data.
New modal, graph, kanban and pivot utils (testUtils.pivot.*,
testUtils.kanban.*, etc.).
New fields utils: (testUtils.fields.*)
* editInput, editSelect: allow to change the value of a field,
using a selector to identify it. They validate that the input
exists and trigger the change event automatically.
* editAndTrigger: allow to modify a field and trigger specific
events after the value change
* many2one (testUtils.fields.many2one.*)
clickOpenDropdown, clickHighlightedItem, clickItem,
searchAndClickItem: use a field name instead of a selector and
do all the complex mechanism to open, filter and highlight
many2one fields.
Joint work with aab, dam, ged, mge, svs and vsc.
Purpose is to ease understanding of applications / categories and their
links with the access rights labelling.
This commit is related to task 1884968 and PR #29176.
Check that it makes custom binary fields into attachment as that's the
main reason for the change: when users create binary fields via Studio,
they're necessarily db-stored (as the interface doesn't allow altering
the attachment attribute and it's unclear how we'd handle users
switching it on/off every time), which significantly bloats their
database (and burns storage & backup space), especially as the primary
use case for binary fields is adding images and documents to records.
* check that binary fields are properly created as attachment=True
* add attachment=False on fields where that seems relevant (most but not
all of the fields previously using the default)
* remove occurrences of attachment=True
closesodoo/odoo#29308
Robot Odoo