Install CRM (we need the "Hide Private Message" record rule defined by
that module), create a meeting as of today, set a reminder of one day,
invite another user (Demo) as attendee, save. Edit, go to the options,
change the "Show time as" to "free", save => access error due to the
said record rule.
The reminder is handled by the `get_next_potential_limit_alarm` method
of the `calendar.alarm_manager` model. It uses a raw SQL query to
perform its search. It returns a dictionary of the different events with
data attached. Due to the "Hide Private Message" record rule, some
records are not accessible.
Original (reverted) 9c4b52000 fix was replacing the `browse` by a `search`
in order to filter out non-accessible records. That fix was later fine
tuned by (not-merged) 7dd93809c to exclude calendar's virtual ids. The
real fix is to filter out records in the original result dict.
opw-1974599
closesodoo/odoo#33209
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Co-authored-by: Raphël Collet <rco@odoo.com>
The `_search` is override in `calendar.event` to return both ids and
virtual ids of recurrent events. Calling `.get_recurrent_ids` after the
search is wrong.
The entire request has been copied from the original
`_find_allowed_model_wise` function defined in `mail.message` to ensure
his correctness.
The purpose here is to ensure every virtual event id is mapped to the
real event id so the original function doesn't throw KeyErrors for
virtual ids.
opw-1972563
closesodoo/odoo#33246
Signed-off-by: Julien Castiaux <Julien00859@users.noreply.github.com>
This reverts commit 9c4b52000f.
The fix of opw-1974599 is wrong. As the fix was fixing a corner case, it
is better to revert this one as it is breaking all recurrent events.
opw-1985498
opw-1985552
closesodoo/odoo#33206
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Install CRM (we need the "Hide Private Message" record rule defined by
that module), create a meeting as of today, set a reminder of one day,
invite another user (Demo) as attendee, save. Edit, go to the options,
change the "Show time as" to "free", save => access error due to the
said record rule.
Using a search instead of browse ensures record unavailable due to a
record rule are filtered.
Same as 54e970e
opw-1974599
closesodoo/odoo#32987
Signed-off-by: Julien Castiaux <Julien00859@users.noreply.github.com>
Create a calendar meeting using Mark Demo. In the options of the event,
set the meeting as "Show Time as" = "Free". Using the admin user, send a
digest (KPI Digest module, technical > emails > digest email > send
now). It raises an User Error because the template cannot be rendered.
The problem is due to the way the "Show Time as" is implemented, the
"Free" option is used to not show the meeting in the different calendar
views. The events are hidden thanks to a record rule "Hide Private
Meetings".
Each digest is sent using the context of each subscripted user and not
the SuperUser ID 1. The call to `search_count` on `mail.message` calls
the dedicated `_search` of `mail.message` and ultimately end up in the
overriden `_find_allowed_model_wise` method of message in calendar.
That method does a browse of all the record ids containing new
messages in their chatter, but fail with an access error due to the
above record rule. Because it fails, the `kpi_mail_message_total_value`
compute fails and the field is missing when rendering the template.
Using `search` instead of `browse` ensures records unavailable due to a
record rule are filtered out.
opw-1966664
closesodoo/odoo#32735
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Before this commit, Odoo notifies the user of all the recurring past
events, existing before the installation of the module Calendar (old
events imported when synchronizing with Google, for instance). This
occurs only the first time a synchronization with Google is made. This
occurs because Odoo notify all the events that occurs since the last
time it notified, and the first time you install the module the date of
the last notification is empty.
Now, when the module Calendar is installed, the date of the last
notification is set by default to the current date (the date of the
installation of the module)
opw-1942443
closesodoo/odoo#32535
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Have a recurring meeting, repeated until some date
Edit one of the instances and detach it (click on "update only this instance")
Edit the detached event and change some value
Save
Before this commit, a JS error was thrown saying that the field final_date was invalid
This was because the required attribute on this field was set to True, but the python
put the value of the final_date to False
After this commit, there is no error as we set this value to false, since the field
doesn't make sense for a non-recurring event anyway
OPW 1892426
closesodoo/odoo#28850
Be in the timezone Australia/Brisbane
On an object, create a Meeting activity
Create the calendar event and set a start date "tomorrow" at 7:00am
Now go back to the object to see the activity
Before this commit, the activity appeared as due "today"
After this commit, it is due "tomorrow"
OPW 1891110
closesodoo/odoo#28576
Try to access a recurring event.
The _search function defined in mail_message tries to read records,
building a list of ids.
They are given to the _search of calendar, which builds its custom SQL query
using the data it received.
Since it got recurring ids instead of real ones, we get:
SELECT id, ("calendar_event"."id" in (101,'101-2019011118000...
Bug introduced in f74f5edc77.
If we get such a request, we convert the virtual ids back to real ids.
Note that a similar conversion was done in calendar's override of "mail.message"
_search method, 'in the case it was asked on virtual ids'.
Note that as of this commit making messages on virtual_ids doesn't even work,
so it is possible that this mess was introduced for the chatter feature,
which has been broken before, and so all of it is useless.
closes#27474closes#28288closes#28621
opw 1928562
opw 1930763
opw 1935148
closesodoo/odoo#30827
Be in timezone Europe/Brussels, where, in 2018, the DST switch
happens on 2018-10-28.
Create a recurring event starting on 2018-10-27 until 2018-10-29
at say, 8am
For the days before the 28, the time of the event will be correct
Before this commit though, for the days after the 28,
the meeting time will be shifted by one hour
This is because the rrule took a TZ aware datetime, and generated recurring
event dates with that same TZ, i.e. the one in STD time
After, this commit, all the meetings are well scheduled at 8am,
OPW 1895315
closesodoo/odoo#27985
With a user in a distant timezone, like UTC +/- 11
Create a all day event.
Before this commit, the event was displayed across the wrong days
This was because the dates were converted from the user's timezone
into UTC before being stored.
Which is:
- start date at december, 12
- if the user's tz is utc-11: the date becomes december, 11 (at 1:00pm)
- at rendering, it becomes december, 11 (at 7:00am)
After this commit, we store the datetime field "as if" it were a date field
that is, we don't convert it to any particular tz
It is worth noting that, if one removes the allday mapping in the xml view,
an event that has been created as allday will get its start and stop date converted
to the browser's timezone, and will NOT be displayed as from 8am to 8pm as one could expect
This is considered as a limitation of the code, that was present before this commit anyway.
In any case, please do not revert this commit :D
OPW 1891110
closesodoo/odoo#27949
While start and stop are required fields, it is possible to trigger the
computation from the UI before saving (e.g. create an event, set no date, check
"all day" checkbox).
Fixes#27265
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
Since 76b7242 if we have a recurring event with 3 occurences:
[4th 4:00-4th 5:00] [14th 4:00-14th 5:00] [24th 4:00-24th 4:00]
And we detach the first one to modify it, then when getting the
info of reccurring events not detached the system get:
- starts: [14th 4:00] [24th 4:00]
- stops: [4th 5:00] [14th 5:00] [24th 5:00]
And wrongly apply the current filtering over:
[14th 4:00-4th 5:00] [24th 4:00-14th 5:00]
So the issue hides recurrences of event wrongly if:
- they have not been detached
- they don't have a duration of 0
- one or several previous events have been detached
- the stop date of the nth previous event occurrence (nth equaling
number of detached previous events) is not in the current filtering.
With this change, the stops are also filtered based on start of
occurrence + duration.
Without the change, the added test fails with:
False != '27-20120301120100' : Last event should be found searching it by date range
note: 11.0 version of 10.0 #26887
opw-1866151
closes#26901
- calendar.event.start and stop are expecting datetime and not date.
Now, if 'All Day' event, start time = 00h00 and stop time = 23h59m59s
- when switching from all day event to not all day event, due to
stop time = 23h59m59s, the rounding for duration leads to make the stop
pass to the next day (00h00). each time you switch between all day and
not all day, the duiration is incremented by 24h.
We remove 1 sec to event stop time to avoid this.
Now that Date/Datetime fields use python naive datetime, we want
to prevent developper to call or assign aware datetime to
fields. Moreover, if so, the timezone will be stored in the
database, but when reading Datetime fields, we expect naive datetime.
Comparing naive and aware datetime objects leads to errors.
This commit forces developpers to use naive datetime when saving
data in database.
As example, we have to erase the timezone of dates in calendar
modules. We also regroup the 2 assignations in one call to
`write` for performance reason.
Thanks to @dbeguin and @RomainLibert for spending some time
on this bug.
When fixing calendar search for recurring events we assumed that
no autojoin field will be used in this search.
The filter unread messages is based on message_ids from mail thread.
The solution here is to redefine this field in calendar to remove the autojoin.
When creating and editing a new calendar.event record from the calendar
view, the start_datetime field does not prefill from the day that was
selected on the calendar.
Introduced in e08f999468
opw-1875276
