No need to hide the chatter to recruiters, as the salary configurator
has been improved to avoid posting sensitive data on the application
form itself.
TaskID: 3101400
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 made the following changes.
- Add new refuse reasons:
- Languages issues
- Role already fulfilled
- Duplicate
- Spam
- Refused by Applicant
- Modify refuse reasons:
- Refused by Applicant: don't like job
- Refused by Applicant: better offer
- Clickable job position breadcrumb in website.
- Set default applicant when we create new email template
- Use the `selection_badge` widget in Refuse Reason wizard
task-3336247
closesodoo/odoo#125612
X-original-commit: 94bc52e79e37df6daf9af6cb62efd65d63cbb61e
Signed-off-by: Kevin Baptiste <kba@odoo.com>
*: account, crm, crm_iap_mine, event, hr_expense, hr_holidays,
hr_recruitment, lunch, mail, mass_mailing, point_of_sale, project,
purchase, purchase_stock, sale, survey, web, website, website_blog,
website_event, website_forum, website_sale, website_slides,
test_main_flows
In odoo/odoo#111103 the tour system was rewritten. The previous tour
system used to depend on the `root.widget` js module, and this module
was an async module that indirectly depended on `session_bind` which
would load the translations, meaning that the js module definition code
of the tours would only run after the translations were loaded. This is
no longer the case with the new tour system, this means that the module
definition code is executed as soon as the dependencies of that module
are fulfilled, which is generally befoe the translations are loaded,
causing most tour tips to not be translated.
This commit adds a hacky workaround for this problem: it creates a new
module that has a default export which is a promise, and has a legacy
alias, this creates an async module that waits for the translations to
be loaded. This module is then imported for its side-effect in all
onboarding tours, causing them to be translated correctly once again.
This commit also needs to convert the steps key in the tours internal
registry to a getter. In previous versions, the steps were directly
added as is to the internal state of the tour service, but since
odoo/odoo#122834 the steps are now mapped, and without a getter, any
edits to the steps occurring after registration will not be taken into
account. This causes issues in some modules that change original
behaviour of other modules (eg accounting makes invoices into a menu in
the accounting app instead of a top-level app in the home menu) as they
need to edit the steps of existing tours to make them work.
In a separate PR, we will implement a more proper fix by changing the
API of the tour manager so that we no longer need this workaround.
closesodoo/odoo#125284
X-original-commit: d130699ba82dc9919c9116f4b64a5e461ebb6319
Related: odoo/enterprise#42655
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Samuel Degueldre (sad) <sad@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>
THese are rarely intended for all users but often intended only for
employees.
account:
account.incoterms: only used within internal business models
account.journal.group: same as account.journal, add sudo in computed field
account_edi: need access to accounting objects
base_address_extended:
res.city: only employees should access address data
board: only employees uses this (old) module
crm:
crm.stage: internal users business object
hr_recruitment: employees can read
im_livechat: apply same as for the steps
l10n_ar: used on partner, not only invoices
l10n_ec: accessed only through account.move
l10n_latam: accessed on res.partner
mail:
publisher.warrenty.contract: no data, only static models
mail.channel: group_user has already his own rule
mail.group: group_user has already his own rule
mail.message.subtype: group_user has already his own rule
mail.message.all: remove, already has a portal and employee rule
partner_autocomplete: no interaction with public
project:
project.tags: only needed for project sharing
sale_management:
sale.order.option: same as sale.order
utm: employee already has write access
web_editor: test models that have nothing to do here
web_tour: only employees uses tours
website_sale:
product.ribbon: add sudo for access
base:
ir.default: only employees uses set (could probably be converted to group_system)
ir.ui.view.custom: same as ir.ui.view, add sudo when needed
report.*: portal users don't configure reports
res.users.log: create in sudo, no access needed (adapt test to use another model)
res.lang: still needed for public
closesodoo/odoo#118701
Related: odoo/enterprise#41285
Signed-off-by: Martin Trigaux (mat) <mat@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>
For some reason, this is pbly the only action from a menu items that
opens a modal dialog instead of being the main actions. Other actions of
this kind are usually a wizard of some sorts - there is no reason to
behave that way to manage "persistent" data.
closesodoo/odoo#123598
X-original-commit: eecc22becb221ab5e5a476264920ca35eac9afa7
Signed-off-by: Bouvy Damien (dbo) <dbo@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>
Currently, only stable releases see their translations updated. This has
resulted in master accumulating outdated stuff for years, which can be
confusing for users testing master on runbot.
This one-shot commit resynchronizes master translations based on the
content from 16.0 and removes empty PO files (i.e. no longer containing
translations).
closesodoo/odoo#121629
Related: odoo/enterprise#41171
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Prior to this commit, the SVG's viewBox attribute was missing, which
prevented svgs from being scaled.
This commit fixes this issue.
task-3326633
Part of task-3326263
X-original-commit: 30300c373ad1c63a6cf8b035cae0785a09c6933f
Part-of: odoo/odoo#121886
The introduction of Milk has brought new app icons.
Using the svg format creates a lack of anti-aliasing on the edges of the
shapes, which makes the icons look bad.
Since the png size has been reduced, we can afford to use the png format
to have the best possible quality without having a lack of performance.
task-3326633
Part of task-3326263
X-original-commit: e07cb722f2b11407a3ad093bd688b7d37afd5a88
Part-of: odoo/odoo#121886
The shortcut to refuse an application is overridden by the shortcut to
move the record to the next statusbar stage
Steps to reproduce:
1. Install Recruitment
2. Go to Recruitment > Applications > All Applications and open any
application
3. Press and hold `alt`
4. The hotkey for the action 'Refuse' is shown (`x`)
5. With the `alt` key held, press on `x`
6. The application goes to the next stage instead of being refused
Solution:
Change refuse hotkey to `d`
Problem:
Commit https://github.com/odoo/odoo/commit/76b513917b4dad6eeecb4decac24e8c2d2c75b00
introduced a shortcut `alt+x` to move the record to the next state in
the statusbar. Because this shortcut has been chosen for its similarity
with shortcut `alt+shift+x` (Move to %s...), we prefer to change the
hotkey to refuse an applicant
opw-3206744
closesodoo/odoo#121395
X-original-commit: 37a9d552a5d581f14fd59728ea539726b1387f0b
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Signed-off-by: Guillaume Merlin (megu) <megu@odoo.com>
This commit fixes the ribbons used in `kanban` and `form` views.
The SCSS uses the square root of the parent `div.ribbon` to calculate its
diagonal width and applies that width to the child `span`.
After changing the ribbon's transform-origin, we calculate the ribbon's
position based on CSS variables of the view's top padding,the height of
the ribbon and the shadow's size (to avoid it being cropped by
overflow-hidden).
By changing the values of a few of these variables in the kanban view,
we were able to remove all the specific SCSS related to ribbons in the
modules.
Other changes were applied inside some of the modules to make this
work:
- `event`: padding corrections on the kanban's cards;
- `hr_holidays: replaced `margin:0` in the SCSS with negative margin
utility classes on the element to achieve the same visual result;
- `discuss`: moved the ribbon to the parent element;
- this was also done to `discuss`, `survey` and `helpdesk`;
- `crm_team_view` in `sales_team`: the ribbon's height made it overflow
from the kanban's card. We fixed this by changing the value of one of
the CSS variables in the view's SCSS file;
- the same thing was done in `survey` and `appointment`;
- `website_event_exhibitor` had some SCSS that wasn't being used because
it uses `.o_ribbon` instead of `.ribbon`
task-2818586
Part-of: odoo/odoo#116641
hr_recruitment: switch smart button value and label
- Switching applicant's name with "Employee" label to be consistent with
the rest of smart button's format
mass_mailing: adapt status bar layout
- Removed excessive margin between the status bar and the content
- Added no padding between status bar and the control panel
- Removed a useless border before the status
- Improved margin between alert and buttons
project: right side panel stats buttons alignment
hr_skills: fix `::before` alignment
== ISSUE ==
Before this commit, the :before line in Employee resume is not aligned
with the dots. This is due to the fact that the variable
$o-hrs-timeline-entry-padding used in the mixin isn't the right value we
should use.
There was also an issue with responsive.
== After this commit ==
We now use a calc, which process the half of the circle plus the padding
minus the border-width. The $o-horizontal-padding is the variable used
to define the padding of the line inside the form view.
We adapt this in a smaller media query since the $o-horizontal-padding
value is different.
task-2818586
Part-of: odoo/odoo#116641
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>
*: web + adaptations in base, fleet, hr, hr_expense, hr_recruitment,
loyalty, lunch, mail, mass_mailing, note, project, stock, survey,
web_tour
**Foreword**
Since d19037e141 the rootnode class attribute for form/list views was
copied two times:
- on the o_view_controller div
- and on the root node of the view renderer.
Examples:
<form class="foo">...</form>
gives
<div class="o_view_controller o_form_view foo">
<div class="o_control_panel">...</div>
<div class="o_content">
<div class="foo o_form_editable ...">...</div>
</div>
</div>
and
<list class="foo">...</list>
gives
<div class="o_view_controller o_list_view foo">
<div class="o_control_panel">...</div>
<div class="o_content">
<div class="o_list_renderer foo ...">...</div>
</div>
</div>
**Issue**
This could lead to confusion and also unexpected styling issues.
See this PR #119815 to read a message JS Framework team has received.
See also another a fix that had to be made for x2m fields: 980244fa8
**Introduced Changes**
- in the form compiler, the root node attributes are no more copied to
the root div node of the compiled template the form renderer receives
- the root div node generated by the form compiler now has the
"o_form_renderer" class, which was removed during the recent form view
refactoring.
- the list renderer no more adds the root node class attribute to its
"o_list_renderer" div
- the X2ManyFieldDialog has been adapted too
- since View, X2ManyField & X2ManyFieldDialog both need to compute view
classnames derivated from the arch root node, an util has been
introduced to avoid duplicating code
- the whole codebase has been checked and adapted.
Related: odoo/enterprise#40418
Signed-off-by: Mathieu Duckerts-Antoine <dam@odoo.com>
This commit adds two autoresize hooks for text inputs and textareas to
make it adapt their size (width for text inputs, height for textareas)
depending on their content.
The commit therefore solves the issue of several form view task titles
being restricted to 1 line while it can be annoying if the title is too
long. The autoresizeTextarea feature was moved from TextField to the
autoresizeTextarea hook and the autoresizeInput feature was moved from
the AutoresizeInput mail component to the autoresizeInput hook.
The TextField component has a new option for disabling linebreaks.
task-3138826
closesodoo/odoo#117355
Related: odoo/enterprise#39493
Signed-off-by: Géry Debongnie <ged@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
This commit converts almost all odoo module by native module.
The goal is to deprecate odoo.define in favor of native module and then
simplify boot.js by removing the regexp that finds module dependencies.
task id: 3162300
closesodoo/odoo#117305
Related: odoo/enterprise#39118
Signed-off-by: Géry Debongnie <ged@odoo.com>
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>
They dates from < 2027 and are quite outdated. Favour the nl
translation instead.
n_BE is not on Transifex so it was not possible to correct bad
translations.
closesodoo/odoo#115845
X-original-commit: d04c8b7e484db8306d858c891a7a2b11885fdcd9
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Yannick Tivisse