Use the application form partner as work contact when converting him into
and employee.
Use the employee work contact as user partner on user creation.
The goal is to have only 1 partner over the whole recruitment process
flow, instead of three, thus reducing the confusion for end users who
don't really know who to choose.
TaskID: 3101400
- Improve performances, as the ir.rule restricting private partners
visibility is also applied on res.users by inheritance, on each
prefetch.
- Solve the issue of partners set as followers on records (eg: application
form) and then made private, making them impossible to contact via the
chatter.
- Solve the multiple access issues when trying to access the bank
account, or the private address for non HR people like the accountants
forcing the usage of sudo in the business code.
TaskID: 3101400
Improve usability of employee form. It is confusing for end users
to create another record to encode the employee address.
Move all the private information on the hr.employee record itself.
Remove the M2O address_home_id.
TaskID: 3101400
Issue:
If owner is set to job position, the owner does not receive an email
when creating a new applicant so we remove the owner if the alias is active.
task-3354799
closesodoo/odoo#126911
X-original-commit: 637c390d49f01ef374a3d4fe1fe14cca540a93f3
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Issue:
------
When applying for a job via an alias mail,
it is sometimes possible to get the wrong information
for the applicant's name and email.
For example:
Applicant's Name: "FirstName SecondName
Email: "FirstName SecondName" <name@example.com>
Because of this, it is not possible to send an e-mail
(for example, to set up a meeting)
because the latter is erroneous.
Cause:
------
Many e-mail services add the name associated with the e-mail in the header.
Example of a sent e-mail (can be retrieved with "Show original"):
```eml
MIME-Version: 1.0
Date: Wed, 21 Jun 2023 12:09:34 +0200
Message-ID: <CAHbiOmS_PHojqKMhoji9iev4I6pzuJ1=dVHgLKNh3SOS_mw7+w@mail.gmail.com>
Subject: Subject test
From: FirstName SecondName <name@example.com>
To: team-recruitment@company.com
Content-Type: multipart/alternative; boundary="000000000000f7db4305fea0f6c3"
--000000000000f7db4305fea0f6c3
Content-Type: text/plain; charset="UTF-8"
Message test
--000000000000f7db4305fea0f6c3
Content-Type: text/html; charset="UTF-8"
<div dir="ltr">Message test<br></div>
--000000000000f7db4305fea0f6c3--
```
Solution:
---------
Use `_parse_partner_name` method
to correctly parse the e-mail
and partner's name.
Note:
-----
Not add `email_from` in `_primary_email` field.
Otherwise, they will be override with the "raw" value.
opw-3347313
closesodoo/odoo#126678
X-original-commit: 551685368971161975d64f480e9bec326db8931e
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Signed-off-by: Thomas Lefebvre (thle) <thle@odoo.com>
The previous commit introduced an optimization to reduce the number of
queries and fields fetched when we call `name_search`. But it works much
better when the dependencies of `display_name` contain field names used
in the calculation (on the same record/model).
Then, to improve the performance and the cache coherency, add `depends`
and `depends_context` depending on the custom `_compute_display_name`.
Add only the first level of dependencies (never traverse relational
field) because only these have a positive impact on the previous
optimization and the cost is very low (see `modified`).
About `depends_context`, we don't include `lang` because (when `_` is
used by example) it is unlikely to get the same display_name in the same
request with two different lang.
closesodoo/odoo#122085
Related: odoo/documentation#4639
Related: odoo/enterprise#42599
Related: odoo/upgrade#4780
Signed-off-by: Raphael Collet <rco@odoo.com>
Rationale
=========
Since v8, the `display_name` field is present on all models. By default,
`display_name` uses `name_get` which has pretty much the same purpose
(return record name used by the web client). Gradually, many (backend)
developers (and the ORM: https://github.com/odoo/odoo/commit/6da1c3ac4c036eac289597602976538e243cb939)
started using `display_name` (more convenient than
`record.name_get()[0][1]`) but it still had the `name_get` override.
It becomes more complex than necessary and poeple start to misunderstand
the two (and sometimes override both, leading to inconstiencies between
`display_name`/`name_get`).
To simplify the ORM and the API, we decided to keep only one of them,
the `display_name` field:
- It is much more convenient from a backend point of view
(`record.name_get()[0][1]` vs `record.display_name`)
- It is cached during the same transaction (and invalidated if
its dependencies change)
- It can be overridden like any other compute field (override
`_compute_display_name` with any extra dependencies)
- `name_get` is replaced by `read(['display_name'])`
(API perceptive), which can actually be more efficient
(if `display_name`'s depends are correct, the ORM will only fetch the
fields it needs instead of every prefetchable field)
Changes
=======
- Deprecates `name_get` for the v17 and based the method on
`display_name` (the opposite of before)
- Converts all usage of `name_get`
- Overrides of `name_get` are now overrides of `_compute_display_name`
- For `res.partner`, rename the field store `display_name` into
`complete_name` because `display_name` context-dependent and it makes
no sense to have a compute store that is context-dependent.
- Previously, it was possible to return multiple names for the same
record with `name_get`, but it was tricky and most of the usage of
this `name_get` didn't take this into account. The only example of
this is the `name_get` of `product.product`
(now use `", ".join(<names>)`).
Part-of: odoo/odoo#122085
Purpose: In order to increase visibility of the interviewer group,
it is moved from hidden group, to recruitment group.
Moreover, we grant the interviewer additional rights in order to manage
the application process properly and be able to execute following actions
• Send an interview
• Check interview results
• Add/delete/modify skills
• Create a meeting
In order to allow above mentioned actions on skills to the interviewer,
we grant them all the rights to the hr_applicant_skill.
In order to let the interviewer send the survey we grant them access to
the private addresses and now recruitment-interviewer implies
survey-officer group as well.
Additionally, for the security purposes, we make a change, so that
the survey officer is not able to read recruitment interview results
unless they are also an interviewer for a specific applicant.
task - 3179332
closesodoo/odoo#118897
Related: odoo/enterprise#40696
Related: odoo/upgrade#4624
Signed-off-by: Kevin Baptiste <kba@odoo.com>
- kanban view progressbar based on status
- new first column 'New' with the welcome mail template
- create date column renamed to 'applied on' and moved to front
task 3346175
closesodoo/odoo#123293
Related: odoo/enterprise#42098
Signed-off-by: Kevin Baptiste <kba@odoo.com>
In this commit, We have added the sequence field so that the user can
easily reorder the Refusal Reason.
task-3336247
closesodoo/odoo#122429
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Purpose:
When the applicant is unarchived, they are automatically set back to
first stage. This is done automatically. In case there is automated
message post configured for that stage change, it will send the mail to
the applicant. We want to avoid this.
After this commit, the automated message related to the stage change
will not be posted in case the applicant has been just unarchived,
even if it is configured for the stage.
task - 3267915
closesodoo/odoo#120506
Signed-off-by: Kevin Baptiste <kba@odoo.com>
The fix introduced in odoo/odoo#114903 created another issue: changing
the work email would change the private email also, breaking the
seperation of the contacts for the employee.
The initial behavior was correct:
- a res.partner for the work details (email, phone, etc.)
- a res.partner (of type private) for the personal details of the
employee.
task-3284664
closesodoo/odoo#122880
X-original-commit: 290465e57dfcb8503e382a418e0ba4498ea5693b
Signed-off-by: Kevin Baptiste <kba@odoo.com>
And open interview forms on a new tab as well
task - 3293231
closesodoo/odoo#120903
X-original-commit: 7bed47dc59ae8c88048e585f0104db70b76a7f28
Signed-off-by: Kevin Baptiste <kba@odoo.com>
The action `Create Employee` on an applicant would open the form view
with the fields pre-filled, but the employee would not be automatically
created when leaving the view.
task-3301176
closesodoo/odoo#120566
Related: odoo/enterprise#40835
Signed-off-by: Kevin Baptiste <kba@odoo.com>
The fix introduced in odoo/odoo#119017 was no longer taking into account
the refused/archived applications, showing a negative number in some
cases.
task-3293460
closesodoo/odoo#120426
X-original-commit: 55e279f96c9d878103657f437222066ae74dcf0f
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Prior, application_count was computed in batch. In order to do
so, the complex query was used, which can be error prone.
As the field is only used for smart button on the form, we can assume
that the method will be called for one record at a time, thus using ORM
methods will not make big difference in terms of speed, while it is more
elegant and secure.
Note: that we still need to have _compute_application_count in batch,
as it is a compute method.
task - 3266694
closesodoo/odoo#119373
X-original-commit: 8480a6a6da8ef319047d11be489f546d368dfc56
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Previously, the "Other applications" smartbutton was incorrectly
matching with the applicants with '' on the fields. We don't want
applicants to match if both of them has '' on the matching fields.
Moreover, record rules were not correctly applied for application_count
calculation, as current record will not match with similar record
which has no company defined on it.
This commit fixes the above mentioned issues.
task - 3266694
closesodoo/odoo#118805
X-original-commit: e8263e56423432e9465f70d26fce60c021eabaa2
Signed-off-by: Kevin Baptiste <kba@odoo.com>
*: account, crm, hr_recruitement, im_livechat, point_of_sale,
project, sale_management, website_sale
Purpose
=======
Now, the KPI are computed based on their `company_id` and not based
on the current company. If no company is set on the digest, we compute
it based on the current company.
The KPIs are computed based on their company. Most of the time, they
will all belong to the same company so we can improve the performance
by computing them in batch.
Task-2827996
See odoo/enterprise/pull/27658
Part-of: odoo/odoo#91945
Steps to reproduce:
- create a new job application;
- click on the 'CREATE EMPLOYEE' button;
- save.
Issue:
Two contacts have been created.
Cause:
When creating an employee from a applicant, if the applicant does not have a linked contact, one is created.
Then, when validating the creation of the employee, we will create a contact if he does not have a contact linked to him in the `work_contact_id` field.
Therefore, two contacts will be created.
Solution:
Different information will be put in the context when we are redirected to the form view for the creation of an employee and in particular `default_applicant_id`.
If a current applicant is detected when creating an employee, we are certain that a contact already exists (because it was created previously).
In this case, the contact linked to the applicant is added to the employee's `work_contact_id` field to avoid the creation of another contact afterwards.
opw-3208808
closesodoo/odoo#116663
X-original-commit: 84507e03e47d49ee32ca4693bba8dcc22b772b1a
Signed-off-by: Kevin Baptiste <kba@odoo.com>
The purpose of this key was to force the form view to be in edit
mode directly when opening a record, in specific actions. This is
now automatically the case since form views are always in edit
mode. This commit thus removes the support of the key, and removes
all occurrences where it was set in the codebase.
Part of task 3179751
closesodoo/odoo#115172
Related: odoo/enterprise#38130
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
According to Wiktionary, French spacing is "the archaic practice (though
still current in French) of inserting a space around colons, semicolons,
question marks, and exclamation marks". This is not standard practice in
English and most languages of the world.
The purpose of this commit is to start purging the code from this typo,
as it may reflect poorly on the software for some people.
closesodoo/odoo#114533
Related: odoo/enterprise#37853
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Add mail.thread.main.attachment in the inheritance chain of all models that
use the main attachment feature.
Note that we remove the main attachment from crm_case_15 of the demo data as
crm_lead doesn't use that feature.
Task-2648976
Part-of: odoo/odoo#110734
Don't ask for the refusal reason when archiving an applicant.
Show a pill/ribbon for archived applicants.
task-3172203
closesodoo/odoo#113474
Signed-off-by: Kevin Baptiste <kba@odoo.com>
This reverts commit 15865cffb5 introduced
in odoo/odoo#93840.
This change was causing issues with applications received from job
boards (like LinkedIn), the same partner is assigned to the applicants
and changing the email address of one of those applicant was repercuted
on the partner and thus all the applicants.
closesodoo/odoo#110171
X-original-commit: 72c62dbf157dfb353caf13a228921e3f81036885
Signed-off-by: Kevin Baptiste <kba@odoo.com>
RATIONALE
Improve usage of composer in comment or email mode: support batch-posting in
comment, support more configuration from templates, improve global model.
SPECIFICATIONS
Change 'auto_delete_message' into 'auto_delete_keep_log' that has the inverse
meaning. Indeed it is unclear what 'auto_delete_message' really does. It is
used when automatically removing emails sent through mass mailing, to know
if message created through inherits are kept or not. Purpose of keeping them
is to have a log on the document. Deleting the message therefore removes the
log.
In this commit we change the meaning to something positive, keeping logs being
clearer when choosing which option to activate. Functional usage of the field
itself does not change with this commit.
Task-3035101 (Mail: Support batch-posting from composer)
Part-of: odoo/odoo#99482
RATIONALE
Purpose of this commit is to cleanup main post helpers and have a more easy
and understandable way of calling them.
SUMMARY
We now have two main API methods, based on business flow: either posting
on documents, either sending a mass mailing. Indeed those two flows are
different
* post: create message, then launch notification process by taking into
account subtype, followers, ...
* mail: create mails in batch with recipients being based on template or
given partners. No notifications is involved, only maybe traces if a
mass mailing is linked
Delegate QWeb rendering to the render mixin (i.e. _render_template_qweb_view)
in order to have a single point to forge evaluation context and re-use
existing rendering code.
SPECIFICATIONS
Main API helpers are now
* ``message_post_with_source``: (batch) post on records, using an ir.ui.view
(given a record or its xml id) or a mail.template record (given a record or
its xml id). When using a template, a composer is called to post on each
record (as batch post is not yet supported). When using a view, a direct
call to message_post using the rendered bodies is done, one record at a
time.
* ``message_mail_with_source``: send a mass mailing on records, acting like
invoking the mail composer in mass mode. Same arguments are valid, either
a reference to a view, either a reference to a mail template.
Other helpers are
* ``_message_log_with_view``: (batch) log on records, using an ir.ui.view
to render the body using QWeb (no notification process);
* ``_message_log(_batch)``: (batch) log on records (no notification process);
* ``message_notify``: notify partners on records (creating notifications
specifically for some people while message itself is not displayed in
chatter);
Code migration
* ``message_post_with_template`` in "mass mode": use ``message_mail_with_source``
and set the template record as source;
* ``message_post_with_template`` in "comment" mode: use ``message_post_with_source``
and set the template record as source;
* ``message_post_with_view``: its main usage was to post on a document, in which
case it generally can be replaced by ``message_mail_with_source`` using
the view reference as source;
Task-2710804 (Mail: Clean MailThread Posting API)
Part-of: odoo/odoo#99482
RATIONALE
Purpose of this commit is to be explicit in subtype chosen when invoking the
message composer / calling message_post. As default value may not always be
clear, better be explicit in case the composer default value changes.
SPECIFICATIONS
Add explicit references to subtype when it is not obvious what will be the
final subtype, notably when using helpers (post_with_view or template which
uses the composer that is not crystal clear in its subtype management).
In this commit we also add support of XMLID-based subtype when invoking the
composer. A ``default_subtype_xmlid`` context key is transformed into a
``default_subtype_id``, to be used notably in JS where we cannot easily
use a ``ref``-like statement. Post API now also supports 'subytpe_xmlid'
argument allowing to give the xml id and ease calling the methods.
Use ``_xmlid_to_res_id`` to get directly the ID of subtypes in order to
avoid useless queries from ``ref`` that does an exists.
Also remove useless values given to post API, notably author_id that is by
default the current users' partner.
Task-2710804 (Mail: Clean MailThread Posting API)
Part-of: odoo/odoo#99482
Before this commit, recruitment models and views were mostly
set inside 'hr_recruitment.py' and 'hr_recruitment_views.xml'
respectively. In order to navigate easily, models are separated
into distinctive files.
closesodoo/odoo#105935
Related: odoo/upgrade#4048
Signed-off-by: Kevin Baptiste <kba@odoo.com>
in the model/view the name of the field is Applicant's Name and in the user error message the warning is shown as Contact Name, improving the message for easy and better understanding for the end user
closesodoo/odoo#107498
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Some cases require usage of Markup in order to correctly display HTML content
and avoid escaped or invalid statements.
Fix: in hr_recruitment, support default_job_id from context, easing display
of job's alias in empty list helper.
Task-3074357
closesodoo/odoo#106061
Related: odoo/enterprise#34139
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Purpose is to cleanup code: stop using help parameter name (use help_message as
help is a keyword), try to call super(), ...
Task-2710804 (Mail: Clean MailThread Posting API)
Prepares Task-36879 (Mail: Support MultiCompany Aliases)
Part-of: odoo/odoo#105992
If an applicant goes through the salary configurator
to create his contract, the employee created will not get
the associated sign requests nor the skills as it is working
now when creating an employee from the "create employee"
button on the applicant page.
Also fixes:
- a traceback obtained on the salary configurator
when having hr_contract_salary installed and
not hr_work_entry_contract
- a traceback obtained while trying to access an applicant
form while in debug mode
task-3002185
closesodoo/odoo#104320
X-original-commit: 20d5de3490baaab62715fe0f4f2a9a48dc248d55
Related: odoo/enterprise#33332
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Purpose: The number of 'Late activities' are displayed on the kanban card.
The number excludes the activities for the hired applicants. Yet, once we
click on it, we are redirected to the activity view, which included the
later activities. On the one hand, this is not consistent, but on the
other hand, one might still be interested in those activities later on.
Thus the best way out is to put the filter for the "Running Applicants".
This filter will filter out the applicants in hired stage, but if we are
interested in them, one could just remove the filter.
task - 3001375
closesodoo/odoo#102691
X-original-commit: 16e025de14be3ace07191ab153259ed17b174748
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Signed-off-by: Gvaladze Sopiko (sgv) <sgv@odoo.com>
Currently clicking the 'Other applications' smartbutton on an
application redirects to a kanban view that does not have very useful
information.
With this commit, this smartbutton now redirects to the application list
view and adds small UX changes to this list view.
task-2946398
closesodoo/odoo#99828
Signed-off-by: Kevin Baptiste <kba@odoo.com>
When hr_recruitment is installed and a user doesn't have any recruitment access, an access error is raised.
This commit fixes the access error, allowing the user to access the hr departments view when hr_recruitment is installed and the user has no hr_recruitment access.
task-2971553
closesodoo/odoo#99591
Signed-off-by: Kevin Baptiste <kba@odoo.com>
From the applicant page, there is no way to access the related partner's page.
If you made an error on the email address before creating the partner and you wish to update it,
it will not be updated on the partner's mail address, which is used to send the signature request.
taskID 2880904
closesodoo/odoo#93840
Related: odoo/enterprise#28502
Signed-off-by: Kevin Baptiste <kba@odoo.com>
hr_*:
hr
hr_contract
hr_recruitment
website_hr_recruitment
Increase UX and possibilities to postulate to a job on recruitement.
Also moves the model hr.contract.type from hr_contract to hr so that it
can also be used from hr_recruitment without having two models in parallel.
taskID 2898063
closesodoo/odoo#96551
Related: odoo/enterprise#29777
Related: odoo/upgrade#3861
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Purpose
=======
Currently, only email sending can be scheduled with the `scheduled_date` field
defined on on <mail.mail>. It's not possible to delay the sending of
notifications.
We want to be able to delay the sending of the emails, but also the inbox
and bus bus notifications.
Technical
=========
For that purpose, we created a new model which stores the message we need to
notify with the scheduled date. When a scheduled_datetime is given we skip the
notification process. Instead an entry in that new model is created. A cron
regularly polls the scheduled message and launch the notification process on
messages that are ready to be sent.
Task-2207626 (Rating: Delay rating notification to ease feedback)
Part-of: odoo/odoo#95623
Co-authored-by: Thibault Delavallée <tde@odoo.com>
This commit aims at removing unuseful help message to:
1/ reduce translators work, to focus on more useful translations
2/ not sending unuseful information in load_views
3/ reduce help message to useful messages, so that we can mark
fields having a tooltip in the future UI.
4/ some cleanup of existing messages too
The main use cases:
- REMOVED: help redundant with the field name, providing no extra info
- MOVED TO COMMENT: technical help messages, that should not be in UX
closesodoo/odoo#97279
Signed-off-by: Fabien Pinckaers <fp@odoo.com>
The interviewer field was added by #78622, and adds access control for
`hr.applicant` based on whoever was assigned as the interviewer.
Due to the access control implications, it's useful to track the value of
this field in the applicant history.
closesodoo/odoo#95432
X-original-commit: 4b9447972009aa56ddacdba8eba4f7686537a753
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Move the definition of class Query to odoo.tools, in order to avoid
circular imports when importing Query in core Odoo modules.
Also reorganize imports in the impacted modules.
Part-of: odoo/odoo#66938
1f7c83cc3e renamed _notify_compute_recipients to
_notify_get_recipients. This function was not renamed with it so
members of the hr_recruitment.group_hr_recruitment_interviewer group
were receiving chatter they shouldn't be receiving.
The test didn't catch this because:
- the interviewer was not subscribed and thus never received email,
- MockEmail._filter_mail got passed status=False instead of None,
which always made it return an empty mail.mail recordset.
opw-2898730
closesodoo/odoo#95004
X-original-commit: 4dd9d3ee6fb261fd856036ced35bfb15b302b0b7
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
This commit aims to improve the recruitment reports clarity,
particularly the confusion between source and medium
TaskID : 2837445
closesodoo/odoo#90975
Related: odoo/enterprise#27148
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Purpose
=======
This commit add an option on the configuration to install the enterprise
module to scan and import CV information on the application form.
closesodoo/odoo#92019
Related: odoo/enterprise#26687
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Yannick Tivisse