856894 - Imported calendars that only support X alarm reminders should only allow editing X alarms

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: Gaia::Calendar, defect)

Description

[Jason Smith [:jsmith]]

In Zimbra's case, imported calendar events only can have one reminder. However, our current UX design allows for multiple reminders. So take the following scenario then:

1. I import my zimbra calendar with X event with a 5 minute reminder
2. I modify the event to add another 30 minute reminder
3. [Time passes] I check the event on my zimbra site

At this point, zimbra will list that there's a reminder for the event in 30 minutes. For an end-user, they'll probably think something didn't work here - I indicated I had multiple reminders in my calendar on my device, but zimbra says I've only got one. Now, let's continue that user scenario:

4. Edit the zimbra event to have a different reminder
5. Resync the zimbra calendar on device

Now, the calendar event will read off as having one reminder, not two. So whatever happened to that second reminder we originally declared?

The correct behavior we should do here is take into account that certain calendars will only support one alarm reminder and reflect the UI as such.

Comment 1

[Jason Smith [:jsmith]]

Don't think this blocks, but we should fix this. Here's why:

We're essentially confusing the user all over the place here making them think data was saved, when in reality, it wasn't saved at all, since the calendar server doesn't support multiple reminders. After that happens, things get really messy for the user, so they'll never really understand what alarm reminder(s) were actually set and why.

Comment 2

[Jason Smith [:jsmith]]

needinfo on Arun for UX input here

Comment 3

[James Lal [:lightsofapollo]]

This is initially more difficult then it sounds... Essentially what we should do is "round trip" edits by sending the server an event then re-syncing only that one event... Even then we would need some logic to show that we can only edit one alarm, etc...

Theoretically I would say this is a Zimbra bug not our bug as they should accept multiple alarms without modifying them.

Comment 4

[Jason Smith [:jsmith]]

As a point of comparison, what does other calendar client software do in this scenario in integrating a caldav provider that only supports one alarm per event?

Lightning? iCal? Google Calendar?

Comment 5

[Jason Smith [:jsmith]]

Bouncing over to the general UX alias to raise attention.

Comment 6

[Stephany Wilkes]

Assigning to Rob. Hope this can be informed, too, but some of the recent calendar work we've done. Rob, feel free to bounce this to Tribe (same with 857241) if you need some support.

Comment 7

[Stephany Wilkes]

Bumping to Casey since Rob is out this week.

Comment 8

[Casey Yee]

After talking with James about this, it seems like the issue is more of a Zimbra/server issue.  What happens with the multiple alarms when events are saved outside of our calendar app is something we don't have any control over.   

Besides this, it doesn't seem to be a way to be able to query the server if it supports multiple alarms on events or not.   If a user saves a event with multiple reminders, there is no guarantee that >1 reminders will be saved.   

We should research the issue further and find out:
a) if this is a really an issue
b) prior art around handling these cases

A possible work-around would be to re-fresh the event after saving and alert the user of any discrepancies.

Comment 9

[Jason Smith [:jsmith]]

(In reply to Casey Yee [:cyee] from comment #8)
> A possible work-around would be to re-fresh the event after saving and alert
> the user of any discrepancies.

That sounds reasonable actually. We could try to save the event, query an update for the event, and compare the results. Doing the comparison could tell us if we were successful or not and if we fail, report a useful error.

That will consume more network resources, but at least tells the user exactly what worked vs. failed and why.

Comment 10

[Casey Yee]

Agreed.  Just getting the team to research the options and will post results back to this bug.

Comment 12

[Jason Smith [:jsmith]]

Not a blocker, but this is awkward UX. We should try to get this fixed eventually.

Comment 13

[Stephany Wilkes]

UX has completed a spec for this. Please see the final that satisfies this bug on PAGES 6-7 of this document:
https://mozilla.box.com/files/0/f/867803710/1/f_8804934931

Comment 14

[Stephany Wilkes]

Attachment: Pages 6-7 address this bug.

Comment 15

[BMO Automation]

Firefox OS is not being worked on