Mainly transifex issues but also some errors found through 'grep' checks.
Fix typos and obscure english strings in xml contents, fields strings/helps, some docstrings, ...
ensuring correct translations base (and fallback when translations isn't available).
closesodoo/odoo#57276
X-original-commit: 4214f05d454bca2b60fda3a288d529c098e84f77
Related: odoo/enterprise#13053
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Before this commit, when two week calendar were used, the tooltip was wrongfully assuming which week were odd and even.
Even with correct information, it was not easy to fill and could easily lead to wrong information on the payroll.
closesodoo/odoo#56055
Taskid: 2308804
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
TL;DR
=====
Improve performances with nearly a factor of 2. Use case, call action_validate on hr.leave for 100 employees
- 1987 requests -> 844 requests
- 1300 ms -> 700 ms
Purpose
=======
The first purpose of this commit is to add a test ensuring the number of request while creating
a company leave for 100 employees, if 15 of them already have a leave during that period.
It includes, the mass leave generation, and the conflicts resolutions. (Cancelling/Splitting the
already existing one and adapting the dates accordingly).
The second one is to reduce the number of request for this test.
In term of requests, currently we have:
- 5154 requests without bypassing the mail tracking + the activities management
- 1987 requests when bypassing the mail post-process (this is the current value, the bypassing was
already done several month ago)
- 844 requests with all the optimization done in resource/calendar/hr_holidays
In terms of execution time, we have a reduction from +- 1300 ms to call the method action_validate
to +- 700 ms
As the performances issues severity increases with the number of leaves to create and the real time access
to the database, on the production base, we reduced the execution time to generate more than 500 hr.leaves
from several minutes to 21 seconds. A fix to avoid deadlock was already made at
https://github.com/odoo/enterprise/pull/10740/files
Some contortions were made to avoid changing a signature method in a stable release and thus
introducing for each method a second one, with the "batched" implementation, to keep a retro-compatibility
for the existing custom code.
But surely this could be cleaned in the master version. The old one will be deprecated while waiting to be
removed in a few versions.
closesodoo/odoo#56534
Taskid: 2256705
X-original-commit: 8c96a887d3f05680c923dcd44f9c70c0e5e0bd32
Related: odoo/enterprise#12670
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
The method `_get_unavailable_intervals` was only available on
`resource.resource`. It's now moved to the `resource.calendar`.
closesodoo/odoo#51311
Taskid: 2253893
Related: odoo/enterprise#10616
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
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'`
Victor Feyens