This commit sets the fields date_from and date_to as optional hidden on
the resource.calendar.attendace.
closesodoo/odoo#51527
Taskid: 2241686
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
With a user with timezone "Europe/Brussels", add a
slot on the gantt view where the preceding day is a working day.
The default starting time will be the previous day.
Reason: the default starting time is midnight, adjusted to
the closest attendance interval in the employee's calendar.
However, midnight in "Europe/Brussels" is actually 10pm UTC
the previous day.
The method adjusting the datetime to the closest attendance only
checks within the corresponding day.
Two ways to fix this:
1) the business code calling `_adjust_to_calendar` should
timezone the datetimes itself. To avoid similar bugs in the future,
the method should be modified to only accept timezoned datetimes.
2) Change `_adjust_to_calendar` to convert datetimes it was given
to the resource's timezone and consider the dates in those converted
datetimes.
Option 2 is chosen because it seems to take care of the problem at a lower
level which allows the business code to not think about those timezone details.
While this is technically an API change (in a stable release), the method was
introduced recently by b058ca1 as a fix for an already broken method.
closesodoo/odoo#53582
X-original-commit: c6cecac60360a1d8b0c62ee155a818a3a28505e1
Related: odoo/enterprise#11399
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Using a few regex like
\((_\(.*%s.*)(\) % )([\w\[\]][\w .\[\]\(\)'"]*)\)
($1, $3))
Old syntax is still compatible but starts the migration to the new
syntax that catches error.
The methods `get_work_hours_count` and `_attendance_intervals`
raise a traceback if `self` does not contain a single calendar record.
This commit adds an explicit check for this requirement.
Related PR odoo/enterprise#10593closesodoo/odoo#51326
X-original-commit: e5d93be382b03c7a9c925b4a2e6be6875843195d
Related: odoo/enterprise#10619
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Before this commit, It was not possible to Hide Working Time or Deleting Working Time if Resource is linked to it.
Now we add, Active field to Hide Working timw without removing it.
closesodoo/odoo#50963
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
The method `_get_work_interval` has several problems:
1) The name is not self explanatory in any way
2) It should be defined on the `resource.mixin`
3) It simply does not work (as described in its docstring).
Here is a simplified example (only concerned about hours):
Currently, given two attendances: 8-12 and 13-17,
with parameters start=9 and end=18 it returns (9, 17)
while it should return (8, 17).
This leads to strange behaviors in the planning app:
Given employee A with calendar 8-17 and employee B 8-16.
Create a planning slot and assign employee A: the start and end times
are set to 8-17.
Then assign employee B, the start and end times are correcly set to 8-16.
Now reassign employee A: the start and end times are not set to 8-17.
Task 2229296
closesodoo/odoo#50804
X-original-commit: 7dfab89bc0025cf6424f00b6992fef1f42463ffe
Related: odoo/enterprise#10426
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Signed-off-by: lul-odoo <LucasLefevre@users.noreply.github.com>
In a calendar with 2 weeks mode (odd and even), before this commit, all
new created periods (placed in one of the two sections) don't have the
week_type field set. This generates a confusion, because a period that
should be applied only in odd weeks, for instance, it was applied also
in the even weeks.
Now, the new periods will have the week_type field set with the
week_type of the section where is it. Also, an error message is raised
if a period is not in one of the two sections.
opw-2239966
closesodoo/odoo#50478
X-original-commit: 33a62118818952872321591e85403b657380128a
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
Purpose
=======
When duplicating a calendar, duplicate their global time off too.
closesodoo/odoo#49255
Taskid: 2230549
X-original-commit: b1417a8f094331246120ce5f0a5d25db6c6eb8a7
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
ir.rule are default values but can be customized based on the
company's policy and needs.
This is typically a record that is in noupdate as should be
customization-friendly.
Currently, to activate/deactivate records with the 'active' checkbox
user has to switch to edit mode of the form.
So the purpose of the task is to allow the user to activate/deactivate
records from the readonly mode of the form view.
In this commit, we set widget='boolean_toggle' on the 'active' field in form
view.
closesodoo/odoo#46567
Taskid: 2206794
Related: https://github.com/odoo/enterprise/pull/8918
Related: odoo/enterprise#8918
Closes: #46567
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
When a contract is closed, set the date of the day.
In the contract cron, ensure that all closed contracts have
an end date if it is followed by a new contract.
Add multi-edit on work_entry list
closesodoo/odoo#44118
Taskid: 2180263
X-original-commit: 0b5d8ce756eac904a040ca700f44ea860daefcb4
Related: odoo/enterprise#7991
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Followup of a425695e
The terms were back in 12.0
Courtesy of Juan José Scarafía
closesodoo/odoo#41624
X-original-commit: 85d0c7001a997748d7691205bbb8d066597591a5
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Move and adapt gantt unavailability related methods (
_get_work_interval() and _get_unavailable_intervals() ) from
hr.employee to resource.resource. This move allows the unavailability
to be generated for users without related employees (like in FSM in
enterprise).
Task-2069861
closesodoo/odoo#36785
Signed-off-by: Jérome Maes (jem) <jem@openerp.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>
This commit simply moves methods from the resource
mixin to the calendar, so it can be use without having
a resource.
Indeed, in some case, we want to know the duration (in
days and hours) according to a working calendar without
any resource attached (typically services using a
working calendar).
Task-37561
Don't set attendance_ids default value if the field
is not in the field list parameter.
closesodoo/odoo#33904
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
The goal is to be coherent with the user property.
Actually, company_id and company_ids on the environment are no fields.
Calling env.company_id returns a browse record, not an id.
Multi is the default api for methods, it is not necessary to explicitly
decorate methods with it, adds clutter and most people use it because
they see that the rest of the code uses it.
Done with `find . -type f -name '*.py' | xargs sed -i '/@api.multi/d'`
Purpose
=======
In Belgium, we need to support some partial time on 2 weeks.
For instance, a mid time, means you could work on monday, tuesday
and wednesday on week1 and monday and tuesday on week 2. Others payroll
softwares manage this.
Specification
=============
Add a checkbox on resource calendar to manage 2 weeks. --> Consider even/odd weeks.
Add sections on calendars (Like sales orders)
Modify methods in resources to apply this behavor generically.
Check that attendances aren't overlapped
Write an integration test for holidays - benefits - payslip
to check all this, + "credit temps" and wage modification.
Note
====
For the sake of simplicity, we only manage calendars over 2 weeks
to consider the odd/even weeks and keep an easy implementation.
For more complicated calendars (eg: over a months with specific targetted days),
it's better to create specific allocation requests and apply specific leaves
for those days, as it would be the case for parental leaves.
closesodoo/odoo#31674
Signed-off-by: Yannick Tivisse (yti) <yti@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>
The field user_id on resource.resource is optional but the access rules
on resource.calendar.leaves request that field set. Which means a user
can only see his own leaves but not the ones of a machine's calendar for.
instance
This commit relax those rules to give access to the user's leaves and the
one not assigned to a specific user
Task : 1892819
Purpose
=======
Currently, `resource.calendar.leaves` are ordered
by creation date. In a list view,this is counter intuitive
if leaves are not created in the order in which
they will happen.
Specification
=============
Order `resource.calendar.leaves` by `date_from`
instead of creation date.
Kevin Baptiste