A new calendar view has been added, the "year" view.
Some modifications should be done on this view, more specialy in "Time Off" application.
Problems were the fact that it was hard to see if a time off has been approved or not.
Another was the fact that week-ends & public holidays were not grey.
This commit change year calendar in Time Off module.
More specially, this commit:
- Change default calendar in personal dashboard to "year"
- Gray week-ends & public holiday (based on the worker's calendar)
- Hatch non-approved time off
- Removed a calendar view from My Time Off Requests
- Fix a "cancel" button that doesn't work
- Add a new view that is displayed when there is no filter to show on the filter view for calendars
Task id #2318645
Task id #2317525
When going on Leaves dashboard, if an employee is archived, his leaves
are still displayed.
To reproduce the error:
1. Add time-off to an employee E
2. Archive E
3. Go back to Time Off module > Everyone
=> The E's leaves are still shown
They should be hidden.
Notes:
Manual forward-port.
In previous versions, the fix concerned the `hr_holidays` module
Replace #62795
Initial PR #62726
OPW-2406702
closesodoo/odoo#62987
X-original-commit: aa4be1c39d246a1a48c40bf7717c23809ca2e7ef
Signed-off-by: adwid <adwid@users.noreply.github.com>
Currently, Traceback occurs when we do timezone filters in every one
report of time off because the timezone is non-stored compute field in
hr leave model.
So in this commit, get the timzone value based on compute field from
resource or timezone of the current company's calendar OR user's tz
and at last 'UTC'.
closesodoo/odoo#61910
Taskid: 2334866
X-original-commit: 05c373a99a6064f08fc9eb0662ab2ccdb1978cd7
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
f0d37c384b added a check on write access
for server action. Since the fixed server action are readonly with strict
access right, corresponding groups are added to avoid a warning.
_read_from_database was removed in the ormpocalypse of 13.0 . It was used in
hr leaves report to make leave name (holding description) anonymous for
people not belonging to HR groups. Since 13.0 _read_from_database has been
removed. A security has been added in read_group itself, preventing to try to
read name through read_group.
In this commit we therefore simply remove dead code as the feature itself
is still alive.
Task ID-2285881
closesodoo/odoo#55610
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
This restricts the attributes of a BaseModel instance to `env`, `_ids`
and `_prefetch_ids`. This way, one can only assign fields on a record;
other assignments are programming errors.
This also reduces the memory footprint of records from 168 to 64 bytes
(-62%), and makes their instanciation faster.
closesodoo/odoo#51075
Related: odoo/enterprise#10529
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
The name of the employee and the dates were shown multiple times in the
popover. This commit aims at showing the relevant information only once.
closesodoo/odoo#49845
Taskid: 2227158
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Purpose
=======
Avoid to show to much information to leave responsibles.
Specification
=============
- Dynamically add/remove the leave_manager_ids on the group
group_hr_holidays_responsible, on employee creation/modification
- Retrict the available employees when creating a leave. For
manager/users : Everyone. For responsibles: The employee for
who the user is responsible. Otherwise: Only me.
- Don't obfuscate the leave name on employees for who I'm the
responsible.
- Add a new SQL view for "Everyone" report. To select only the
information we want to share instead of showing the hr.leave
model directly.
closesodoo/odoo#47659closesodoo/odoo#49765
Taskid: 2206862
Related: odoo/enterprise#9239
Related: odoo/enterprise#10021
X-original-commit: 781147dcaf1552b8f2ab687ed73034b8fd1f7352
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
The leave description is now replaced with a compute method in order to
obfuscate the description based on the user's group.
closesodoo/odoo#38995
Taskid: 2088559
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
There are too many image sizes. Since they are stored resized this takes time to
generate when saving a new image, it's more rows on the attachment table, more
files on the disk, ...
64px is close enough to 128px that it can be removed without a big impact on
download size.
It will even reduce download and number of requests when both images are
displayed because now only one has to be downloaded and then benefit from cache.
The difference between the two is typically around 1.5kB which is negligible
these days, especially when the request overhead is around 0.5kB already, not
even taking into account other factors such as latency.
If a 64px image must absolutely be returned, it is still possible to pass the
size parameters to the image route. But the current guideline is to handle
resizing in the views when necessary.
Views
=====
- remove width and height attributes when existing CSS rules are overriding them
(eg. `.oe_kanban_avatar` in the right context)
- add CSS rules instead of width and height attributes when possible
- use `object-fit: cover;` where width and height are forced to avoid distortion
of non-square images
- for products, use `object-fit: contain;` instead, keep ratio but without crop
- add new CSS rules where the expected size was max 64px*64px before due to the
image size itself
- remove `img-fluid` where using size classes to avoid conflicting rules
task-2060865
closesodoo/odoo#36147
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Prior to this commit, the Time Off Analysis report was showing the
leaves of all employees and not the ones selected.
closesodoo/odoo#37048
Taskid: 2073345
Signed-off-by: Romain Libert (rli) <rli@odoo.com>
This attribute is misleading as it is insufficient to correctly upgrade
the database. It only renames the column in the database, but other
operations are needed, like updating the corresponding `ir.model.fields`
record (and its xmlid). The default values and the translations are also
lost during the upgrade.
Moreover, this feature was misused. It was:
- left on fields during multiple versions.
- used on reports (SQL views). This would be ok if the feature was
complete, but, as is, it was useless.
- kept unchanged after a second renaming of the field (which can happen
versions later the first rename).
- used, even when the meaning of the field changed. i.e. the field
`archived` has been renamed to the classic `active`, but the value
in the database should be switched.
image_original => image_1920 (now resized to 1920)
image_big => image_1024
image_large => image_256
image_medium => image_128
image_small => image_64
image replaced by image_1920 (when writing) or by image_1024 (when displaying
what was previously the big size)
+ add new intermediate format:
image_512
PR: #34925
* attendance, contract, fleet, holidays, maintenance, presence,
timesheet.
For the model 'hr.employee', replace the actions menu 'Archive/Restore'
by the stat button. That's why adapted changes regarding xpath.
Also rename the actions menu 'Time Off' by 'Time off'.
Linked to task 1984526
Related to PR #33720
Before this commit, the report Leave Summary had hr.leave as its model
implicitly meaning that a report could be printed from an hr leave.
Since the report actually is a view which aggregates data, and not a document
representing a leave, it should have its wizard (the only entry point for that report)
as its model
OPW 2029699closesodoo/odoo#34507
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
The old tree views don't really exist anymore, this odd pseudo-flag to
dispatch between "list" and "tree" tree views has no reason to remain.
Task 1937686
closesodoo/odoo#31243
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Task 1843603
* src_model is redundant with binding_model_id
* multi -> binding_view_types (if empty => all views) (maybe should be
empty by default yo?)
* in convert, type => rec.get(type) but no @type possible on <act_window>...
* removed deprecated auto_refresh & auto_search (not used anywhere (?))
closesodoo/odoo#24738
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
General Purpose
===============
We want an 'Employee profile' gathering every data about an employee.
The main form view is modified to become this employee profile.
A user can also see his own profile through the Preferences menu.
The new profile replaces the current Preferences view if the hr module is installed
and the current user is linked to an employee.
A user should be able to see and edit his own profile.
*Problem*:
Many fields on hr.employee are protected by groups="hr.group_hr_user".
Therefore, a regular user cannot see or edit those fields.
This protection must be bypassed to allow read/write access
to the regular user's own data.
A similar mechanism already exists for res.users (for Preferences)
The better (least worst) solution found is to reuse this mechanism by adding related fields on res.users.
Pros:
- Don't change security access on hr.employee
- Don't implement yet another custom security layer, risking to add new security breaches
- A lot of fields are added by other modules on hr.employee.
It would have required to integrate them with the custom security layer.
- Fields added by other modules on the user's preferences view (normal view, not the profile)
are automatically included in the employee's profile view.
- Allow the hr.employee form view to be different than the user profile accessible
through the Preferences menu.
E.g. add custom buttons only relevant to the logged in user such as "Request a leave".
Cons:
- Each field from hr.employee that you want to appear on its profile
must be added as a related field on res.users
- Those related fields must be added to user's preferences view (duplicate views)
- They also must be added to SELF_[READABLE | WRITABLE]_FIELDS
Note:
When the front-end loads the views it gets the list of available fields
for the user (according to its access rights). Later, when the front-end wants to
populate the view with data, it only asks to read those available fields.
However, in this case, we want the user to be able to read/write its own data,
even if they are protected by groups (groups are kept on the related fields on res.users).
The front-end need to be made aware of those fields by sending all field definitions.
hr_attendance
=============
This commit integrate attendance in the new employee profile.
It also adds a stat button to this employee profile showing
the number of hours worked last month.
Remove the boolean computed field 'manual_attendance'.
This field is just a shortcut to add/remove the employee's user
in the "Manual Attendance" group.
The checkbox is confusing on the employee's form and this should
be done through the normal group management screens.
hr_presence
===========
Display the presence status on the employee kanban template.
The status is a colored chip which can be green (present),
orange (to define) or red (absent).
Currently, the presence status is only computed when accessing
the report view. As this commits displays it on the employee kanban,
it should be updated more frequently.
The state should not be updated every time the kanban view is loaded
since the computation is a bit heavy. Instead: add a cron to update
status every 15 minutes.
-> The status is accurate on the report view (status is still updated
when loading the view)
-> The status in accurate at 15 minutes on the kanban view
[ADD] hr_attendance_presence
============================
Bridge module between hr_attendance and hr_presence.
This commit integrates hr_presence module in the employee
profile and adds the presence status on the employee kanban view.
But hr_attendance adds at the same place a similar status icon for
checkin/checkout.
This bridge module makes the status from hr_presence invisible as
hr_attendance should be the main presence control mechanism.
Also, this commit adds the ability (through a new setting option)
for hr_presence to take into account checkin/checkout to determine
the presence status.
l10n_be_hr_payroll
==================
integration with employee profile
Purpose
=======
We need to use an international word to define holidays and leaves, rename everything into Time Off.
Employees needs a good dashboard and leaves summary
Specification
=============
1/ Add a new dashboard: https://balsamiq.cloud/sm5j0d/pg5w04r
Create a new dashboard with a calendar and a summary of all time off and time off request
2/ Rename leaves into Time Off everywhere
3/ Improve general usability
TaskID: 1916871
closesodoo/odoo#29634
Purpose of this commit is to rename type column to something matching the
the real business use of the field. That way it is easier to find and grep
in the code. It also lessens potential conflicts with type build-in python
function. It also lessens conflicts when using the field in JS as type
is a build-in attribute.
Renaming type column is a long-living issue. We choose to do it at the
beginning of the v13 development to catch errors as soon as possible.
This commit is linked to task ID 1896245. It is also a subpart of community
PR #27599.
Purpose
=======
Currently when searching on a department (on the employee view for example)
we only retrieve employees from the specific department. It should return
all the employees from the department and also from its children
departments, like for partners or companies.
Specification
=============
Adapt all the search view where a department field is used by
specifying a 'child_of' operator.
Purpose of this commit is to give description more "business oriented"
because those descriptions appears in Odoo Studio which is supposed to be used by end users, not only by developers.
Related Task ID : 37311
Purpose of this commit is to simplify fields used in leave and allocation
used to store the duration of the requests. We want notably to get rid
of "number of days temp" that, contrary to its name, is not temporary
at all as it stores the real number of days. We also want to clarify
the hours or days encoding that is different on leave and allocation models.
Specifications
* number_of_days on leave and allocation is the master field holding the
leave or allocation duration in days;
* two fields are used for interface that are suffixed by _display in order
to indicate they are UX only: number_of_hours_display and number_of_days_
display. They are interface fields used for the user and correct number
of days is computed and stored in number_of_days;
* more specifically for leave model
* display fields are readonly as it is computed based on dates given by
the user, directly (from / to) or indirectly (half-day leaves for example);
* duration field is computed through an onchange. It could be directly
set by hand by managers if some confusion in the number of days appear;
* more specifically for allocation model
* display fields trigger an inverse as they are the real duration given
by HR officers or managers;
* duration field is computed through the inverse of display fields;
Various reports, data and use of leave / allocation models are updated to
use the correct field.
This commit is linked to task ID 1876795 and PR #26571.
Currently code somehow allows people to create allocation requests on the fly
by writing on the computed remaining_leaves field. It work only under some
conditions that are not likely to happen. Moreover creating and validating
allocation requests should be done under the Leaves application while knowing
it and not hidden in an inverse field.
Let us remove that code and let people use the Leaves application to handle
allocation requests. That code comes from old versions of Leave application.
This commit is linked to task ID 1876795 and PR #26571.
Purpose is to clean a bit the code to prepare some incoming modifications.
More specifically this commit focuses on removing unused views and actions
to lessen future work in shaping them like requested.
This commit contains :
* small linting of leave fields;
* remove some unused and unnecessary views and actions;
* ensure default values for request_unit_all;
* small linting of tests;
This commit is linked to task ID 1876795 and PR #26571.
It seems specifications of new menus implemented at 9af6e9070a were not
totally correct and broke some Odoo conventions. New specification for leaves
application menus are now the following :
* Dashboard
* My leaves (user sees this only)
* New request (calendar view by default)
* Leaves requests (only my, list view by default)
* Allocation requests (only my, list view by default)
* Summary (only my, summary list view by default)
* Managers (HR officers or managers only)
* To approve
* Leaves (default filters: to approve, on my department)
* Allocations (default filters: to approve, on my department)
* All
* Leaves
* Allocations
* Payroll
* Leaves to report (default filters: grey kanban state)
* Reporting (HR officers or managers only)
* Leaves Analysis
* Report by Department
* Configuration
* Leaves Types
This commit is linked to task ID 1876795 and PR #26571.
Purpose
- clean access rights;
- solve some access and security issues;
Access specifications
- an user
- can see all leaves;
- cannot see name field of leaves belonging to other user as it may contain
private information that we don't want to share to other people than
HR people;
- can modify only its own not validated leaves (except writing on state to
avoid bypassing validation);
- can discuss on its leave requests;
- an Officer
- can see all leaves;
- can validate "HR" single validation leaves from people if
- he is the employee manager;
- he is the department manager;
- he is member of the same department;
- target employee has no manager and no department manager;
- can validate "Manager" single validation leaves from people if
- he is the employee manager;
- he is the department manager;
- target employee has no manager and no department manager;
- can first validate "Both" double validation leaves from people like "HR"
single validation, moving the leaves to validate1 state;
- cannot validate its own leaves;
- a Manager
- can do everything he wants
In top of that, multi company rule are correctly added.
In reporting model using in "summary" name field should also be stripped
if you are not an HR officer and if it is not your own request.
Concerning allocation requests: implement same rules except constraint on
name field as it is less private and therefore can be seen.
This commit is linked to task ID 1876795 and PR #26656.
Before the models split in a0f4f65 the Leaves Summary report inherited
the message_needaction from mail.thread. Now the hr.leave.report model
does not have this field and leads to a traceback.
With this commit, the filter is removed from the search view of the
report.
Steps to reproduce the bug:
- connect as the demo user
- go to the Leaves app
- check the Leaves Summary menu: by default, it is empty
- go to Allocation Request
- create one Allocation Request for 1.00 day using the Compensatory Days type
- repeat the operation several time
Bug:
Only the first Allocation Request appears in the Leaves Summary
opw:1872365
The '.badge' elements must now also use the 'badge-pill' class to get
the same style as before as '.badge' elements without it are meant to
replace the old 'label' component.
Giacomello Nathan