Steps to reproduce:
-------------------
- install `account` module;
- create an employee;
- add a bank account;
- add a related user and save;
- remove the user and save;
Issue:
------
A traceback occurs.
Cause:
------
We synchronize the `partner_id` of the `bank_account`
with the `work_contact_id`.
If the latter is `False`, this triggers an error.
Solution:
---------
Do not trigger the logic that updates the `partner_id` of
the `bank_account` if the value is `False`.
This keeps the logic that the `partner_id` field
in the `res.partner.bank` model is required.
opw-3558983
closesodoo/odoo#139570
X-original-commit: c19574e26d8814a745152489eb16915f13b2a6c0
Signed-off-by: Sofie Gvaladze (sgv) <sgv@odoo.com>
Signed-off-by: Thomas Lefebvre (thle) <thle@odoo.com>
Fixes a large number of cases where strings are translated then
formatted, instead of letting `_()` do the formatting internally,
which allows it to recover from incorrect translations (missing,
broken, or extra placeholders).
Also
- removes translation markers entirely when there's nothing to
translate e.g. `_("%s - %s")` is not useful
- fixes a few messes which lead to only partial translatability
(DRY is generally a bad idea when translations are involved, even
more so when you don't make the variable part translatable)
- fixes a few nearby issues noticed at the same time
- replaces a few `"%s"` by `%r`, which should automatically quote
strings relatively appropriately
- fixes translated strings which use `\` to escape a newline (in order
to fill-paragraph): `\` escapes only the newline, if the
continuation string is indented this results in a bunch of spaces
ending in the string to translate, which is pretty garbage for the
translator, using implicit concatenation works much better
Note: some of the updates revert f-string parameters to %, because
babel (2.9) apparently has trouble with f-strings and blows up trying
to extract them.
Not in scope:
Helping translators fix translatable strings e.g. any translation
string with more than one placeholder probably should use keyword
placeholders
- Provides more context / data to the translator to make sense of the
sentence.
- Allows reordering the translated terms, which can be necessary
depending on the sentence and language.
closesodoo/odoo#139314
Related: odoo/enterprise#49311
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Purpose:
--------
This commit adds properties (and related properties definitions) on the
following models:
- hr.employee (hr.department)
- hr_recruitment.hr_applicant (hr_recruitment.hr_job)
- product.product (product.category)
- stock.picking (stock.picking_type)
These have been added to the related form, kanban and calendar views when
applicable.
Properties have also been added to kanban and calendar views of
- crm.lead
- event.event
- project.task
(Properties had already been added on these models and form views)
Task-3458627
Part-of: odoo/odoo#132578
We convert the custom plan implementation to use the generic one. As the
generic one can define plans for multiple model. We use the check
dedicated_to_res_model == 'hr.employee' to activate the specific feature for
hr.employee. Indeed, that field contains the model name when the plan is
applicable only for one model.
We also remove the 'launch plan' button as we can now launch a plan directly
from the activities button in the chatter.
Technical notes:
For the activity schedule wizard, we add the support for active_ids and
active_model as default values for res_ids and res_model because it is used as
link in the chatter to launch the wizard and we want to avoid a big migration
by keeping the link identical (and there are probably no simple solution to
keep the same behavior).
HR CONTRACT
Before the first contract date of the first selected element was chosen to
determine the planned due date if all first contract date were different
otherwise the minimum was chosen. So if the selection included 2 different date
among 3, the minimum was chosen but the first if the 3 were different.
With this change, the minimum is always used to determine the default planned
due date.
Task-3390865
Part-of: odoo/odoo#137969
To keep the git history, we rename the files related to hr plan to their new
name before doing the changes in the following commit.
Task-3390865
Part-of: odoo/odoo#137969
This commit prevents deleting worklocations if they are used as default of an
employee. In case the worklocation is deleted, exceptions using that
worklocation are also deleted.
task-3527196
closesodoo/odoo#137502
Related: odoo/upgrade#5260
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
This commit removes the resource_calendar_id field on
the public employee, as this is giving information that we
don't necessarily want to be public. Additionnaly, it led
to the possibility for every user to access calendar forms.
task-3519805
closesodoo/odoo#137211
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
In this PR we'll add the following UX improvements :
- Drop the useless responsible_id field from hr_job
- Include applicant attachments in the meeting when scheduling an interview
- Several tooltip and default value changes
task-3380150
closesodoo/odoo#125932
Related: odoo/upgrade#4808
Signed-off-by: Sofie Gvaladze (sgv) <sgv@odoo.com>
This commit adds the feature to select a date in the future
in order to see future allocations, would it be for accrual plans
granting new allocated days, lost days due to expired allocations
or allocations that are not yet available to the employee.
The date selector only appear when the employee has accrual allocation,
in which case the feature is more relevant.
This feature comes with a major refactoring of hr_holidays
methods to handle some edge cases in the management of leaves.
The refactoring also includes the removal of the 'draft' and 'cancel'
state in allocations.
This commit also removes unused imports and implements some linting fixes.
task-2675380
closesodoo/odoo#108148
Related: odoo/upgrade#4238
Related: odoo/enterprise#35157
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
As `handle_history_divergence` is not used in the controllers, it makes
no sense to have it in `controllers/main.py`.
task-3217965
closesodoo/odoo#136277
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Issue:
------
When adding a file to an employee's work permit ("Private Information tab"),
the file name is the "value" of the file.
This is not meaningful for the user who will download the file.
Solution:
---------
Use the `filename` attribute to determine the field of `hr.employee`
to be used to get the file name.
As the original file name doesn't exist in an existing field,
we can use a "generic" file name with a non-stored computed field.
opw-3458842
closesodoo/odoo#133981
X-original-commit: 2f49ec86fcd8191f92153069ae242c329a5cdf0c
Signed-off-by: Sofie Gvaladze (sgv) <sgv@odoo.com>
Signed-off-by: Thomas Lefebvre (thle) <thle@odoo.com>
Steps to reproduce:
-------------------
- create a new employee;
- link it to an existing user;
- save (trigger a validation error);
- remove the related user;
- save;
- change the email address of this new employee;
Issue:
------
The email address of the employee linked to the user
that we tried to link is updated.
Cause:
------
We don't sync the employee with the user if the user is `False`,
i.e. we don't update the employee's `work_contact_id` if the `user_id` is `False`.
Solution:
---------
Update the `work_contact_id` in any case.
opw-3475002
closesodoo/odoo#133191
X-original-commit: c2f2dc3e49ee7cd96d4da05f2236441e65090753
Signed-off-by: Sofie Gvaladze (sgv) <sgv@odoo.com>
Signed-off-by: Thomas Lefebvre (thle) <thle@odoo.com>
Formerly, using sudo() on a record had the effect of replacing the
current user with the superuser. But sometimes, knowing who the "real
user" was was necessary, so we needed to store it somewhere. This is
basically why the key `binary_field_real_user` was introduced in the
context: to keep track of who the user was before switching to sudo
mode.
Since 1e6c3bec2c, however, switching to
sudo mode no longer changes the current user; meaning that the
`binary_field_real_user` is no longer necessary.
This commit removes the remaining occurrences of the now useless
`binary_field_real_user` from the code.
* = hr, portal, web_editor
closesodoo/odoo#92032
Enterprise: https://github.com/odoo/enterprise/pull/27649
Related: odoo/enterprise#27649
Signed-off-by: Louis Wicket (wil) <wil@odoo.com>
before this commit, on writing user_id to hr.employee
on multiple record in raisng single ton error.
after this commit, no error wont be raised on the
same.
closesodoo/odoo#130650
X-original-commit: ebc686b8abc84538f224ff4db205ce1231b747c3
Signed-off-by: Sofie Gvaladze (sgv) <sgv@odoo.com>
RATIONALE
Simplify field management for mail / phone / sms flows. Make it working out
of the box, easier to use and tweak.
SPECIFICATIONS
Simplify model custom code when dealing with phone and sms by using helpers
and standard behavior defined on all models.
'_sms_get_partner_fields' was introduced at odoo/odoo@bdebcab0ce to have a generic
implementation of finding partners on a record. Since then another version
has been added directly in 'mail' module, using '_mail_get_partners'.
'_sms_get_number_fields' was introduced at the same time to have a generic
implementation of finding numbers on a record. Since then a generic and
improved version has been added directly in 'phone_validation' module, see
'_phone_get_number_fields'.
Those method can therefore be removed, and replaced by the generic ones
available on BaseModel.
Task-3422449 (Mail, Phone: Move and improve field helpers)
Prepares Task-36879 (Mail: Support MultiCompany Aliases)
Part-of: odoo/odoo#130468
Moves the Newly Hired search filter from hr_recruitment to hr.
This new filter is available to all employees and not restricted to Officers.
task-3346478
closesodoo/odoo#123420
Related: odoo/upgrade#4759
Signed-off-by: Sofie Gvaladze (sgv) <sgv@odoo.com>
if you are a multi company user and you are employee
in another company than the current one you will
end up not be able to use your department as a filter
even if the department is defined for multiple companies
closesodoo/odoo#129665
X-original-commit: 8a30dbb4937ffad93e9d310ca4996d6ff5eac268
Signed-off-by: Sofie Gvaladze (sgv) <sgv@odoo.com>
Signed-off-by: Wolfgang Taferner <w.taferner@wtioit.at>
Users and employees can now define their usual worklocation
for a day of the week aswell as define unusual ones from the
calendar app. The worklocation is then displayed in the calendar
in two different ways: when only one person is selected, there
is a circle with an icon in it, and a ray that extends to the right
if the person is at the same location for multiple days. If there
are multiple persons selected there is no ray, instead the circles
are grouped by location type and colored accordingly to the filters
in the left panel.
closesodoo/odoo#129585
Task: 3060685
X-original-commit: c74ac3f698d4ea4c9b7a5e060fba4cf77cc9a6d7
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Co-authored-by: dasz <dasz@odoo.com>
Allow sharing records between company
* accounts
* taxes
* fiscal positions
* products
* ...and some related models
These records can be read and used in children companies.
This can be used to
* have different branding for different businesses
* allow more complex security rules
* consolidate branches differently
* manage different tax reports with different tax ids in the same
country
task-3371677
closesodoo/odoo#125642
Related: odoo/enterprise#43215
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Changing the value of `allow_out_payment` when it was already set to
False would trigger an AccessError.
closesodoo/odoo#128800
X-original-commit: 74f15362beaf967cefe509d5b9b66c5436bb661b
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Adds a mechanism to have some fields available to the employee manager
on the public employee profile.
Here `first_contract_date` is available for the employee manager.
task-2882052
closesodoo/odoo#124640
Related: odoo/enterprise#42362
Signed-off-by: Sofie Gvaladze (sgv) <sgv@odoo.com>
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 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
*: account, event_booth, gamification, hr, project,
website_event_track, website_hr_recruitment, website_slides
HTML fields that appear in the front-end can be modified using the
website editor. Some of them are sanitized in a way that breaks the
behavior of snippets that can be dropped within them.
This commit adapts the sanitization of those HTML fields so that the
snippets behave as expected.
opw-3267589
closesodoo/odoo#126708
X-original-commit: 7fd28afaf3e45cafbef80b69aa45c58b31fb3de6
Related: odoo/enterprise#43311
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Benoit Socias (bso) <bso@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
In case we use multi company and a user does not have an employee
in every company which is quite normal (mostly you are employed with
exactly one company), the calendar is skipping the provision of the
unusual days like public holidays or the working schedule.
To be able to access and see the calendar in such a case we fallback
to the company calendar and fixed a domain for the public holiday
retrieval whereas the public holidays are not assigned to an employee
but the company or the companies chosen to be displayed.
closesodoo/odoo#126420
X-original-commit: d80a3965b7356f9d6b1294cf428667a1057a272b
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Before this commit, when the user creates new resource and employee on
the fly in many2one field, the default avatar of Initial name should be
set instead of placeholder (grey icon). The reason why a grey icon is
displayed is because the `_compute_avatar` for employee set that icon
when avatar or image is not found.
This commit add default avatar of initial name when new resource and
employee is created.
task-3251689
closesodoo/odoo#123403
Related: odoo/enterprise#41823
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
When you use the salary configurator on existing employee, you get an
error because you cannot modify a trusted bank account.
Since we cannot modify the partner_id on a bank account when it is
trusted, we should only modify the partner on the accout when it is
needed, and untrust the account when it is changed.
This has been introduced in https://github.com/odoo/odoo/pull/120423closesodoo/odoo#125096
X-original-commit: 2ef3ebe5985368e5e859ae43bc4725dd8b8ebf06
Related: odoo/enterprise#42567
Signed-off-by: Pierre Masereel (pim) <pim@odoo.com>
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Steps to reproduce:
-------------------
- create two employees (A and B);
- create a user;
- add the user in Related User of employee A;
- remove the user;
- add the user in Related User of employee B;
- change the Work Email of the employee B.
Issue:
------
The Work Email of the employee A is also updated.
Cause:
------
When we add a `user_id` to an employee,
we update the `work_contact_id` field.
Fields `mobile_phone` and `work_email` are inverse fields.
When we modify them, the `_inverse_work_contact_details`
method is called.
We update the `work_contact_id` linked to the employee.
When we delete an employee's `user_id`,
we don't update the `work_contact_id`.
Therefore, when we update an employee's `work_contact_id`,
we call the `_compute_work_contact_details` method
method for all employees who have the same `work_contact_id`.
The result is that we modify the `mobile_phone` and `ẁork_email`
fields for all employees linked to the `work_contact_id`.
Solution:
---------
Differentiate the case where the `user_id` is `False` (>< `None`)
when it is modified and does not contain
a value to "synchronise" the `work_contact_id`.
opw-3338188
closesodoo/odoo#123965
X-original-commit: 85ab51c7cf7c8ee011a903a9460e2aff1296f215
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Signed-off-by: Lefebvre Thomas (thle) <thle@odoo.com>
Clicking on the 'Employee' smartbutton on a res.users form view would
lead to a traceback if the user was not part of HR Officer.
task-3279347
closesodoo/odoo#120804
X-original-commit: b5fc8a4bacdf2964f71f2ad5c7d0c6ac30a4a9b5
Signed-off-by: Kevin Baptiste <kba@odoo.com>
The employment type and first contract date were made available on the
public employee, however those fields but don't need to be publicly
available.
odoo/upgrade#4539
task-3252610
closesodoo/odoo#118333
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
* = bus, calendar, crm_livechat, hr, hr_holidays, im_livechat, mail_bot,
mass_mailing, privacy_lookup, test_discuss_full, test_mail,
test_mail_full, website_crm_livechat, website_livechat, base
In preparation of splitting discuss and mail modules.
Part of task-3265211
closesodoo/odoo#118354
Related: odoo/upgrade#4553
Related: odoo/enterprise#39661
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
When creating an employee with a private contact,
the contact will not be automatically added to the employee's followers.
The desired behavior is that the contact is added
to the followers even if it has a private address.
Commit: 8760a4d0575ecdb175f73a2f2674d93962fe905d
However, this behavior will not be possible because
adding a contact with a private address is forbidden.
Commit: 20536e1bbeb641539c0de44364f8376e7cef651b
Solution:
The solution is to use the private method `_message_subscribe`.
This is not a problem in the business case.
Indeed, the people who have access to the employee's file
also have access to the private contacts.
Moreover, the access rights of the public method `message_subscribe`
do not concern this business case.
opw-3249646
closesodoo/odoo#118843
X-original-commit: f53d4a28d46baaed4c862392b36bcaa73b642336
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Signed-off-by: Lefebvre Thomas (thle) <thle@odoo.com>
When using message_post, the body format must be explicitly specified.
If html is expected, a Markup object should be used.
If text is given, the content will be escaped.
Before this PR:
message_post was unaware if the content of a message was HTML or
text. This lead to multiple situation where the content was
incorrectly considered as HTML and led to display errors.
In
self.message_post(body="Hello %s!" % self.name)
if the name contained HTML, it would be evaluated.
In
self.message_post(body="Contact Raoul <raoul@caramail.be>")
the email would not be displayed as considered as unknown HTML and
discarded by the sanitizer
Now each call must explict the type of content.
Use the escape() helper to properly combine Markup and translations.
It would also be acceptable to use Markup() to wrap a static
translation but escape is better as one can not guarantee the content
of a translation.
closesodoo/odoo#111850
Related: odoo/documentation#3612
Related: odoo/enterprise#36728
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
before this commit, tracking is enable for the
binary field, but odoo is not tracking binary
fields to the chatter.
after this commit, the tracking attribute is
removed from the binary field
closesodoo/odoo#118297
Related: odoo/enterprise#39631
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Steps to reproduce:
- Install Employees App Configuration
- Got to the Employees > Configuration > Activity Planning > Set the On/Offboarding Plans
- Create Test Employee With No Catch
- Click on Launch Plan action
- Check the Warning in Launch Plan Wizard
When employee's coach or manager empty then warning is appeared coach's/manager's
user is not set.In this commit we have shown in the warning that the coach/manager
is not set.
task-3193218
closesodoo/odoo#115889
X-original-commit: 421c238129676a83df63f00abadd539e82ced2eb
Signed-off-by: Kevin Baptiste <kba@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>
Steps:
1. Create Employee A that related with user A / partner A in Sales
department
2. Create a channel Sales, set Auto Subscribe Departments as Sales
department
3. Archive Employee A / user A / partner A
4. Create a application B in Sales department and click button Create
Employee
5. An error occurred: duplicate key value violates unique constraint
"mail_channel_partner_partner_unique"
closesodoo/odoo#115184
X-original-commit: e5e2cc8e00d4aec6f76283e8c5a7e485d6e9ab63
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Thomas Lefebvre (thle)