The idea of current date_{from,to} computations is as follows:
The user selects the request_date_{from,end} (and optionally
request_hour_{from,to} and these inputs are then processed into a
date_{to,from}, taking into account the type of leave, the work schedule
(resource_calendar) and time zone (since date_{to,from} are saved in UTC
while the request_dates are stored in the user's timezone.
However, in practice this computation is very messy, resulting in
date_{to,from} needing to be specified in all demo data and test cases,
even though it should be derived from the request dates. Various
superfluous or poorly named methods also exist in this flow
(eg _get_start_or_end_from_attendance which really performs a timezone
conversion, the logic of which resource calendar to use is scattered
across the whole model etc).
date_{to,from} are used many times as inputs throughout the code, with
code being present te inverse compute request_date_{from,to} from these
values. However in reality this is not possible to do consistently.
Therefore with this commit, we restore request_date_{from,to} as the
sole possible inputs, with date_{from,to} being derived from them. In
addition, the timezone and resource calendar are consolidated into their
own fields, with a single computation method computing them.
task-3081565
Part-of: odoo/odoo#119317
Removed this test because
1. What it was testing doesn't make sense, namely the behaviour of
resource leave creation when you explicitly set the resource
calendar id of the employee to a different one than the one on the
current running contract, which is an inconsistent state that
generates warning messages when you try to do so.
2. The test wasn't testing that correctly because it was only testing
whether two resource leaves were created, but not whether they were
actually created in the two different calendars, which was not the
case.
Part-of: odoo/odoo#119317
Update (some) query counters according to runbot state.
Also make some tests deterministic when involving company name.
Task-36879 (Mail: Support MultiCompany Aliases)
closesodoo/odoo#135288
Related: odoo/enterprise#47345
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
This commit changes the behavior of the avatar card preview so that it
is now triggered on click instead of on hover and the previous behavior
of the click event (open chat) is therefore removed. It also adds the
functionality to the Message and Activity components of discuss so that
clicking on the avatar inside these components will also show the card.
It also makes sure that the id of the user is added to the persona even
if nothing indicates that it should.
task-3442819
closesodoo/odoo#131355
Related: odoo/enterprise#47084
Signed-off-by: Francois Georis (fge) <fge@odoo.com>
psycopg2.extras.execute_values was introduced in PR #101237
however it pypasses the override logic for cr.execute. As a result
1. --log-sql cannot log these queries
2. assertQueryCount cannot notice these queries
...
This commit create a new api cr.execute_values to support the same SQL feature
without losing the override logic for cr.execute
closesodoo/odoo#131190
Related: odoo/enterprise#47374
Signed-off-by: Rémy Voet (ryv) <ryv@odoo.com>
Steps to reproduce:
- Install Attendances app and Employee app
- Setup an employee with a contract which work entry source is from
attendance
- Change the working schedule to different timezone, for example
Asia/Hong_Kong
- By default the working schedule should be start to work from 0800 to 1700
- Now create an attendance in the first day of the contract, i.e.
1st May 2023, check in time 0700, check out time 2000
- The total work hours should be 13
- However, in the work entry, the genearted work entry is 0800-2000, only
12 work hours.
Current behaviour:
The generated work entry mismatches the value of the attendance
Expected behaviour:
The work entry should match the attendance
Explanation:
This issue is casued by the timezone issue. When the system generate
the work entry, it will calculate the date_from datetime and date_to datetime.
Then it will compare between the attendance and the date_from datetime to choose
the larger datetime to put inside the work entry as start time.
However, the date_from datetime didn't consider the timezone of the working schedule.
In the above example, Asia/Hong Kong time is UTC+8 time. Therefore if we convert
the attendance time back to UTC time. It is check in time 30 April 2023, 2300 to
check out time 1 May 2023, 1200. In the mean time, if we compare between the date_from
datetime (1 May 2023, 0000) and the attendance check in time (30 April 2023, 2300).
The system will take the date_from time and therefore the generated work entry time
is incorrect.
task-3468012
closesodoo/odoo#134533
X-original-commit: 2baf4e3ebcd9ce3beb47ee2881aa3e8bd8a74cbf
Related: odoo/enterprise#47007
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Co-authored-by: Yannick Tivisse <yti@odoo.com>
If the duration time off is greater than or equal to 1 day, then it
should be displayed as a whole day event.
Now it's not a case and can be misleading.
Moreover, this change increases querycount for the following reason:
When we create allday calendar event, on top of usual queries -
"calendar_event"."stop_date" and "calendar_event"."start_date" are read.
Note, start_date and end_date are only set for allday events.
task-3103848
closesodoo/odoo#113865
Signed-off-by: Sofie Gvaladze (sgv) <sgv@odoo.com>
Steps to reproduce:
-------------------
- install `hr_work_entry_holidays` module
- create an employee and add two contracts:
- from 2023-01-01 to 2023-06-30 with a full time (5/5) resource
which is expired
- from 2023-07-01 to 2023-12-31 with a partial time (4/5) resource
which is running
(doesn't work on Wednesday)
- create an allocation with 10 days
- with the employee, create two leaves:
- 3 days during the first semester with one Wednesday
- 3 days during the second semester with one Wednesday
Issue:
------
Leave duration is based on the current contract.
If we change the type of leave by modifying its days/hours unit,
we will get inconsistencies between days and hours for leave taken
in a period belonging to another contract.
Cause:
------
Expired contracts are not taken into account
when calculating the number of days and hours.
Solution:
---------
Add `close` state to contract search.
opw-3419380
closesodoo/odoo#132144
X-original-commit: 249f8c836f606c0dfc5f3b6e64ad9b319b5a4602
Signed-off-by: Sofie Gvaladze (sgv) <sgv@odoo.com>
Signed-off-by: Thomas Lefebvre (thle) <thle@odoo.com>
* = crm,hr_work_entry_holidays
This commit changes the value of the "QueryCount" as `mail_enterprise`
executes a new query to search for devices associated with the partner.
Task ID: 3123678
closesodoo/odoo#127198
Related: odoo/enterprise#43577
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
In order to display the unfollow link or not in emails or in the inbox, the
system need to query the followers of the document. This is what explains the
added queries.
See odoo/odoo#107978
Task-3061864
According to Wiktionary, French spacing is "the archaic practice (though
still current in French) of inserting a space around colons, semicolons,
question marks, and exclamation marks". This is not standard practice in
English and most languages of the world.
The purpose of this commit is to start purging the code from this typo,
as it may reflect poorly on the software for some people.
closesodoo/odoo#114533
Related: odoo/enterprise#37853
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
This fulfills the goal of searching and fetching fields in a single SQL
query. We introduce the new method search_fetch() for that purpose.
Also introduce method fetch() to fetch some fields for a recordset if
they are not in cache yet.
The call graph is as follows:
search() calls search_fetch()
search_read() calls search_fetch() and _read_format()
read() calls fetch() and _read_format()
search_count() calls _search()
search_fetch() calls _search() and _fetch_query()
fetch() calls _search() and _fetch_query()
The methods _search() and _fetch_query() are usually the ones to
override to implement business-specific logic. The method _search()
returns a Query object to retrieve the records that satisfy the given
domain and are accessible for reading. The method _fetch_query() uses a
Query object to retrieve fields from the database and store them in
cache.
Also use search_fetch() to save one query in search_read() and the
reading of one2many fields.
Part-of: odoo/odoo#112126
Steps to reproduce:
- Add a pubic holiday record, i.e., From 6 Feb 2023 to 7 Feb 2023
- Add a leave with the date conflicting the public holiday, i.e. From
3 Feb 2023 to 8 Feb 2023
- Regenrate the work entries and check the work entry in form view.
Current behaviour:
Missing leave_id on some work entries
Expected behaviour:
It should linked to the corresponding leave for the work entries that is
created by the leave, while public holiday work entries should keep leave_id
empty.
Explanation:
After calling contract._get_interval_leave_work_entry_type, the leaves should
be filted out the not related leaves so contract._get_more_vals_leave_interval
can get the correct vals. Otherwise public holiday will always return
{'leave_id': false} in contract._get_more_vals_leave_interval which will replace
the correct leave_id value.
closesodoo/odoo#112641
X-original-commit: 66b65074671063e762e09589c3977dec311fc9b3
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Purpose
=======
Add a new type on the working schedule, adding "Lunch" to Morning and Afternoon. It's mandatory,
because, if you don't do that, you can't assume the difference between a time that should be
recorded as extra hours and a time that should not be counted because it's lunch time.
A company is not another, so to be clear, they will define what are the imposed lunch time
where the employee is not paid during the week.
Specification
=============
Lunch between Morning and Afternoon
When a time period is under Lunch :
- There is no working entry generated for that period of time.
- If you work before the lunch time and after it, it's not considered as extra time.
- The employee is not paid for the Lunch time.
TaskID: 3102363
- Automatically compute the average number of hours per day on
resource.calendar;
- Don't allow to change the working hours of an employee when they have
a current running contract;
- Seperate smart buttons on resources to distinguish Material / Human.
task-3102517
closesodoo/odoo#109768
Related: odoo/enterprise#35718
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Update counters according to latest runbot counters. It allows to better spot
side effects of upcoming changes.
Task-2710804 (Mail: Clean MailThread Posting API)
Part-of: odoo/odoo#99482
Before this Commit, dates was not formatted based on user's language.
With this commit, we use format_date to correctly format dates.
closesodoo/odoo#108442
X-original-commit: 4da7129695f2619711f08ed7c36a37543deaa31d
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Before this commit, creating a leave for multiple employees
from the manager's page allowed to create leaves regardless
of the concerned employee's allocations.
After this commit, an error message will be displayed to inform
which employee cannot take that leave.
Also removes unused imports.
task-2995120
closesodoo/odoo#103733
X-original-commit: 636a8276e6797c1d8fe43da61d2fd26b558bfa45
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Probem:
With some time off type as default type in an allocation request
you get a traceback as soon as you try to open the allocation
request form.
Cause:
FIX commit [1] introduced the issue as it didn't consider the
possibility of a false date_from
Improvement 1:
Having a date_from False sets a False in the leave request name
displayed on the form, we change that to have an empty string
instead
Improvement 2:
The timezone bug fix in commit [1] is only applied on a specific
configuration, we applie it to all configuration of leave request
name
[1] 5a50dea2652cff014d9198f59265cf36a3ec1865
opw-2961344
closesodoo/odoo#99454
X-original-commit: 3b9a012e4a0839bc5da2daf51d56591d2863b4be
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Signed-off-by: Fockedey Martin (mafo) <mafo@odoo.com>
As part of hr_holidays B2B, the holidays allowances were moved from hr_leave_type to hr_leave_allocation.
This didn't allow to take a leave longer than the maximum duration of an allocation. Also, despite all the
allocations could have enough days for a certain leave, it was not possible to use all available days without
splitting the leaves across the different allocations.
This commit moves the holidays allowance to the hr_leave_type to remediate the issues described above.
task-2834887
closesodoo/odoo#98317
X-original-commit: 8c37d5c7cc397e517c43c1ec13a131b4b35e48b7
Signed-off-by: phwa-odoo <phwa@odoo.com>
In module mail, invalidating 'message_ids' on a mail thread also
invalidates its inverse field 'res_id' on messages. If you haven't
flushed it before, your cache will be inconsistent, as shown by the test
/mail:TestMailgateway.test_message_process_bounce_records_channel.
In module purchase_stock, add depends on report.stock.quantity. This
ensures that when the model is queried after changes in other models,
the data on which the SQL view depends is flushed to the database before
querying that model's table.
closesodoo/odoo#66938
Related: odoo/enterprise#16722
Signed-off-by: Raphael Collet <rco@odoo.com>
Co-authored-by: Vincent Schippefilt <vsc@odoo.com>
Purpose
=======
Currenlty an error is raise saying that a leave cannot be set accross
overlapping contracts.
But in this special case we could split the time off and allow this simple
action.
Taskid: 2836901
X-original-commit: 1012a7ea8033675b6ebab96922e124b04e5ed884
Part-of: odoo/odoo#94885
Purpose
=======
We currently prevent leaves overlapping several contracts to avoid messing
with the generated resource.calendar.leave.
In case the contracts are on the same resource calendar, this shouldn't be
an issue actually.
Taskid: 2836901
X-original-commit: 4e87c30bb136083153091e67e6dd9d9f64fa94c2
Part-of: odoo/odoo#94885
Prior to this commit if work entries/payroll was installed you could not
cancel a time off in the future if the work entries were generated for
that period, however you should still be able to cancel a time off as
long as the work entries have not been validated yet.
TaskId-2791386
closesodoo/odoo#94165
X-original-commit: 975ac8d2a1809bf7725d577b0fa9143a5b255e0d
Related: odoo/enterprise#28673
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
In 2685472 new computed fields were added in calendar_event. This commit
updates the query counter tests that were failing.
task-2685472
closesodoo/odoo#79654
Related: odoo/upgrade#3182
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
There were inconsistencies in the calls to `_render`.
* the view context could contain information that misled developers.
Indeed, the context and value of the view are not supposed to be found
in the rendering. Thus by calling `ir.qweb` with the name of the
template, we ensure that there is no unwanted information and in
addition the cache key is that of the name of the template which saves
a query.
* the context used for rendering was modified by a method on
`ir.ui.view`, except this is not information used by this model. There
is now a `_prepare_environment` method residing on `ir.qweb`. This
method allows to modify the value dictionary as well as the context in
which the rendering will be done. This preparation of the data as well
as my security check is done only once per rendering. This also saves
some queries
* Freeze options for rendering were inconsistent. It could be that
options on which rendering depends were not part of the cache key. Thus,
depending on the user who generated the generation of the rendering
function, there was or was not information in the template. For example
for automatic branding. This is no longer possible, because it is the
context that is used. The options serving as a cache key are only
recorded for information (for the profiling system for example). A
simplification of the `ir.qweb.field` models could be made.
The report rendering and call `ir.qweb` instead of `ir.ui.view`.
Part-of: odoo/odoo#85110
Purpose is to update counters according to current runbot's state. This eases
checking impact of future performance improvements done.
Task-2631088 (Appointment: profile and add performance tests)
closesodoo/odoo#85838
X-original-commit: b0c7a6397526ad2698fac0701e4323c019ea8bf6
Related: odoo/enterprise#25002
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Issue
-----
Via the field prefetch mechanism, when we need a value of one field
(not in cache of course), the ORM will prefetch all fields
(which has the attribute to `prefetch=True`, the default value of this
attribute is `True`) for all record ids in `_prefetch_ids`.
Then, for each translate fields (where translate is not a callable)
the ORM need to make a `LEFT JOIN` on the `ir_translation` to fetch the
translated value. For big model, it leads to a simple `SELECT` with
several `LEFT JOIN` on ir_translation but each LEFT JOIN have a cost
in the planner time (a small cost in the execution time) of PostgreSQL.
By example, for `product.template` (stock/sale/purchase installed),
there are 6 LEFT JOIN to get all translated fields (5 of this
fields are rarely used).
Proposed solution
-----------------
Deactivate the prefetch by default for all translate fields expect if
this field is the `_rec_name` of the model (which is more likely to
be used).
In the example on the `product.template`:
Without prefetching the translated fields, there is only one LEFT JOIN
(the name, which is translated but is the `_rec_name` of the model).
With the 6 translated fields to fetch, the
query takes 5 ms to plan and 2 ms to execute VS with 1 translate field,
it 1 ms to plan and 1.5 ms to execute.
Side change note
----------------
- All translate of fields of `website.seo.metadata` should be prefetch
to avoid lot of website errors (it is because, website put in cache data
in sudo before reading it without sudo)
- `description` (`mail.message.subtype`), `subject` (`mail.template`),
`body_html` (`mail.template`) should be prefetch to avoid lot of extra
query from mail module.
- `vat_label` (`res.country`) should be prefetch to avoid a extra query
for each website page.
- Increase some queryCount (when it is legit, due to `subtitle` of
`blog_post` or `description` of `event.type.ticket`, etc)
task-2738029
closesodoo/odoo#82896
Signed-off-by: Raphael Collet <rco@odoo.com>
Description of the issue/feature this PR addresses:
In hr_holidays, there is no information about the conflicting time off when a second time off is scheduled at the same time.
There is a validation error saying "You can not set 2 time off that overlaps on the same day for the same employee".
The validation error should display the conflicting time off
Current behavior before PR:
The validation error displays the following:
"You can not set 2 time off that overlaps on the same day for the same employee"
Desired behavior after PR is merged:
The validation error will display the following:
"You can not set 2 time off that overlaps on the same day for the same employee.
Existing time off: Mitchell Admin / Trip with Family : 24.00 hours / from 06/09/2021 to 08/09/2021 / To Approve"
task-2641682
closesodoo/odoo#76452
Related: odoo/enterprise#22490
Signed-off-by: Kevin Baptiste <kba@odoo.com>
A lot of counters are not up to date. Seems some optimizations were done
allowing to lessen query counters.
Task-2661036 (Performance tests data cleanup)
Prepares Task-36879 (MultiCompany Aliases)
Part-of: odoo/odoo#77845
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>
Update query counters according to last runbot state. This helps spotting
query counters change linked to this PR.
Task ID-2377974
Community PR odoo/odoo#61467
This module allows an employee to create leave requests or allocation
requests from their overtime.
Depending on the configuration of the leave type, the request can be
made from:
- "My Profile" for allocation which allows employee requests;
- Time Off dashboard for leave type with no allocations;
- The employee profile for the time off manager.
TaskID: 1904850
[IMP] hr_holidays{,_attendance}: leave allocation multi create
Change leave allocation create function to a multi create one.
Task ID: 1904850
This commit adds a new model `hr.attendance.overtime`.
When an employee checks out, an overtime entry will be created when:
- the option is enabled on the company;
- the employee worked more or less than the number of hours they
were supposed to work that day.
TaskID: 1904850
Base: seems related fields take only 1 extra query instead of 3
Crm: assignment seems to have been slightly improved. Some randomness still
happens.
Hr Holidays: seems it was further improved beyond space frontier
Hr Work Entry Holidays: seems it was further improved
Test mail: those tests were a bit random, seems random is gone (hopefully)
Test mail full: updated local counters
Test mass mailing: seems we gained one query, updated local counters
closesodoo/odoo#70504
X-original-commit: 8c215b3d60929166b3e60e2a4dfb2a6c70439046
Related: odoo/enterprise#18194
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
The purpose is to allow the user to have the opportunity to manage what is
going to be send as reminders. He can now access to the template or create
a new one when the type of reminder is email or sms. In case of a simple
notification, a new text field is added to add custom content.
Task ID-2191254
COM PR odoo/odoo#68443
UPG PR odoo/upgrade#2313
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Rob Coekaerts