This commit does multiple things:
- The readonly mode of form view is removed but not for the fields.
it means that the fields in the view are always in edit mode except
if we force them to be readonly.
- The control panel is revamped to take less vertical space and shows now
the record editing (dirtiness)/validity status after editing the record.
- The record is saved only when leaving the view or by clicking the save
button when hovering the record status in the control panel.
- The record can still be discarded by clicking the discard button when
hovering the status text in control panel.
task id: 2822553
X-original-commit: 77824ad44b6945a9811120380747f87ef6362ae2
Part-of: odoo/odoo#101118
Co-authored-by: luvi <luvi@odoo.com>
Prior to this fix, when a ResourceMixin was copied
and a `company_id` set in its default values,
it was not taken into account, because
ResourceMixin.copy_data first copied self.resource_id
without default values, then set the company of it
into the default values for its own copy.
Same went with `resource_calendar_id`,
just copying the calendar of its resource.
With this fix, if present, we first set these two values
in the Resource default values (`company_id` and `calendar_id`)
and only then copy them in the ResourceMixin default values
(as `company_id` and `resource_calendar_id`).
closesodoo/odoo#93823
Related: odoo/enterprise#28490
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
This commit moves the element inside the table to avoid that the
dropdown may overlap thead column labels.
Part of the overall v16 SCSS optimization/restyle, task-2704984
task-2946835
Part-of: odoo/odoo#98234
This revision is to make uniform the behavior of the `groups` attribute
on the Python model fields
and on the node in the view architecture.
In both cases, remove the node from the view completely.
Before this revision,
in a back-end view:
- In the Python model, if a field has the `groups` attribute set
and the user is not part of
the groups, the field is removed, completely, from the view.
- In the view architecture, if a node has the `groups` attribute set
and the user is not part of
the groups, the node is made invisible (not completely removed, just
made invisible).
in a front-end view:
- if a node has a "groups" or "t-groups" set and the user
is not part of the groups, the node is removed from the view.
So it's 2/3 cases removing nodes restricted to a group.
and 1/3 case making invisible nodes restricted to a group.
It's simpler to have a uniform behavior for the 3 cases,
simpler to understandard for developers.
In addition, this will help for the goal to cache back-end views.
It makes possible to convert views using the `groups_id` field
by moving the content of these views directly
in the view to which they add content which is suppose to be completely
removed when the user has not the according group.
By getting rid of the `groups_id` many2many field on `ir.ui.view`,
it makes possible to cache the view architecture without
requiring to use the groups in the cache key.
Currently, if we want to cache the view architecture,
it would be required to use the intersection of the user
groups with the `groups_id` groups of the view,
making it costly to compute the cache key,
therefore altering the performance point to cache the view
architectures.
closesodoo/odoo#95729
Related: odoo/enterprise#29592
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
This commit aims to improve the performance of
`_attendance_intervals_batch`.
The complexity in space has been reduced by a lot.
Prior to this commit an intervals object was generated for each resource
request.
However every resource of the same timezone will share the same ending result.
The number of calls to `localize` and `astimezone` has also been reduced
as they get quite expensive with such a high volume.
Overall we can see a 10x improvement during `test_performance_attendance_intervals_batch`
closesodoo/odoo#90933
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Prep work to allow work entries to be created from multiple sources when
using contracts.
The end goal is to be able to generate work entries from attendance as
well as the planning app.
After that the plan is to make sure the implementation works well with
payroll for hourly wages.
This commit contains the necessary changes for the next work_entry
modules to work.
TaskId-2466871
Remove most values uselessly specified because giving the same value as
the default one (see _DEFAULT_MANIFEST in odoo/modules/module.py)
* auto_install is Falsy by default
* author is Odoo SA by default
* summary & description are empty strings by default
* application is False by default
* test, demo, depends and data are empty lists by default
This will reduce noise/inconsistencies between manifests specifications,
simplify analysis of manifests content, ...
closesodoo/odoo#90209
Related: odoo/enterprise#26807
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Make sure related values are correctly propagated to the
resource.resource creation, and discard the inverse update post record
creation when it doesn't change anything
closesodoo/odoo#85601
Related: odoo/enterprise#25664
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
When the admin user logs in for the first time, their timezone can be updated based on the cookies of their browser.
In such case, the timezone of the default working calendar should be updated too.
Related: https://github.com/odoo/odoo/pull/83262/
Task 2759592
closesodoo/odoo#87061
X-original-commit: 3c56be1732d219ed69efe5f18bd7931959b7c333
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Small changes in the layout of the hr_leave form view,
mainly for the manager's view point
Task : #2734842 [Time Off] ux changes
closesodoo/odoo#82976
Related: odoo/enterprise#23896
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Previously for `appointment`, now for `appointment_hr`, the computation of
users' availability for appointment slots can be dependent on that person's
work schedule if:
* The user is linked to an employee
* The user's employee has working hours defined (resource calendar)
This commit provides working hours to all employees and a user to some, within
a multi-company setup.
Task-2728093
See odoo/enterprise#22642closesodoo/odoo#80688
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
When creating a new working calendar, its timezone is set to the one of the user creating the record.
However, when first installing the resource app, the timezone of the default working calendar is always UTC regardless of the timezone of the users.
To fix this, this commit sets the timezone of the default working calendar to the timezone of the admin instead.
Task 2744201
closesodoo/odoo#83480
X-original-commit: 2ddddd0253db402542ab6359026888acd61c2464
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Steps :
- Install Planning
- Users > Mitchell Admin > Preferences > Timezone :
Europe/Brussels
- Settings > Employees > Company Working Hours > Timezone :
Japan
- Planning > Gantt View > Week > Mitchell Admin x Friday > Click "+" button
Issue :
- Start date is set by default to Thursday 05:00
whereas it is expected to be set on Friday 00:00
Cause :
- When we want to plan a shift on a day,
we look into the 00:00 to 23:59 range for this day in calendar's tz
to get the closest work time inside of it.
- Yet, this doesn't take the "resource user" into account.
Fix :
- Set these limits for the day in resource's tz.
opw-2678221
closesodoo/odoo#82555
X-original-commit: 1b248ebd58e0a57b070ebf7d67c6da78351a720a
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
This commit adds methods to easily obtain calendar validity per resource
for a given search period and get the work intervals per resource,
taking into account the validity of their calendars.
In hr, the create and departure date of an employee are taken into
account to compute the calendars validity.
In hr_contract, it looks for every contract of human resources with
employee of type student or employee existing in the search period and
consider the specific calendar of the contract as valid during the
contract-lifetime.
PR: #77362
task-2646630
The False key is always added in attendance and leave intervals batch
but is not added in the work_intervals batch.
To give a more smooth API, this commit aligns work_intervals behavior
with the two other methods behavior, regarding the added False key.
Furthermore, we avoid to deal with a resource_list of two empty
recordsets, in the case where the resources parameter is None or empty
recordset.
PR: #77362
task-2646630
Purpose of this commit to improve generic UX for the project app.
So, In this commit done following changes:
- add 'subtask_effective_hours' and 'total_hours_spent' fields in the page of
subtask in task form view.
- change invisible attrs to column_invisible attrs for block_by page in task
form view.
- add 'task in progress' subtype for project.task and move 'stage changed'
subtype above 'task blocked'.
- remove the 'is_close' field and all its references from project.task.type.
- unarchive all of its tasks when the user unarchives the task stage.
- sort projects on 'is_favorite'.
- internal users following the project automatically follow its updates and
their notification preferences propagated accordingly.
- duplicating a task will duplicate all of its subtasks.
- move parent task field in extra info page of task form view.
- change the label of 'edit' to 'view' in the burger menu of project kanban view.
- user can delete task without sale_order validation error.
- add constraints for 'seller_ids' field.
- add remaining_hours_so field in task tree view.
- add unusual_days in task calendar view.
- add 'no content helper' in action of burndown chart.
task-2536044
closesodoo/odoo#74018
Related: odoo/enterprise#19880
Related: odoo/upgrade#2801
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Co-authored-by: Kartik Chavda <kcv@odoo.com>
Allow to use _adjust_to_calendar with or without leaves.
This PR adds a keyword argument to the _adjust_to_calendar, _get_closest_work_time and _work_intervals_batch to include or not the employee being on leave when searching for the start and end of the shift.
task-2632775
closesodoo/odoo#79127
Related: odoo/enterprise#21944
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
The end datetime is not timezoned in _adjust_to_calendar before defining the search_range and using the _get_closest_work_time method.
Since _get_closest_work_time will timezone the timestamp received to start searching, the search interval needs to refer to the same end timestamp to avoid erratic behaviors.
Task-2628876
closesodoo/odoo#79049
X-original-commit: cbf0cb6e210959b3ceea554ec68957416a125141
Related: odoo/enterprise#21915
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Improves on _attendance_intervals_batch to profit more from batching.
Resources are grouped by timezone since we know they will all have the
same result except for when there are resource assigned attendances.
Those have to be handled separately but are incoroporated in the same
routine.
TaskId-2674527
closesodoo/odoo#78741
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
If no timezone is given to _attendance_intervals_batch, the timezone was
overwritten by the first resource's timezone.
TaskId-2674527
Part-of: odoo/odoo#78741
Assign a search_range for calendar_end in the _adjust_to_calendar method in all conditions.
The search_range was only assigned a value if the start and end are on the same date before.
The _adjust_to_calendar method receives a start and end from midnight to midnight in the resource timezone.
Start and end datetimes can be set on a different day via the Gantt view set in month or year for example.
This commit ensures that a search_range is always assigned to find the calendar_end and not only when start and end are on the same day.
This allows to find the end of a shift searched over two days if the employee is only working one day.
Task-2628876
closesodoo/odoo#78746
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Steps to reproduce:
Open the gantt view and add a few shifts for different resources
Observed behavior:
https://nimb.ws/1t38Jl resources are not sorted by alphabetical order
Expected behavior:
https://nimb.ws/NqIAG3 resources should be sorted by alphabetical order
task-2633936
closesodoo/odoo#76621
X-original-commit: 9c4ed2bcadc417a2927877902c4c275e5d9d16d5
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Signed-off-by: LTU-Odoo <IT-Ideas@users.noreply.github.com>
Purpose
=======
Time Off : New Dashboard, Accruals feature, Public holidays, New time off type configuration view.
- Review of Dashboard
- Accrual feature : Currently, when you create an allocation, it's possible to create an
Accrual, but there is no appraisal Plan. An Appraisal plan is use to define steps of accruals
for each employee.
In Belgium, we use accrual Allocation for European Leaves, or compensatory hours, it's a
simple use case. But in USA, it's possible to change the calculation mode each year.
Also, in USA, it's possible to deal your accrual plan when you arrive on the company. It's a
HR Officer task to create the right Accrual allocation for each new employee.
- Public Holidays :
Improvement of global time off feature located on Working hours calendar. Now, Time off
application have to manage Public Holidays.
- Review of Time Off type configuration
COM PR: https://github.com/odoo/odoo/pull/72511
ENT PR: https://github.com/odoo/enterprise/pull/19157
UPG PR: https://github.com/odoo/upgrade/pull/2791
TaskID:2475413
closesodoo/odoo#72511
Related: odoo/enterprise#19157
Related: odoo/upgrade#2791
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Co-authored-by: William Braeckman <wbr@odoo.com>
Co-authored-by: Xavier BOL (xbo) <xbo@odoo.com>
Co-authored-by: Laurent Stukkens (LTU) <ltu@odoo.com>
Co-authored-by: Yannick Tivisse <yti@odoo.com>
The license is missing in most enterprise manifest so
the decision was taken to make it explicit in all cases.
When not defined, a warning will be triggered starting from
14.0 when falling back on the default LGPL-3.
closesodoo/odoo#74245
Related: odoo/design-themes#48
Related: odoo/enterprise#19862
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
It is not possible to define a working time that lasts a whole day. This
can lead to calculation errors.
To reproduce the error:
(Need mrp,hr_payroll)
1. In Settings, enable:
- Work Orders
2. Create a Work Center WC
- Working Hours: <Create and Edit>
- 2 shifts:
- Monday, From 0 To 24
- Tuesday, From 0 To 24
3. Create a routing R:
- Add an operation:
- Work Center: WC
- Default Duration: 1440 (i.e., 24h)
4. Create a Bills of Materials BM
- Routing: R
5. Create a MO:
- Bill of Material: BM
- Plan From: Next Monday
6. Save, Mark as ToDo, Plan
Error: Since the operation should last 24 hours, the end time should be
the same. However, the Planned Date field is incorrect: the end time is
one minute too late. This error is even more noticeable when increasing
the quantity to be produced.
On step 2, when setting the 'Work to' field to 24, it automatically
becomes 23:59. The first consequence is directly observable on working
time form: we should have a total of 48 hours/week but the current total
is 47.98 hours/week. Another consequence is the end of the planned date
(as described above).
OPW-2462094
closesodoo/odoo#72210
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Conversion of all modules to the new manifest assets declaration.
Part of task: 2352566
Co-authored-by: Julien Mougenot <jum@odoo.com>
Co-authored-by: Simon Genin <ges@odoo.com>
