if there the new_hire_field is False, an error appear. This Commit will check that the field is not false
closesodoo/odoo#159859
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Purpose of this commit:
Currently, people having access to different dashboards
without any access rights would end up with a traceback
when trying to search more employees.
Steps to reproduce this issue:
- have a user with timesheet officer rights and no hr rights
- log in with that user account
- go on the dashboard app and select "Timesheets"
- go on employee filter and click on "search more"
Current behaviour:
A traceback is displayed because the user has no access to the view
Expected behaviour:
The public employee search view should be displayed
How the issue was fixed:
The method called `_get_views` has been overriden in
the `hr.employee` model to return the `hr.employee.public` views
instead. As there was no way through the dashboard to define a
relation, the method explicitely takes the result for the
public employee and sets it as result of the private one as well.
closesodoo/odoo#158380
X-original-commit: 6e304037023545eb7eb453d5656f7e1769615d38
Signed-off-by: Sofie Gvaladze (sgv) <sgv@odoo.com>
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Signed-off-by: Bertrand Dossogne (bedo) <bedo@odoo.com>
This will fix the number of employees in the partner view and redirect to a kanban view of the employees.
The smart button on the partner view for the number of employees related to this partner now gives the correct number depending on the companies selected.
If multiple employees are related, the action shows a kanban view of those employees.
closesodoo/odoo#158146
Task: 3693173
X-original-commit: c1e979203ec82de2300ad2f8b10478e1504b1c7c
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
With this commit, the domain of work location domain is reintroduced.
It was a mistake introduced by this PR : odoo/odoo#129308closesodoo/odoo#157580
X-original-commit: 94de3445f507c9c1801157c9526244ab91ceff0d
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Ensure an avatar is generated based on the employee/user name
if no image is provided at the record creation (for internal users only).
closesodoo/odoo#147446
Taskid: 3637523
Related: odoo/enterprise#58646
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Co-authored-by: Yannick Tivisse <yti@odoo.com>
Currently the progressbar computation are not contract-aware, we fix this here
task-3777971
closesodoo/odoo#156040
Related: odoo/enterprise#57902
Signed-off-by: Bertrand Dossogne (bedo) <bedo@odoo.com>
Versions
--------
- 17.0+
Steps
-----
1. Go to Employees app as admin;
2. clear the "Working Hours" field & save;
3. go to Time Off app.
Issue
-----
Odoo Server Error.
Cause
-----
Commit 8f87e102a9 added the
`_get_consumed_leaves` method to `hr.employee`, which calls on
`resource.calendar` methods with `ensure_one()` active. The
`resource_calendar_id` is not a required field for employees, so an
error occurs when these methods are called on an empty record.
Solution
--------
Default to `company_id.resource_calendar_id` where a calendar is
expected.
Also fixes a potential issue in `hr_contract` when getting attendances
between a time interval that includes multiple contracts using different
calendars.
opw-3665412
closesodoo/odoo#149908
Signed-off-by: Bertrand Dossogne (bedo) <bedo@odoo.com>
The user associated to an employee doesn't need to be in the same
company of the employee. When this happens, we could get a multi company
issue when trying to _only_ display the employee form.
One way this issue is triggered is when the partner of the associated
user is marked as partner_share=True. We may get an access error due to
the rule `base.res_partner_rule`.
Steps to reproduce:
1. Install HR module
2. Create an extra company with a user (U) on it. Ensure the partner of
U is also set as belonging to this second company.
3. Create an employee in the first company with associated user U.
4. Archive U (this makes the partner of U get partner_share=True)
5. Try to access the employee form from the first company.
We get an error:
```
Due to security restrictions, you are not allowed to access 'User' (res.users) records.
Records: U (id=11, company=COMP2)
User: Mitchell Admin (id=2)
This restriction is due to the following rules:
- user rule
Note: this might be a multi-company issue.
Contact your administrator to request access if necessary.
Implicitly accessed through 'User' (res.users).
```
Since we allow hr.employee records to keep the associated archived user,
to avoid this issue (potentially triggered differently) we opt to
compute the avatar placeholder as sudo.
The issue has been observed in multiple upgrade requests.
closesodoo/odoo#149171
X-original-commit: 5136e86b4d47fae1a70cba0809906cfc625fd1de
Signed-off-by: Sofie Gvaladze (sgv) <sgv@odoo.com>
Signed-off-by: Alvaro Fuentes Suarez (afu) <afu@odoo.com>
Steps to reproduce:
-------------------
- install the "hr" module;
- remove access rights for "Employees";
- change language on the user profile.
Issue:
------
There's an Access Error because we can't read the `private_street` field
on the employee that corresponds to the user.
Cause:
------
The new version of onchange fetches the record values on the server side,
unlike the old version which used the values in the view.
In the old version, as we were using view values, this didn't cause any problems,
as the values came from a read that which took into account `SELF_READABLE_FIELDS`.
Note:
We do not have access to the value of the `private_street` field because it is a
related field with the attribute `related_sudo=False` and we do not have
access rights for the `hr.employee` model.
Solution:
---------
Use the cache and place the values of the fields in `SELF_READABLE_FIELDS` in it
before performing the onchange logic.
opw-3664929
closesodoo/odoo#148997
Signed-off-by: Raphael Collet <rco@odoo.com>
Issue
Admin unable to change related user on employee profile due to
restricted access to bank account.
Steps to reproduce
1- In the Employee app, go to the HR settings tab of an employee.
2- Remove the related user from this profile.
3- Set that removed user as the related user on a different employee
profile and save (expect no error).
4- Attempt to revert back to the original user.
5- Encounter an access error.
resolution
- Added sudo() in the browse operation to prevent access errors.
opw-3578412
closesodoo/odoo#147993
X-original-commit: 2b27b740ec3cff2fc088f4d01d7347668f6eb441
Signed-off-by: Sofie Gvaladze (sgv) <sgv@odoo.com>
Signed-off-by: Kawtar Drissi El Bouzaidi (kdeb) <kdeb@odoo.com>
Before this commit, _get_calendar_attendances was calling
the calendar method get_work_duration_data without specifying
the company in the domain, ending up in wrong data if global
leaves that don't concern the employee are concerning the calendar.
This commit adds a domain for that method call so that only
relevent global leaves are taken into account.
closesodoo/odoo#148043
Steps to reproduce:
- Create Allocation for 20 days for Mitchell Admin and validate (12/01 to 12/31).
- Set Working Schedule "Standard 40 hours/week" to UTC timezone.
- Set Mitchell Admin's timezone to Europe/Zurich.
- Create a time off with type Extra Time Off with dates 12/29 - 12/29 and try to save.
- Receive Validation Error: There is no valid allocation to cover that request.
Issues:
You cannot request that leave due to a timezone mismatch, even though you should be able to.
Solution:
To solve the zone mismatch we use the employee timezone to compute the
attendance intervals.
opw-3619178
closesodoo/odoo#146938
Signed-off-by: Bertrand Dossogne (bedo) <bedo@odoo.com>
Correct the wording of "Visa Expire Date" to "Visa Expiration Date"
for the visa_expire field to be more grammatically correct.
task-3595978
closesodoo/odoo#143222
X-original-commit: 1722e62193d0b587e508d30b1d460498c1ea4c86
Signed-off-by: Bertrand Dossogne (bedo) <bedo@odoo.com>
Signed-off-by: Florent Maisse (mafl) <mafl@odoo.com>
Step to reproduce the bug:
-Go to the employee app
-Go to an employee form view
-Click on the archive button
-Put a description
-Click on the archive button
-> Odoo error
Bug explaination:
The tracking is not implemented for the html field, so when we archive
an employee the tracking cannot work.
Expected behavior:
The employee is archived and the tracking is done without errors.
Bug resolution:
The tracking has been removed from the html field.
The tracking is now replaced by a message in the chatter
in the write method.
Behavior after this commit:
The employee is archived and the tracking is done without errors
with a mesage in the chatter if a value is entered for the
departure_description field has a value.
task-3576659
closesodoo/odoo#140527
Signed-off-by: Bertrand Dossogne (bedo) <bedo@odoo.com>
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>
pengyuthon