| Age | Commit message (Collapse) | Author |
|
|
|
|
|
|
|
|
|
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
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
closes odoo/odoo#70486
Related: odoo/enterprise#18180
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
|
|
Steps to reproduce the bug:
- Let's consider an employee E that doesn't work on Monday morning
- Create a half day leave request LR for E on a Monday afternoon
- Save
Bug:
The duration of LR was counted as one day instead of 0.5
opw:2491784
closes odoo/odoo#68977
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
|
|
|
|
|
|
Purpose of this commit is to fix computation of access link. In some cases
msg_vals modification leads to invalid URL computation, notably for frontend
or backend differentiation for target recipients.
Followup of odoo/odoo#63292 .
Task ID-2513724
COM PR odoo/odoo#69607
ENT PR odoo/enterprise#17849
X-Original-Commit: odoo/odoo@2015ef463c9ac7c7f89d543745c02a2d1528acf2
|
|
|
|
|
|
|
|
In relativedelta, `day` means day of the month and `days` is for number
of days. Today, the demo data failed because the computed `date_to` was
before the `date_from`.
closes odoo/odoo#68627
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
|
|
|
|
|
|
Steps to reproduce the bug:
- Let's consider an employee E with 8.00 hours as Average Hour per Day
- Create an Allocation for E with a Time-off Type in Hours
(be sure the number of hours is different from the average hour per Day)
- Open the form view of E
Bug:
The smart button Time Off(remaining leaves) was completely unreadable
opw:2441019
closes odoo/odoo#66830
X-original-commit: c5282b15f4a9a785cb2ca44c58ab28ec4ee5f7ca
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
|
|
|
|
Purpose
======
Currently, in some rare cases, if the hr.employee.public is initialized before the hr.employee.public
table, this could lead to a traceback or even some inconsistencies when computing the field
current_leave_id, probably because of the MRO graph construction (to be investigated).
Specification
=========
1/ Ensure the table existence
2/ Set a dummy value for current_leave_id to force the recomputation to a valid one.
opw-2476677
closes odoo/odoo#67518
X-original-commit: 568ed9cde99bbcd6f3d390ec235c86c504466551
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Signed-off-by: Kevin Baptiste <kba@odoo.com>
|
|
|
|
|
|
A leave manager should be able to approve a time off that already begun.
opw:2447240
closes odoo/odoo#66481
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Co-authored-by: simongoffin <sig@odoo.com>
|
|
|
|
Steps to reproducr the bug:
- Let's consider an internal user U with no right in hr
- Let's consider an employee E linked to U
- Log with U
- Create a hr.leave H with hr validation
- Reset H to draft
- Delete H
Bug:
An access right error was raised.
opw:2443366
closes odoo/odoo#65993
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
|
|
|
|
Issue
- Install `Time Off` module
- Go to `Time Off` and switch to month calendar view (default view)
- Select range of date
In wizard, `duration` is not set.
Cause
`date_to` and `date_from` are overided on default get request.
Solution
Do not override default value of `date_from` and
`date_to` if provided in default get request.
opw-2447931
closes odoo/odoo#65830
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
|
|
|
|
Followup to odoo/odoo#65314: turns out there's a bunch of other leave
requests in the file which will eventually fall on a weekend, and will
probably blow up due to the new validation in 14.0:
- hr_holidays_sl_al in March 2021 because April 17th, 2021 is a
saturday
- hr_holidays_cl_mit_2 in June 2021 because June 5th, 2021 is a
saturday
- hr_holidays_sl_vad in September 2021 because September 25th, 2021 is
a saturday
- hr_holidays_sl_kim in April 2021 because May 1st, 2021 is a saturday
- hr_holidays_sl_kim_2 in March 2021 because July 3rd, 2021 is a
saturday
Solution
========
Instead of hard-coding month-days, move to the first monday after the
original date e.g. if we were looking for the 20, now get the monday
after the 22. In relativedelta terms, `weekday=0` is "the next
monday". The date is then formatted inclusive of the month-day rather
than hard-coding one.
One nit is for the end date:"the next wednesday" may come before "the
next monday" if we're on TU or WE. So we need to first jump to the
next MO *then* to the WE after that, which makes the code a bit
longer (and more redundant). As a result the end date is now "the
wednesday after <the start date>" rather than being a literal 2 days
later or whatever.
The PR updates all the 1-day and 2-day intervals, it also updates the
3 days inclusive (those over 3 which include start and end dates
rather than without) including those updated by #65314 for clarity /
coherence of small intervals. Longer intervals are left untouched,
although we may eventually want to update them so `number_of_days`
computations are more reliable.
Redundancy issues
-----------------
There are a bunch of redundancies / verbosities which don't seem
easy or possible to remove:
* While lxml does resolve entities by default it doesn't load
DTDs (let alone validate them), aliasing various datetimes
& deltas as entities is not an option, not to mention for security
reasons we'd rather stop resolving entities entirely than allow
custom ones.
* While it's possible to define nested safe_eval'd `context` on nodes,
the evaluation context for *those* contains neither datetime nor
relativedelta, so storing a bunch of constants in the (environment's)
context and using that in the expression is not an option either.
* Leaving `date_from`/`date_to` off of some records breaks, probably
because some other field necessary to properly compute *them* is
missing.
Other changes
=============
* Removed explicit settings to `number_of_days` and explicit calls to
`_compute_number_of_days`, seems redundant and unnecessary as the
compute works fine as long as we let it.
* While at it, updated the calls to `action_approve`: moved them next
to the corresponding record (instead of being on the other side of
the file) and used direct references to the subject records rather
than complicated searches.
* Also updated two leave allocations to be created validated OOTB
instead of manually calling action_validate as that's what's being
done elsewhere in the file.
Notes
=====
* In relativedelta lingo, "the next X" is inclusive of the current
date e.g. when looking for the next WE, if the date being offset is
already WE there will be no movement, this can be unexpected.
* Normally relativedelta would be used with the MO/TU/WE/... constants
for weekdays, but we're not exposing those to `@eval` so integer
literals it is.
closes odoo/odoo#65380
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
|
|
All fields not provided default to 0, so the the exact values are
`%Y-%m-20 00:00:00` - `%Y-%m-22 00:00:00`.
Because this is only 2 days it can entirely overlap with a week-end
(e.g. 2021-02-20/21), leading to `number_of_days` computed to 0 and
triggering an error at confirmation (`"The following employees are not
supposed to work during that period"`).
Change familly trip as the same issue would occure in May 2021
closes odoo/odoo#65314
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
|
|
|
|
Steps to reproduce the bug:
-Create a time-Off request R1 for 27/01
-Refuse R1
-Create another Time-Off request R2 for the same date 27/01
-Set R1 in draft
-Try to delete R1
Bug:
A ValidationError was raised:
You can not set 2 time off that overlaps on the same day for the same employee.
opw:2447540
closes odoo/odoo#65077
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
|
|
|
|
* = hr_holidays, im_livechat, website_livechat
A huge amount of components where rendered for no reason, notably when typing a
new message (at every key press), which significantly slowed down the interface.
There were 2 causes to this number of renders:
- OWL rendering all children automatically, even if their props didn't change,
unless `shouldUpdate` is overridden, which is now done.
- `useStore` selectors being way too generous in what they observed
task-2399731
closes odoo/odoo#62703
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
|
|
|
|
|
|
PURPOSE
Notification may be sent using a generic mail.thread record, notably when
sending user notifications. In that case links to view document are
incorrect.
HOW TO REPRODUCE
Issue
- Install "Approvals"
- Submit new approval with you as "Request Owner"
- Click on "View Approval Request" in your mailbox
The link redirects to a 505 error
Cause
The model is not the correct one and the res_id is undefined
Solution
Specify the model and the res_id to _notify_get_action_link
when creating the link with kwargs
SPECIFICATIONS
Propagate message value through various notification sub methods. That way
we can rely on them if model seems void.
Also limit values given as URL parameters to some white listed values.
LINKS
opw-2358846
Task ID-2379766
Followup of odoo/odoo#60998
Followup of odoo/odoo#61545
Closes odoo/odoo#63292
Closes odoo/enterprise#15585
closes odoo/odoo#64170
X-original-commit: 2b6d2b71f6c60bcf64db440473c88d1dc335acbf
Related: odoo/enterprise#15588
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Co-authored-by: Achraf Ben Azzouz <abz@odoo.com>
Co-authored-by: Thibault Delavallée <tde@odoo.com>
|
|
|
|
This translates 'Hours' when displaying the number of unpaid hours.
closes odoo/odoo#63821
Signed-off-by: agr-odoo <agr-odoo@users.noreply.github.com>
|
|
Steps:
- Install Time Off
- Go to Employees
- Click an employee (A)
- Change Work Information > Schedule > Working Hours to "Standard 38 hours/week"
- Go to Time Off > Managers > Time Off
- Click Create
- Select employee (A)
- In the title, select Unpaid
- From 2020-12-20 to 2020-12-24
Bug:
Float representation issue: 4.00 Days (30.400000000000002 Hours)
Explanation:
Changing formatting of `number_of_hours_text` from '%s' to '%g'. This affects the way this value is displayed: 0.0 Hours is now 0 Hours.
opw:2418740
|
|
|
|
Steps to reproduce the bug:
- Let's consider two users U1 and U2
- U1 is linked to employee E1 and U2 to E2
- E1 is the manager of E2
- U1 has the access rights Responsible for Time Off
- Create a leave request LR for E2 with a description D
- Log with U1 and open LR
Bug:
The description appeared like **** instead of displaying D
opw:2414759
closes odoo/odoo#63777
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
|
|
|
|
|
|
Currently, when we create time off and does not add 'Start Date' or
'End Date', it displays a wrong warning.
Issue is occur because date_from is required field at db level and it's
value computed based on visible field request_date_from which is
non-required field and when you keep that empty it will raisse the
contraint instead of required error.
So in this commit, we make request_date_field field required from view
and also make request_date_to visible based on condition so it should
fill the proper value inside the date_from and date_to.
closes odoo/odoo#59586
Taskid: 2352360
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
|
|
Unlinking it could be problematic if the synchronization is activated
with google or microsoft, as this action is prevented to avoid multiple
synchronization of the same event.
closes odoo/odoo#63135
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
|
|
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
closes odoo/odoo#62966
X-original-commit: d812a0a986339f841701399815dbedca3d3b2cf4
Signed-off-by: adwid <adwid@users.noreply.github.com>
|
|
|
|
task-2277511
closes odoo/odoo#61586
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
|
|
|
|
Courtesy of Transifex's translators for reporting bad/unclear sentences.
closes odoo/odoo#62539
Related: odoo/enterprise#15032
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
|
|
What are the steps to reproduce your issue ?
1. Install "google_calendar"
2. Log in with "admin"
3. Create an eventX with "admin" and "demo" has attendees
4. Run "Google Calendar Synchronization" from "Scheduled Actions"
What is currently happening ?
eventX is successfully added to Google but without admin
if you sync Odoo to Google one more time, Google will overwrite eventX
and it will remove admin from attendees
What are you expecting to happen ?
Sync Odoo to Google and Google to Odoo without lost attendees
Why is this happening ?
Because there is a filter that prevent addition of current user to the attendees
How to fix the bug ?
Remove the filter
This reverts commit 287ee0f83ae6fd457e5356860c8a8ab5a4e66754.
opw-2382443
closes odoo/odoo#62406
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
|