Problem
-------
Recruitment pipe is design to work better if you archive the
lost/refused candidate rather than moving them in a specific column
this practice is reinforced by hr_referral.
Therefore, the other application button should take into account
archive applicant
Solution
--------
- count archived applicant
- show archived applicant
closesodoo/odoo#63982
X-original-commit: f242160eb06067ad56dec1c9acfbfe068ad1c6a1
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
- create 2 applications in Odoo Recruitments with the same email
- Notice how they both have a stat button that indicates that this
applicant has another application.
- Refuse one of the 2 applications
The stat button disappear because it ignores archived records, while it
should indicate if someone has already applied in the past
opw-2423158
closesodoo/odoo#63926
X-original-commit: caaef5829b51f7e5862a6d730ea978e19deadd42
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: agr-odoo <agr-odoo@users.noreply.github.com>
If a job position has a default recruiter, when applying for this job, the application's recruiter is not the correct one.
To reproduce the error:
(Need hr_recruitment,website_hr_recruitment)
1. Go to Recruitment > Configuration > Job Positions
2. Create a new one
- Fill in the Recruiter field
3. Save it
4. Click on "Go to Website"
5. Publish the job position
- Top bar: click on "Unpublished"
6. Log out
7. Go back on the job position page
8. Apply
9. Log in
10. Open the Recruitment module
11. Check the applications for the job position
=> The application is created, but the associated recruiter is not the one previously set (step 2 above).
This fix makes sure an application has the correct recruiter when the associated job position recruiter is defined.
OPW-2387888
closesodoo/odoo#62038
X-original-commit: b7deda4185e3c240c3c30c9a570dc7173f9d8aa3
Signed-off-by: adwid <adwid@users.noreply.github.com>
WHY: odoo translation framework still cannot properly handle terms that have
different translations, so we need to avoid english terms with double meaning.
Also, this improves term understanding for translators.
---
closes odoo/odoo#61668
Discussion: #60765#61272
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
The open_action_with_context was not using _for_xml_id, producing an
error when reading the action content.
In open_action, the action_name was taken from the context and needs
sanity checks. Ensure only actions from the account module can be
read and only if the user has access to the target model.
This is a limitation of the previous behaviour but, at the moment, all
known calls are made refering to an action from the account module.
Limit the scope of this method while the 14.0 is still early to avoid
having a door open to ready any action, and difficult to close later.
Remove old action fetching from the context in create_move that is no
longer used.
closesodoo/odoo#61602
X-original-commit: a39e94f7e4dc74e850650ac90bbc5f85af130bc8
Related: odoo/enterprise#14695
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Co-authored-by: Xavier Morel <xmo@odoo.com>
Currently, when got to applicant view and quick create the applicant
in the kanban view there is traceback for department_id.
becasue department_id is computed field which depends on job_id
and it was not set as False due to filter on self.
So in this commit, If job_id is not there then department_id
should be set as False.
closesodoo/odoo#56796
Taskid: 2320885
X-original-commit: 2ec35b724e5ac985a4baef85b96dc3411a828762
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Currently, when creating job postion from config menu then
it will generate the traceback of key error.
So in this commit, If job id found in result then assign the
documents_ids of that job else set the false.
TaskID: 2283753
Use _for_xml_id to replace all the self.env.ref().read()[0]
This has the advantage of having a single point of control and to add
the fields filtering and model verification.
Add sudo for other operations on ir.actions.*
/web/action/load is the public controller that Should be used by the
webclient to fetch actions
_for_xml_id is the default access method on actions that implements
fields filtering to avoid leaking server action code or other
information not needed by the webclient
Implementing whitelist of fields that can be access per model
b8359c55e6e57035ffa3b10bfa5294e22a74e837
An user with recruitment/officer (user) permission on hr_recruitment
could not create applications anymore because doing so imply a write to
hr.recruitment.stage
opw-2305646
closesodoo/odoo#55805
X-original-commit: 01fbb34213358f216011ae5b1c1fd6ec8dd80bdf
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: agr-odoo <agr-odoo@users.noreply.github.com>
Added a new tour for the module hr_recruitment
Hr.job:
Form view:
- Using a notebook view for increased clarity
Kanban view:
- Added a toggle button to publish/unpublish a job offer.
- In the menu, added the « Create Interview Form » button to create an interview form.
Hr.applicant:
Generale:
- Use of the "Applicant: Acknowledgement" template by default when an application is moved to the "First Interview" stage.
Form view:
- Possibility to consult an interview after this one and not before
- The "CREATE EMPLOYEE" button no longer directly creates an employee. The employee will be created if the "SAVE" button is pressed.
Hr.employee:
Generale:
- Added of two new certifications.
And some other minor style and name changes.
closesodoo/odoo#55928
Related: odoo/enterprise#12420
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Currently in the job's stat button and on kanban button the archived
applicants are not counted and not display while click on button.
So in this commit, count of the archived applicant's in form views
and show the archived applicants when clicked on stat button.
also curently there is no indication for applicant is refused or not
so in this commit add badge on kanban and form for archieve(refused)
applicant.
we should not count the archived applicantion in the kanban
button.
closes odoo/odoo#55755
Taskid: 2308448
Closes: #55104
X-original-commit: d272d0bbaa5847753236bbee11bff94683cb66f4
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
When someone is applying to any job position from the website
( via the `/website_form/` route ), the `hr.applicant` record
is created by OdooBot, and in such case, the `_compute_user`
method is never triggered as the field `user_id` (Responsible)
already has self.env.uid as default value.
This fix will in priority try to set a proper Responsible (if any
is defined on the job position) via `_compute_user` and then
assign `self.env.uid` if none is found.
closesodoo/odoo#55146
X-original-commit: e9292cb424ec04823dbce964ad4532edc20190c6
Signed-off-by: Toufik Benjaa (tbe) <tbe@odoo.com>
After 9ddfc18b41
an user with recruitment/officer (user) permission on hr_recruitment
could not create applications anymore because doing so imply a write to
hr.recruitment.stage
opw-2305646
closesodoo/odoo#55222
X-original-commit: b8359c55e6e57035ffa3b10bfa5294e22a74e837
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Before this commit:
If a template_id is put on the first stage, a partner is
automatically created at the creation of the applicant. And if the
applicant had a phone or a mobile, they are removed.
After this commit:
The phone and mobile are saved on partner and not removed from
applicant.
taskId 2299970
closesodoo/odoo#54574
X-original-commit: 3735c3363f422d01ae1ff96e761a1b206fc32a69
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Signed-off-by: jbm-odoo <jbm-odoo@users.noreply.github.com>
Using a few regex like
\((_\(.*%s.*)(\) % )([\w\[\]][\w .\[\]\(\)'"]*)\)
($1, $3))
Old syntax is still compatible but starts the migration to the new
syntax that catches error.
PURPOSE
Make digest email and tips more appealing. The goals of these tips are
* to encourage the adoption of other apps (Did you know ?);
* to make Odoo look more fun (Fun tips and tricks, young and dynamic style);
* to show social proof and increase trust (emphasis on already existing
projects / customers to);
SPECIFICATIONS
Digest now use qweb views instead of a standard mail.template record for
rendering as
* template is very custom;
* probability of breaking it while edition the mail template is high;
it is easier to maintain and extend in qweb;
* only body was really used, other mail-related fields were not used;
We therefore remove the mail template data and the field used for it on
the digest model. Template is now forced to a Qweb view.
We can also remove the template_id field. Indeed we think that having
different templates for digests is a really advanced use case we do not
want to support.
Finally kpis and action computation is rewritten. It now returns an unique
structure containing all information in a more neutral way, holding values
for 3 columns. Purpose is to be less date-oriented in data construct and
allow people to use digest qweb template to display a 3-columns KPIs content
even if not related to yesterday / last 7 days / last 30 days.
LINKS
Task ID 2197417
Community PR odoo/odoo#51619
Upgrade PR odoo/upgrade#1256
Multiple small changes/fixes to the hr_recruitment module to provide
a better base for later improvements.
The linkedin recruitment source is only added by default to new records,
existing records remain unchanged.
For the google map in the email template, since it requires an API_Key and
only a minority of companies will get this key, it was decided that
it is better to remove it from the template.
Now that linkedin is added to job positions by default, deleting a
job position currently does not delete the related linkedin source.
So after removing 10 job positions, there are still 10 linked in
source in the database. This commit fixes that.
Add three additionnal utm_sources.
Add linkedin as a source job to demo job position to be consistent with no-demo
data db.
closesodoo/odoo#50076
Taskid: 2196767
Related: odoo/enterprise#10778
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Purpose
=======
For a tag to be displayed on a kanban card, it needs to have a color set.
We won't be changing that behaviour, since it would mean having
two options > the color, and whether or not to show it in the kanban
The purpose of this task is to set a color on new tags to make the user
save a bit more time, set a color for him as he might not find the feature,
and make sure the tag will be on the kanban cards.
Specification
=============
For each of the following models, at creation, set a random integer between
1 and 11 in field 'color'
Models:
res.partner.category
crm.tag
project.tags
hr.applicant.category
helpdesk.tag
hr.employee.category
event.track.tag
mrp.eco.tag
repair.tags
closesodoo/odoo#49967
Taskid: 2234527
Related: odoo/enterprise#10112
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
PURPOSE
Several counter fields are performed inefficiently. They use compute methods
using length of 2many fields instead of making use of more efficient ORM
methods like read_group.
SPECIFICATIONS
No functional change, only technical performance improvements. Purpose is to
improve meeting count performances.
An index on applicant is also added to speedup queries.
LINKS
Task ID 2196182
PR #44662
Co-Authored-By: Victor Feyens <vfe@odoo.com>
Co-Authored-By: Thibault Delavallee <tde@odoo.com>
Impacted modules:
hr, hr_contract, hr_recruitment, hr_payroll, fleet, hr_skills, hr_appraisal, ....
Several onchanges have been converted to computed fields in the following modules :
Community :
- hr
- hr_contract
- hr_recruitment
- hr_work_entry
- hr_maintenance
- hr_expense
- hr_expense_check
- hr_holidays
- sale_expense
- account_analytic_default_hr_expense
Enterprise:
- hr_contract_salary
- hr_referral
- hr_payroll
- hr_payroll_expense
- test_l10n_be_hr_payroll_account
There are still 2 onchanges with complex behavior that couldn't be converted easily:
- an onchange that updates "tz" (timezone) that is defined as a related field
to "resource_id.tz". Apparently it is useless except to initialize the default
value of "tz".
- an onchange that updates "name" that is defined as a related field to
"resource_id.name".
the applicant.
closesodoo/odoo#45414
Taskid: 2169099
Related: odoo/enterprise#8572
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Clean the usage of mail aliases and more specifically its associated mixin
`mail.alias.mixin` .
Stop using context for model of aliases, and correctly give model_id and
parent_model_id to the call chain through a cleaned code easier to override.
We also merge methods get_alias_model_name and get_alias_values in single one
called before record creation (alias first values) and right after (to have
values depending on actual record).
LINKS
Task ID 1919277
Community PR odoo/odoo#41160
Enterprise PR odoo/enterprise#6983
Upgrade PR odoo/upgrade#872
Co-Authored-By: Rémy Voet <ryv@odoo.com>
Co-Authored-By: Thibault Delavallée <tde@odoo.com>
Purpose of this commit is to clean manual alias creation by correctly giving
field values instead of relying on magic from model_name to model_id. Code
is more understandable now.
Task ID 1919277
Community PR odoo/odoo#41160
Enterprise PR odoo/enterprise#6983
Upgrade PR odoo/upgrade#872
Co-Authored-By: Rémy Voet <ryv@odoo.com>
Co-Authored-By: Thibault Delavallée <tde@odoo.com>
Purpose
=======
In the Recruitment app, when a new applicant is created and moved staged,
an email may be sent according to the stage configuration.
If the email is not found in the database, a partner is created.
The new contact is now visible and available to the rest of users
(for example can be selected as a customer on a SO), which is a potential
security risk as only HR employees should be able to see this
applicant information. There should be a way to limit the access to this
applicants Contact, for example defaulting the type to private rather
than contact.
Specification
=============
The created partner should be of type private.
closesodoo/odoo#46351
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
- Create 2 applications with the following emails:
'test@test.com'
'test@test.com '
The 'Applications' stat button doesn't match the 2 applications.
Since `_compute_application_count` uses a `read_group` for performance
reason, we choose to strip the value at create and write for the sake of
simplicity.
opw-2189965
closesodoo/odoo#45613
X-original-commit: 00cfc324134b289417ba25373d472ba7cce4c78f
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
PURPOSE
Clean posting process and improve mail.message definition and comprehension.
SPECIFICATIONS
In order to be more explicit subtype parameter is renamed to subtype_xmlid.
It therefore clearly indicates it should be a valid subtype Xml ID. Support
of ill formatted Xml IDs is removed because there is no reason to try to
add some random prefix. Give something that exists or go to hell, punk !
LINKS
Task ID 2071556
PR #38692
The current 'Newly Hired' filter is incorrect in several ways:
- the compute method doesn't assign the value correctly
- the search method mixes `hr.applicant` IDs with `hr.employee` IDs
Moreover, it relies on the fact that the job position is closed. Some
positions might always be opened, so the result is inaccurate.
We make the simpler assumption that the newly hired people are employees
created less than 90 days ago.
opw-2125861
closesodoo/odoo#40899
X-original-commit: ee928babbe433285883f1e878d83392d7199a37d
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
When clicking on stat button "Meetings" on a partner, just highlight the
partner meetings as is done for similar stat button instead of having
a domain that hides other event (so when creating meeting, we can take
into account other existing meetings).
A similar change with same reasoning has been done for "Meetings" stat
button of hr.applicant records.
opw-2131494
closes#40812closesodoo/odoo#40900
X-original-commit: 957e7eb77ed18e4a1c14ef4ef55bd54503c56f44
Signed-off-by: Nicolas Lempereur (nle) <nle@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>
Purpose
=======
Like in crm, having a refusal reason to get some metrics on recruitment
+ recruitement dashboard
id=2003841
closesodoo/odoo#38467
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
The default `compute_sudo=True` makes sense for recomputing stored
fields that are indirectly related to a business operation. This
ensures that the recomputation of the field does not break an operation
that is not aware of the fields to recompute.
However, computing non-stored fields in superuser mode is usually not
necessary. It even leads to unexpected values: counting a partner's
sales orders does not give the same result in superuser mode as in
normal mode. That is why non-stored fields are not computed in
superuser mode by default.
[FIX] account, delivery, event, hr_recruitment, point_of_sale, stock:
adapt the model definition to make all fields with the same compute
method have the same value for `compute_sudo`.
[FIX] sale: split the computation of `invoice_ids`, `invoice_count`
(non-stored) and `invoice_status` (stored), as no code is actually
shared.
closesodoo/odoo#39195
X-original-commit: 843fd38a97f02b49dc09d7f55919072d272fd80e
Signed-off-by: Olivier Dony (odo) <odo@openerp.com>
Somehow followup of dbb6cfdbf8 . Purpose is
to use formataddr from tools instead of manually handcrafting the full
email address format. Indeed the tools one correctly encapsulates and
format name and email.
Task ID 2068986
When recruitment is duplicated, `emp_id` should not be copied for obvious reason.
closesodoo/odoo#38442
X-original-commit: 68820340ce4adc5a31df23f0b5ff2c715a695fdc
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>
Purpose is to make field use more obvious by correctly stating in the
name it should contain an xml id to a qweb layout used for email
notifications. This renaming is propagated through various calls and
addons.
Related to task 1943901
Linked to PR #32404
Message post should always be called on a record (ensure_one). That way we
ensure posting a message is always done in a record's context with right
values computed (reply_to, followers, ...)
Message_notify can be called on record or on mail_thread and must have
partner_ids. It is based on the recently modified user_notification mechanism
and allow to notify a partner on a record or just to push him a message
(aka, not linked to a record).
Small performance improvement
* browse recipients instead of search in _notify_email_recipients;
* todo in future optimizations: mayybe be improve by searching on ids
and is_blacklist immediately;
Related to task 1943901
Linked to PR #32404
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
The goal is to be coherent with the user property.
Actually, company_id and company_ids on the environment are no fields.
Calling env.company_id returns a browse record, not an id.
When we change job_id on an applicant, we want that the stages above
change (if there arre special stage for this job).
On website recruitment, a traceback prevent to complete the form to
apply for a job.
closesodoo/odoo#34981
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Thibault Francois