835300 - [CALENDAR] [META] no notifications/alarm for event either ahead of event time or when the even time is reached

Status: RESOLVED INVALID

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

Description

[ayman maat :maat]

**DESCRIPTION**
no notifications/alarm for event either ahead of event time or when the even time is reached. Having notification or alarm that an event is either forthcoming or reached is expected out of the box functionality for end users of a Calendar, and its omission severely impedes the viability of the current Calendar application.

[TEF_REQ] as Feature required for TEF build.

Meta bug created to aggregate calendar notification / alarm bugs

Comment 1

[Jason Smith [:jsmith]]

Invalid. Technically for v1, we only supported imported alarms, which work the last time I checked. There is an edit feature for the future, but that's no longer part of v1.

Comment 2

[ayman maat :maat]

(In reply to Jason Smith [:jsmith] from comment #1)
> Invalid. Technically for v1, we only supported imported alarms, which work
> the last time I checked. There is an edit feature for the future, but that's
> no longer part of v1.

I am reopening this bug as the ability for an end user to receive a prompt in the form of an alarm or notification for an upcoming calendar event that the end user has entered into the calendar is a required product feature for Telefoncia. That does not mean it should be implemented in V1 and that is the reason I am not nominating for any triage.

I am happy to have this marked as a 'feature request' and open up a discussion about in what version this feature can be folded into the current Calendar app. I am also happy for it to be closed as a duplicate of a bug that this bug *actually* duplicating.

However it is not an option to mark this as invalid simply because it is not.

Comment 3

[Jason Smith [:jsmith]]

I don't see a reason to track this meta bug. Please use the underlying bugs for tracking.

Comment 4

[ayman maat :maat]

(In reply to Jason Smith [:jsmith] from comment #3)
> I don't see a reason to track this meta bug. Please use the underlying bugs
> for tracking.

I sense a distinct lack of cooperation from you Jason and an element of obstruction as we attempt to improve this product. 

As you are a member of Moz QA, as requested in comment 2, please feel free to associate to other bugs you see fit and please refrain from closing/invalidating until you have done so. thanks

Comment 5

[Jason Smith [:jsmith]]

(In reply to ayman maat :maat from comment #4)
> (In reply to Jason Smith [:jsmith] from comment #3)
> > I don't see a reason to track this meta bug. Please use the underlying bugs
> > for tracking.
> 
> I sense a distinct lack of cooperation from you Jason and an element of
> obstruction as we attempt to improve this product. 
> 
> As you are a member of Moz QA, as requested in comment 2, please feel free
> to associate to other bugs you see fit and please refrain from
> closing/invalidating until you have done so. thanks

Uhh...no. It's up to the owners of this component to determine how they want to track this - which is up to James, myself, etc. I don't want bug pollution, which is exactly what's going on. Please use the other bugs to track the issues.

We don't even know if and when we'll implement alarm support. We don't even have any of these things marked for tracking on a targeted release. Until that's done, there's no point to jump the gun trying to go feature control crazy when no one plans to work on this.