During the revamp (https://github.com/odoo/odoo/pull/138670) the
classes `.o_event_hatched` and `.o_event_striked` were moved.
The `o_event_hatched` works on day, week, and month
view but not in Year view of the `hr_holidays` module where the events
all look like they have the same status. The `o_event_striked`
was removed by mistake.
To fix this issue, we move the `.o_event_hatched` where it isn't under
the `.fc-event` selector (because this one doesn't exist in Year view),
and we put back `o_event_striked`.
task-3617333
part of task-3575827
closesodoo/odoo#144208
Signed-off-by: Romeo Fragomeli (rfr) <rfr@odoo.com>
__getitem__() of BaseModel, reset the prefetch set of the recordset.
Fix _compute_activity_date_deadline, to batched the reading of
activity's deadline.
closesodoo/odoo#154860
X-original-commit: ef7226aaa2f0ad135133fe27bdf1414b7ebf2a92
Signed-off-by: Rémy Voet (ryv) <ryv@odoo.com>
Steps to reproduce:
- Calendar > create an all_day meeting with an additional attendee
- Save > Edit > change starting date to a later day > traceback
Cause of the issue:
The write call of the method _onchange_date is applied to a pseudo record.
However, the write method expects a record with an integer id to
correctly _send_mail_to_attendees down the line.
Fix:
Since we don't want to send_mail_to_attendees anyway, we skip this part
of the write method using the already existing contextual escape
'is_calendar_event_new'.
opw-3733753
closesodoo/odoo#154091
X-original-commit: f206781b3f4cababa4e69c8c9586f0f5406acc83
Signed-off-by: Lancelot Semal (lase) <lase@odoo.com>
Description:
Domains of the form
```python
[('stored_Many2X.id', '=/!=/in/not in', list_of_ids)]
```
will force the ORM to generate a sub-`SELECT` (or `LEFT JOIN` in
case of `auto_join=True`), which is inefficient, as the `id` can be
retrieved directly from the current `model` table, instead of going
to fetch it from the `PKey` of the `comodel` table.
There is just one *important* detail - in the sub-select, the `ir.rule`
of the `comodel` is applied, which is not the case when directly
referencing the `field` from the `model`. So in some cases using an
explicit `.id` would be a wanted, if the intention was to apply the
`ir.rule`.
Fix:
Remove the `.id` from left leafs of domains that if the field is
stored, and the `comodel` doesn't have `ir.rule` associated with it,
or the `ir.rule` application is redundant/not needed.
task-3735923
closesodoo/odoo#153464
Signed-off-by: Leonardo Pavan Rocha <lpr@odoo.com>
Since PR #137969, the `save` button is no longer available in schedule activity
wizard.
This PR makes `schedule` button available for call activities like other
activities (except meeting), so user can create a call activity without going to
calendar view.
Also, we have to consider `has_error` in creating activity so if there is an
error, user couldn't access to `schedule` button. This field is correctly placed
in `mail.mail_activity_schedule_view_form` view but not in the inherited view
in `calendar`.
task-3668732
closesodoo/odoo#152893
Signed-off-by: Maryam Kia (maki) <maki@odoo.com>
Steps to reproduce:
1. install the calendar module
2. in General settings, add the French -or any- language
3. create a new event
4. under **Options** tab choose the recurrence type to be weekly
5. select the days to repeat the event on
6. save the event
7. send an email using the **EMAIL** button, you can notice that works like (Weeks) and the days’ names are not translated but still in English
Investigation
- the translation is applied on the model level, not on the code level. So we have to explicitly/programmatically translate the options.
Discussion
- In the proposed fix, we compute the recurrence rule `name` by translating it to the current language -the event creator's language- but as this field is **stored**, it resulted in another issue that the invitation emails sent to the participants had a mix of languages: the email template being translated in each participant's language while the recurrence rule itself is translated in the owner's language being a **stored** field
- That's why the fix got extended to embed translating of the recurrence rule directly into the template.
- However there's a **_limitation_** we couldn't deal with that's there are two types of emails we are concerned with:
- invitation emails that follows `calendar attendee` model which works correctly as discussed
- update emails that follows `calendar event` model coming from the composer which deosn't allow to properly use partners/participants languages
Resolution
- The update emails are sent in the owner's language, with the intention to enhance the behavior in master (Task-3677327)
opw-3483319
closesodoo/odoo#151669
X-original-commit: 1d6d12ab67ffc96719c3c329cdba1cc3e3471f36
Signed-off-by: Arnaud Joset (arj) <arj@odoo.com>
Signed-off-by: Ali Hassan Youssef (alhy) <alhy@odoo.com>
ba1a550#diff-36973ac6e1f20b32a00fbcdc1f811c923bbb44ca15a0e068018e904ff565644fR97
The previous PR added some constraints on what can be used on the
context of views. The key word 'force-email' is no longer relevant and
will be removed from the context before reaching the next view/python
code.
This commit's purpose is to remove the force_email that were forgotten.
In order to still open the simplified partner form view, the ref of the
view is given in the context instead. While at it, we also fix the
create option given on the partner_ids field that was inconsistent.
affected version 17.0 - master
task - 3538000
https://www.odoo.com/web#id=3538000&menu_id=4720&cids=1&action=333&active_id=4105&model=project.task&view_type=form
Please enter the commit message for your changes. Lines starting
closesodoo/odoo#149806
Related: odoo/enterprise#54549
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Before this PR:
Canceling an activity linked to an event produces error because of non provided
thread.
Steps to reproduce:
- Create an activity with event (call or meeting) in chatter
- Try to cancel this activity
- There is an error about undefined thread and activity remains on the chatter
After this PR:
- Thread is provided in `onUpdate` method to use in `load()` in chatter
- `activityService` deletes the activity with event in `unlink` patch
closesodoo/odoo#152737
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
For a first iteration, Russian translations were done using DeepL using
1 large .pot file of all the standard modules to translate (e.g. no
localizations, no test modules, etc). Unfortunately for some reason
doing a msgmerge with the existing ru.po files didn't seem to work, so
old "Translators" metadata at top of files were lost (maybe they will be
re-added during next Transifex sync?)
Part-of: odoo/odoo#152285
In calendar if you delete the end_date, switch to all_day event and set both
start_date and stop_date and try to create the event, it will raise an error
because `end` is not set. This is due to 'end' being a required field and the
end_date not setting the end value. This commit adds an onchange to properly
set the start and stop values from the start_date and stop_date.
task-3682608
closesodoo/odoo#151910
X-original-commit: ff431fc02df59b731ea2a8a7051c1e1d42581637
Signed-off-by: Arnaud Joset (arj) <arj@odoo.com>
After https://github.com/odoo/odoo/pull/118738, we start generating a single
cron trigger per recurrence, however it fails to create the cron trigger for
daily recurrences. The main issue happens when the cron is run after the first
trigger of the recurrence. Imagine we have an alarm of 5 minutes before the
event, the call for_setup_alarm from _send_reminder will try to get the next
event in the recurrency to notify. However, the SQL query uses
`WHERE start > now` and if the cron trigger runs before the event is started
(most cases) this query will return the event that we're notifying. This commit
fixes this by checking event by event which is the next alarm tha should be
triggered and passing that date in the context of the `_setup_alarms` call.
How to reproduce?
Install calendar
- Create a recurring event with daily recurrence repeating for 3 days. Invite
Demo, set an email alarm for 5 min before the event and create the event
- A cron trigger will be created for 5 min before the event
- Change your computer's time so that it is 5min before the event
- The cron trigger will be called and it should create a new cron trigger for
the other day, however no cron trigger is created
Issue: SQL query in _setup_alarms in calendar.recurrence is getting the first
event with start > now, however it returns the event that was already notified
Solution: process event by event and check if its last alarm was already set.
If it was, we'll generate an alarm for the next event. If not, we'll use the
same event for the _setup_alarms call
For SMS alarms, we would not even create triggers for recurring events, so this
commit also fixes that.
task-3663455
closesodoo/odoo#151623
X-original-commit: 2da5bf6e9184db23836ea458a1fc53e27be49a1e
Signed-off-by: Arnaud Joset (arj) <arj@odoo.com>
Signed-off-by: Leonardo Pavan Rocha <lpr@odoo.com>
In 17.0 the calendar view was revamped and the boolean field `all_day` started
being rendered with the boolean_toggle widget. This widget, however, behaves
differently than the boolean widget without passing explicit props. This caused
the onchange call not to be made after this change. This commit fixes this by
passing the autosave option as False on the field.
task-3669879
closesodoo/odoo#148874
Signed-off-by: Arnaud Joset (arj) <arj@odoo.com>
In some case, the author should be notified. For example, in the
case someone books or cancels an appointment. The current user should
be notified as it's a proof that the action worked correctly.
This commit prepare a method that can be overriden to allow this process.
task-3505819
closesodoo/odoo#151319
X-original-commit: 9dff32354b0b6534ad707160459a9cd2514965f5
Related: odoo/enterprise#55221
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Jérémy Hennecart (jeh) <jeh@odoo.com>
After revamping the calendar event form view, the warning that is shown when an
attendee doesn't have an email set started being rendered in a single column,
making the warning be super shrunk. This commit fixes this by forcing the
renderer to use 2 columns for the warning.
task-3613118
closesodoo/odoo#144514
Signed-off-by: Arnaud Joset (arj) <arj@odoo.com>
The `calendar notification` tests patch the `setTimeout` function.
This sometimes leads to infinite recursion when the `multi_tab`
service has enough time to initialize: this service make use of
`setTimeout` to call the `heartbeat` method repeatedly. Moreover,
patching the `setTimeout` method is not a good idea since it makes
this method synchronous which totally changes the flow that is tested.
This PR fixes this issue by using the `contains` helper instead: this
method will wait for the element to be inserted in the DOM and perform
the assertion afterwards.
closesodoo/odoo#147503
X-original-commit: 973db5a
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Signed-off-by: Matthieu Stockbauer (tsm) <tsm@odoo.com>
Before this commit, attempting to do
`self.env['calendar.event'].write({'partner_ids': [0, 1, 2]})`
would give a traceback as the method that updates attendees
only supports parsing commands, not ids.
This is a problem as that method is called from 'write' and other methods
with the assumption that partner_ids can only contain commands.
This will not be the case when using a gantt view and grouping
by partner_ids for example, and cannot be worked around.
task-3452277
closesodoo/odoo#146446
X-original-commit: 88e191132bf40a4e3090077f1fd0077e649eb7fb
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Signed-off-by: Renaud Thiry (reth) <reth@odoo.com>
__Current behavior before commit:__
`_compute_meeting` computes the meetings linked to the children of the
partners in `self`. To do so, it first retrieves all children partners
of `self`, then it loops through all of them to apply the meetings to
the parents.
This way of doing is inefficient because it is useless to iterate over
the children that don't have any meetings.
__Description of the fix:__
Loop only through the partners that have a meetings instead of all
children partners.
Improve `test_meeting_count` to test the case where only the child
partner has a meeting but the parent has initially none. This test
improvement is a forward port of [#144575][1].
__Benchmark:__
| len(all_partners) | w/o fix | with fix |
| ----------------- | ------- | -------- |
| 1k | 32 ms | 14 ms |
| 100k | 1500 ms | 800 ms |
opw-3511371
[1]: https://github.com/odoo/odoo/pull/144575closesodoo/odoo#146381
X-original-commit: e35949cdd09b4312a60383b79290008e78768b64
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Julien Launois (jula) <jula@odoo.com>
To reproduce
============
- Create a meeting activity from any document (for example CRM opportunity) with a calendar.
- It will create a meeting in the calendar.
- Now, mark as done the activity created and it will delete the meeting from the calendar too.
revert of https://github.com/odoo/odoo/pull/144526
opw-3626773
closesodoo/odoo#146421
X-original-commit: 0b183299a8ef7361d28d9d2b49cc56b74bfb2b46
Signed-off-by: Abdelouahab Laaroussi (abla) <abla@odoo.com>
Issue:
======
Marking an activity of calender event as marked with text raises an
error.
Steps to reproduce the issue:
=============================
-Go to any contact and create a meeting with him as an activity in the
chatter.
- Mark the actvity as done and add some text as feedback.
- An error showing that the record is deleted.
The issue already solved here , this commits only add the test.
opw-3623719
closesodoo/odoo#146045
X-original-commit: 787f2f44961b9b5283b7bdc944acc2e8284212cc
Signed-off-by: Mahdi Cheikh Rouhou (macr) <macr@odoo.com>
Issue:
======
Attachment files aren't sent with the event invitation email.
Steps to reproduce the issue:
=============================
- Add any attachment to the email template : `Calendar: Meeting
Invitation` and save it.
- Go to website and book an appointment.
- Go to Scheduled Actions and run manually email queue manager to send
the notification.
- The sent email doesn't have the attachement you provided, it has only
1 attachement which is the calendar one.
Origin of the issue:
====================
The notification of the event invitation was taking only the calendar as
attachment and ignores the template attachemnt.
Solution:
==========
Now the calendar event invitation email will take into account the
attachment of the email_template.
opw-3593140
closesodoo/odoo#145628
X-original-commit: 28880c32e62b6e2e6c87c35094da0e20c6c14c21
Signed-off-by: Mahdi Cheikh Rouhou (macr) <macr@odoo.com>
The sequence is equal to 10 and it is causing issues during upgrade. The order used by the menus is _order = sequence, id
As the menu has a new xmlid, it will be placed after the existing one because if his sequence. We could
1) lower the sequence value
2) don't provide a sequence (menuitem is noupdate False) and update the value in the upgrade script.
Proposal 1 is chosen as it does not require an upgrade script.
closesodoo/odoo#144716
Taskid: 3618126
Signed-off-by: Arnaud Joset (arj) <arj@odoo.com>
Before this commit:
When we try to delete a Meeting type Activity from the technical menu
"Settings > Technical > Activities" it do not delete the associated calendar
event.
After this commit:
The calendar event will be deleted when the associated Activity gets deleted.
task-3493426
closesodoo/odoo#144674
X-original-commit: 71dc58acfcc4589bc5996b48e157aea6b0f8a609
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
The color was only used on the calendar event form view, but it was ignored in
these other views.
closesodoo/odoo#144621
X-original-commit: cab9ccb2f9f4168f03ad97b34e2fb6a7474a53a3
Signed-off-by: Leonardo Pavan Rocha <lpr@odoo.com>
Before this commit, when a user was invited to an event from an account outside Outlook (e.g. Google account), accepting the invitation in Outlook Calendar didn't send the 'accept' status to Odoo Calendar, and vice-versa. This problem was also happening with recurrent events accepted in Outlook, the events weren't being accepted in Odoo Calendar correctly. Additionaly, when 2+ attendees from Odoo were synced (having the organizer as an external user), only the last user to sync the event was able to answer it in Odoo due to its outdated 'microsoft_id'.
After this commit, both ways are fixed: accepting an event in Outlook Calendar or Odoo Calendar notifies the other calendar correctly. For recurrent events, accepting them in Outlook Calendar also updates the events status to 'accept' in Odoo Calendar (reminder: due to a limitation in Outlook Calendar synchronization, when the synchronization is active recurrent events acceptance can only be done through Outlook). In addition, all attendees from Odoo can now answer an event that came from external organizers.
closesodoo/odoo#144690
Task-id: 3290922
X-original-commit: a0e628985a19f732830a1f4a732ee35e5f779fe1
Signed-off-by: Arnaud Joset (arj) <arj@odoo.com>
Signed-off-by: Gabriel de Paula Felix (gdpf) <gdpf@odoo.com>
Steps to reproduce:
-------------------
- be in UTC -5 (America/Lima for example)
on the system (and so browser) and the user profile;
- create an event from 4pm to 5pm the next day;
- be at 2pm today;
Issue:
------
We have a notification in activities for this
event today, which is one day too soon.
Cause:
------
To find the events that need to be notified to the user, we use a domain which, in this case,
can be expressed as follows:
```
(
the `start` of the event must be after "now" (the event has not yet passed)
OR
the event `stop` must be after now (the event is in progress)
)
AND
the `start` of the event must be less than the end of the day (the event must be today)
```
The end of the day must be determined, but taking into account the user's timezone.
As the domain has to work with UTC values (because the `start` and `stop` values of the event are in UTC in DB),
in order to determine the end of the current day, we first need to determine which day the user is in UTC.
Logic before this commit (using the example):
```py
start_dt = datetime.datetime.utcnow() # 19:00 (because 14h in America/Lima -5)
start_date = timezone(tz).localize(start_dt).astimezone(UTC).date() # 00:00 next day
end_dt = datetime.datetime.combine(start_date, datetime.time.max) # 23:59 next day
end_dt = timezone(tz).localize(end_dt).astimezone(UTC) # 4:59 second next day
```
The result (for an America/Lima timezone) is that if the event has its `start`
in UTC before 4:59 two days later, the event will be notified.
Solution:
---------
Correct the values used to construct the domain.
Logic after this commit (using the example):
```py
start_dt_utc = now_utc.replace(tzinfo=UTC) # 19:00 (because 14h in America/Lima -5)
start_dt = start_dt_utc.astimezone(user_tz) # 14:00 (because 14h in America/Lima -5)
stop_dt = datetime.datetime.combine(start_dt.date(), datetime.time.max).replace(tzinfo=user_tz).astimezone(UTC) # 4:59 next day
```
Because 23:59 today using user timezone and then converted to UTC gives 4:59 next day.
In fact, the day of a user in the America/Lima (UTC -5) timezone ends in UTC at 4:59 the next day.
If this same user creates an event that starts at midnight (and therefore tomorrow),
the activity must not be displayed before midnight and therefore 5:00 the next day in UTC.
opw-3523558
closesodoo/odoo#144064
X-original-commit: 5a997d34f53d4b00e230b4a9d3131a015b190548
Signed-off-by: Arnaud Joset (arj) <arj@odoo.com>
Signed-off-by: Thomas Lefebvre (thle) <thle@odoo.com>
Before this commit, with the synchronization with Outlook active, it was not possible editing the organizer of an event to a different user than yourself or even creating a new event with a different organizer because Outlook didn't accept the change.
After this commit, it is possible creating a new event with this characteristic and changing the event's organizer to a different user too. Changing the organizer will delete the current event and create a new one, and creating a brand new event will create the event directly with the different organizer.
closesodoo/odoo#140820
Task-id: 3450045
X-original-commit: 81601d5
Related: odoo/enterprise#50080
Signed-off-by: Arnaud Joset (arj) <arj@odoo.com>
Signed-off-by: Gabriel de Paula Felix (gdpf) <gdpf@odoo.com>
Before this commit, the test was trying to send mail for a past event.
It would fail with the following error:
```
FAIL: TestCalendar.test_event_creation_mail
Traceback (most recent call last):
File "/data/build/odoo/addons/calendar/tests/test_calendar.py", line 329, in test_event_creation_mail
_test_one_mail_per_attendee(self, partners)
File "/data/build/odoo/addons/calendar/tests/test_calendar.py", line 311, in _test_one_mail_per_attendee
self.assertEqual(len(mail), 1)
AssertionError: 0 != 1
```
https://runbot.odoo.com/web/#id=29871&view_type=form&model=runbot.build.error&menu_id=405&cids=1closesodoo/odoo#141411
X-original-commit: 2b0bedf5a57ca2733501359fb8cc8e5bc743a4fa
Signed-off-by: Arnaud Joset (arj) <arj@odoo.com>
Currently the calendar integration can be accessed from the cog menu when in
the calendar module in the calendar view. However, it is a bit hidden. This
commit removes the button for calendar integration in the cog menu and also we
move the calendar integration settings from the general settings to a new
calendar specific settings page.
task-3570053
Part-of: odoo/odoo#139736
Elisabeth Dickinson