Creating employee from applicant was not providing the default
home_address_id
closesodoo/odoo#81121
X-original-commit: 68cdf057a9e769071fab6726eaf3b37d16959bf1
Related: odoo/enterprise#23443
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
It is more intuitive that application_count smartbutton has
the label 'x Other applications'.
task - 2695252
closesodoo/odoo#80551
X-original-commit: f1a2f51fec0a31b80a20c78a5b3d11561dce7164
Signed-off-by: Kevin Baptiste <kba@odoo.com>
PURPOSE
This commit consolidates UTM usage across all applications.
Global purpose is to avoid having undesired side-effects, such as unlinking an
utm.source/utm.medium/utm.campaign and at the same time cascading the deletion
to various records without noticing.
SPECS
ALLOW MORE PEOPLE TO CLEAN UTM RECORDS
Currently, not even the system administrator can delete utm.mediums and
utm.sources (he can only delete campaigns).
These were considered as "technical records", but allowing some cleanup is
a good idea since these records are often automatically generated and can
create a lot of unnecessary noise in the database.
That's why we now allow the following groups to delete all UTM records
(sources, mediums and campaigns):
- group_system
- group_mass_mailing_user
- group_social_manager (enterprise)
PREVENT DELETION
For some use cases, removing an utm.source/utm.medium/utm.campaign would
cascade delete the related record, which was unintended / hidden side effect.
These combinations were secured by preventing to unlink:
- mailing.mailing source_id field
Trying to delete the utm.source will throw an error message
- mailing.mailing medium_id field
Trying to delete the utm.medium will throw an error message
- hr.recruitment.source source_id field
Trying to delete the utm.source will throw an error message
ADDING CLEAN ERROR MESSAGES
When trying to delete an UTM record that is linked with ondelete="restrict", we
improved the error message to give a clear explication to the user, e.g:
"You can't delete these UTM sources as they are linked to the following
mailings in the Mass Mailing APP, and deleting the source would break the
statistics: Newsletter"
SPECIFY 'ondelete' strategy
For a lot of uses of sources/mediums/campaigns, the 'ondelete' strategy was not
specified, leading to the confusion of "is this really how we want to handle
this?".
A lot of ondelete="set null" have been added in various field definitions to
ensure that this is the desired and logical strategy we want for that
specific model.
PREVENT REMOVING HARDCODED UTM RECORDS
In some functional flows, UTM records are hardcoded using their direct
record reference.
This is notably the case for the recruitment process and its creation of
aliases, and for the Email / SMS Marketing flows.
As deleting them would break these flows, we prevent their deletion in a
"api.ondelete" method.
ENFORCE NEW RULES WITH TESTS
A lot of python tests have been added to make sure we enforce the decisions
taken here above.
LINKS
ENT PR odoo/enterprise#19048
Task-2459480
closesodoo/odoo#72239
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Purpose
=======
Give the user a more organized view of the digest KPIs in the backend and
improve global wording of digest sections and KPIs.
Specifications
==============
Reorganize order of KPIs in digest view. Fix some typos, move buttons in
list and form views.
Task-2582128
closesodoo/odoo#77507
Related: odoo/enterprise#21340
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Improves the application count compute by ignoring case when matching
applications by email.
TaskId-2669835
closesodoo/odoo#78541
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Previously when creating an applicant through the calendar application,
no activity would be created making the newly created record not show up
in the calendar because it depends on the activities linked to the
record.
A calendar event will now be created upon creation through the calendar
view in order for the applicant to be displayed directly.
Also fixes an issue where if no contact is set on the application it
would prevent you from refusing it.
TaskId-2641495
closesodoo/odoo#76831
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Issue: When receiving a mail on a alias for a job position, the
application is created correctly in the right stage but the e-mail
template for that stage is not sent to the applicant
Steps to reproduce :
1) Set an alias and a external mail server
2) Configure incoming mail server
3) Create a job position with a mail alias and a email template
4) Receive a mail for that job position
5) The application is created but no mail is sent to the applicant
Why is that a bug:
When we create an application manually the mail is sent to the
applicant but when creating it via e-mail reception, it's not sent
even though it should. This is due to stage_id missing from the flow
when receiving an e-mail
opw-2533310
closesodoo/odoo#75721
X-original-commit: 108b1c30e6254f24564246c401ad50a983498066
Signed-off-by: Nathan Marotte <nmarotte@users.noreply.github.com>
Since a partner of the type private is created when
the partner is created at message post (see _message_post_after_hook),
most of the hr.applicant are linked to a partner_id of type private
And recruitment officer may not have the access to private address,
those user can get an access error while opening a form view of an
hr.applicant due to get_suggested_recipients called.
They are already able to see the email address and the name of the
applicant directly on the applicant form we can consider they should
be able to call get_suggested_recipients
closesodoo/odoo#75454
Solution: read the partner with sudo
X-original-commit: b916e8fd8347e77f2f2e15bf0473a0b3642436f9
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Remove read access on `ir.model`, `ir.model.fields`, `ir.model.fields.selection` and `ir.model.data` for employees.
To access such records, the code must use the helpers (`_get`, `ref`,...) instead of CRUD operations directly.
Simplify the helpers to ir.model.data that were public and redundant.
self.env.ref is encouraged instead but with the slight drawback that `ref` makes a call to `exists()` (`_xmlid_lookup` can be used if this wants to be avoided).
Part of task-id 8203
closesodoo/odoo#69120
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Assign the job recruiter to applications created through the email
alias.
Previously the email alias did not contain the recruiter's ID and the
application would not be assigned to anyone. This commit changes that
behaviour and also updated the alias creation values when the right
fields change, such as department_id.
The Alias should be kept synchronized with the job configuration.
Closesodoo/odoo#74236
Task ID: 2608541
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Multi-Application Management and UX improvements.
Improve in Recruitment app Job Positions Kanban view;
It is more intuitive if list is applications default view; improve the applications form;
Task - 2404610
closesodoo/odoo#63946
Related: odoo/enterprise#15750
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Change the text of the meeting smart button to be similar to the one
found in appraisals, it now also shows the date.
Closesodoo/odoo#72649
Task ID: 2578165
Related: odoo/upgrade#2642
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
When using the Add button on the calendar view introduced with
odoo/odoo#64948 the event would not be linked with the applicant.
After further investigation the method used to get the applicant id in
default_get was not flexible enough, the one from crm calendar has been
'copied'
Task ID: 2578165
closesodoo/odoo#73635
X-original-commit: f23e07dcb0606dbc4bf835b8266323d5a515662d
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Signed-off-by: William Braeckman (wbr) <Williambraecky@users.noreply.github.com>
Multiple improvement with job views:
- Add a sequence field for jobs
- Display 'Open Positions' on the website event if there is only 1 open
position
- Display whether the website is published on both the list and the
form views of hr.job
- Fix an issue introduced with 446d906f508880eb787debbec3c23cfd081bb045
where html field would be cut and html tags would be displayed
Minor change:
- Add an sql constraint on the estimated number of recruitment to be
positive
Task ID: 2581595
closesodoo/odoo#72769
Related: odoo/enterprise#19264
Related: odoo/upgrade#2585
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Previously the number of hired people in the reporting was based on
if they were in a folded stage or not. Adding this boolean allows the user
to decide which stage should be used for the computation of the number
of hired people.
Task-2462536
closesodoo/odoo#66761
Related: odoo/upgrade#2205
Related: odoo/enterprise#16644
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Purpose of this task is to improve the refuse reason action to sent
the email using the automatic template.
Currently, when using the refuse action,there is no mail template sent
to the applicant.
In this commit, we improved Refuse Reasons wizard by adding the
send mail inside the wizard with email template so user can select the
send mail option and rpvide the template or default template while
refusing th application.
- On selection of the refuse reason:
- If in the settings, the refusal reason have an email template,
the send mail checkbox is true, and template is displayed (can be changed)
- If the refusal don't have email template, send mail checkbox is
unchecked by default.
closesodoo/odoo#57722
Taskid: 2313402
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Co-authored-by: Mahendra Barad <mba@odoo.com>
Replace text fields to html fields as we have our own 'OdooEditor'.
Indeed, it gives more options to users in the way they format their
content without weighting too much on the UI
(tools appear on demand and not by default).
Models -> Fields
1) fleet.vehicle -> description
2) fleet.vehicle.log.contract -> notes
3) hr.job -> description
4) hr.contract -> note
5) hr.leave.allocation -> notes
6) hr.applicant -> description
7) lunch.product -> description
8) lunch.order -> product_description
9) lunch.product.report -> description
Task Id: 2499504
X-original-commit: afe52b050a7667f3f20696cd48cd922f635a941c
PURPOSE
Remove hardcoded list of models on which mailing is possible. Indeed it is
not modular and not really smart with enterprise code not being reachable
in community.
SPECIFICATIONS
Replace hardcoded list of models on which mailing (both mail or sms) is
possible by a computed searchable field on ``ir.model`` based on a class
attribute.
It allows to cleanly define models having mass mailing capabilities and add
this attribute in bridge modules (when existing) or directly on base model
definition to avoid bridge modules.
In this commit we introduce a basic ``_mailing_enabled`` class attribute
activating mailing on model.
Mailing models may also have a ``_mailing_get_default_domain`` method allowing
to define a custom default domain when sending a marketing mailing on records
on this class.
Mailing models can now define a ``_mailing_get_opt_out_list(_sms)`` method
allowing to define custom behavior to fetch opt-outed records. Instead of
defining a model-based behavior on Mailing itself, it now calls the model
defined one. We still have two methods, one for mailing and one for SMS
opt out computation as it relies on different underlying models and fields.
LINKS
Task ID-2431217
COM PR odoo/odoo#67322
ENT PR odoo/enterprise#16876
UPG PR odoo/upgrade#2236
Steps to reproduce the bug:
- Create a Job Application without Applied Job
- Refuse/Archive it.
- Restore/Unarchive it
Bug:
- KeyError raised due to missing `False` in `default_stage`
Fix:
- Add `stage_id` if Applied Job is selected on the application.
opw:2513147
closesodoo/odoo#70077
X-original-commit: b0dc16e44d027bf27ec501d922459bf0f1db8550
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Co-authored-by: simongoffin <sig@odoo.com>
Have an empty database
Install Recruitment
Employee>Departments>Administration(3 dots)>Recruitments
Missing record message raise
This occur because of an access to a record that may not exists
opw-2431929
closesodoo/odoo#66764
X-original-commit: 911aec8465a4a796297a465e96b3033d1c415628
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: agr-odoo <agr-odoo@users.noreply.github.com>
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>
Bayarkhuu Bataa