Some of the non canononical timezones are not present in Ubuntu Noble,
it would be a better practice to only use canonical timezones in data
and tests.
Note that this is not a real fix for all cases since the database that
ran on Ubuntu Jammy and are moved to an ubuntu Noble server will have
the issue with timezones already in database.
One of the possible fix would be to manage that during upgrades, but
this isn't a verry flexible solution since upgrade are meant to manage
chyange of version, not change of server. If an old 17.0 versions needs
to be moved to a Noble server, this won't work.
Another solution would be to install package like tzdata-legacy that may
keep the old timezones but it is not the only think since TAI-10 are
also in this package. This solution is not ideal because non canonical
timezone will still be shown in the dropdown. We would need to filter
them.
A last solution would be to add the support for those old timezones by
monkeypatching the lib. This way, only new timezones would be shown but
non canonical one won't crash when used. This is not ideal either
because we may need to keep this for a while. But in combination with
the upgrade solution, it may work proprely.
Part-of: odoo/odoo#160842
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>
When we use the `|` (or) version of this rule the ORM generates two
sub-queries when checking the company. This causes sub-optimal and in
some cases really bad planning for the queries and thus PG takes hours
to complete them.
Example (formatted):
```sql
SELECT "mrp_routing_workcenter".id
FROM "mrp_routing_workcenter"
LEFT JOIN "mrp_bom" AS "mrp_routing_workcenter__bom_id"
ON "mrp_routing_workcenter"."bom_id" = "mrp_routing_workcenter__bom_id"."id"
WHERE "mrp_routing_workcenter"."workcenter_id" in (1)
AND ( ("mrp_routing_workcenter"."bom_id" in (
SELECT "mrp_bom".id
FROM "mrp_bom"
WHERE ("mrp_bom"."company_id" in (1))
)
)
OR ("mrp_routing_workcenter"."bom_id" in (
SELECT "mrp_bom".id
FROM "mrp_bom"
WHERE "mrp_bom"."company_id" IS NULL
)
)
)
ORDER BY "mrp_routing_workcenter__bom_id"."sequence",
"mrp_routing_workcenter__bom_id"."id",
"mrp_routing_workcenter"."sequence",
"mrp_routing_workcenter"."id"
```
If we use the single term version the generated query has only one
sub-query:
```sql
SELECT "mrp_routing_workcenter".id
FROM "mrp_routing_workcenter"
LEFT JOIN "mrp_bom" AS "mrp_routing_workcenter__bom_id"
ON "mrp_routing_workcenter"."bom_id" = "mrp_routing_workcenter__bom_id"."id"
WHERE "mrp_routing_workcenter"."workcenter_id" in (1)
AND ( ("mrp_routing_workcenter"."bom_id" in (
SELECT "mrp_bom".id
FROM "mrp_bom"
WHERE (("mrp_bom"."company_id" in (1))
OR ("mrp_bom"."company_id" IS NULL))
)
)
)
ORDER BY "mrp_routing_workcenter__bom_id"."sequence",
"mrp_routing_workcenter__bom_id"."id",
"mrp_routing_workcenter"."sequence",
"mrp_routing_workcenter"."id"
```
In this version PG is able to produce a better query plan resulting in
better execution times.
Also, the `company_id` field is required on some models, so the "= False" comparison is useless.
closesodoo/odoo#159123
X-original-commit: 1b5c41f36801fb886ec591f29dba42787d698526
Related: odoo/enterprise#59378
Signed-off-by: Christophe Simonis (chs) <chs@odoo.com>
Co-authored-by: Christophe Simonis <chs@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>
Currently, when the user and the target both are in multiple companies,
the profile button cannot be displayed correctly. Since the employee_id
uses `('company_id', '=', self.env.company.id)` rather than `in`.
This commit fixes the issue by checking employee_ids directly and if it
is found, the profile button will be displayed correctly.
We don't care about which employee_id is used if there are multiple,
since the user are in multiple companies as well. If looking for a
specific profile, the employee can be found in the HR application.
closesodoo/odoo#157741
Signed-off-by: Sofie Gvaladze (sgv) <sgv@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>
Steps to reproduce
==================
- Install Timesheets
- Login as Admin
- Edit the access rights of Mark Demo:
* Timesheets: "User: all timesheets"
* Employees: "None"
- Logout and login as Demo
- Go to a project task
- Switch to the Timesheets notebook
- Add a new line
- Click on the employee field > Search More
=> An error occurred
Cause of the issue
==================
The hr.employee.public model is an SQL view of the hr.employee table
with differents permissions.
Since the user doesn't have the hr.group_hr_user group, the model
hr.employee.public should be used and not hr.employee.
Since [0], the model is switched depending on whether the user has the
appropriate group.
The EmployeeFieldRelationMixin is used and defines a getter for the
relation. That relation was not propagated to the Many2OneField.
Solution
========
Pass the relation to the many2OneProps.
---
[0]: https://github.com/odoo/odoo/pull/136786
opw-3765393
closesodoo/odoo#155743
Signed-off-by: Sofie Gvaladze (sgv) <sgv@odoo.com>
For a first iteration, Russian translations were done using DeepL using
1 large .pot file of all the standard modules to translate (e.g. no
localizations, no test modules, etc). Unfortunately for some reason
doing a msgmerge with the existing ru.po files didn't seem to work, so
old "Translators" metadata at top of files were lost (maybe they will be
re-added during next Transifex sync?)
Part-of: odoo/odoo#152285
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>
up default Working Hour for a company
Setps:
1. `Standard 38 hours/week` data doesn't have a company
2. Employees menu > Configuration > Settings
3. cannot select `Standard 38 hours/week` to set
closesodoo/odoo#147995
X-original-commit: 352843ff8a8d204007f021153765d093aeb11fb5
Signed-off-by: Bertrand Dossogne (bedo) <bedo@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>
Change adds missing helpers and alters some of their messages
in differents parts of HR apps.
task-3522163
closesodoo/odoo#145268
X-original-commit: a2238763d4fad99da69a96104adf26b6d8eca938
Related: odoo/enterprise#52261
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>
Issue:
The hr_referral application can not be installed with demo data.
Analyze:
The db is being auto locked. And transaction is not rollback due to the
xml failure.
Fix:
Add corresponding line into hr_demo.xml instead of hr_referral_demo.xml
Note:
It does not fix the root cause, but until the root cause is well defined
and fix, it is the best workaround.
Related ticket:
opw-3547638
Affected version:
16.0 and above
closesodoo/odoo#142928
X-original-commit: 436772ff0af5ae21043e4c0d60761c4f4149f7e7
Related: odoo/enterprise#51163
Signed-off-by: Benjamin Hanquin (beha) <beha@odoo.com>
Signed-off-by: Sofie Gvaladze (sgv) <sgv@odoo.com>
pengyuthon