imported google calendar events sound when they shouldn't

This sounds like it might be an indicator-datetime bug rather than a calendar-app bug.

Jamie, could you please attach a sample entry from the ical file that's causing unwanted event sounds? You will find the file(s) in ~/.local/share/evolution/calendar/*/calendar.ics where * generally includes "system" and may include other directories as well.

Here is an ical that should contain the event that sounded this morning. Ie, there is a calendar event for 10am local (US/Chicago) on 2016-01-13 that sounded the calendar alarm at 6am local (US/Chicago). This is a recurring event and I included all events with the 'SUMMARY:1 on 1 Chris/Jamie'. I have redacted the 'UID:' fields-- there were only two different ones (I guess depending on who created the event??) but I redacted the info with a string of the same length as what was previously there and kept the two UIDs unique.

@renato
please help to see if anything needs to be done on calendar app or backend

as Charles mentioned I believe it is a indicator problem. The indicator should check which kind of alarm the event has and play a sound or display the message based on that:

Until now I found 3 types:

BEGIN:VALARM
ACTION:[DISPLAY | AUDIO | EMAIL]

The indicator should check that and act as requested.

In my opinion this should be the indicator behavior for each action:

DISPLAY = Show the message without any sound
SOUND = Show the message with the sound
EMAIL = do nothing

Status changed to 'Confirmed' because the bug affects multiple users.

fwiw, the proposal in comment #6 sounds good.

Renato, thanks for working on some of the indicator-datetime backlog. =)

For this one, after the EDS engine collects all the alarms for an event, it should cull out the ones that have neither an audio_url nor display text, ie:

=== modified file 'src/engine-eds.cpp'
--- src/engine-eds.cpp 2016-02-03 16:33:39 +0000
+++ src/engine-eds.cpp 2016-03-29 17:53:12 +0000
@@ -960,7 +960,8 @@
             appointment.end = i.first.second;
             appointment.alarms.reserve(i.second.size());
             for (auto& j : i.second)
- appointment.alarms.push_back(j.second);
+ if (!j.second.text.empty() || !j.second.audio_url.empty())
+ appointment.alarms.push_back(j.second);
             subtask->task->appointments.push_back(appointment);
         }
     }

A few important notes:

1. I believe the clock app used to (and possibly still does?) write empty valarms, so when testing this or any other fix you should confirm that it doesn't break the clock. For backwards compatibility with existing clock-app alarms, we may need indicator-datetime to inject an Alarm if none is present for any event containing the "x-canonical-alarm" tag.

2. Most of indicator-datetime's EDS tests were created with output from clock-app, so new ical tests are needed to cover these other valarm action types.