Closed
Bug 840050
Opened 12 years ago
Closed 12 years ago
[MMS][User Story] Messages app invoke from notification
Categories
(Firefox OS Graveyard :: Gaia::SMS, defect, P1)
Tracking
(blocking-b2g:leo+)
RESOLVED
WORKSFORME
blocking-b2g | leo+ |
People
(Reporter: pdol, Assigned: cassie)
References
Details
(Keywords: feature, Whiteboard: [LOE:M])
UCID: Messages-074
User Story:
As a user, when I click a received MMS notification, I want to be taken directly to the MMS message to make it easeir to read received messages.
Comment 2•12 years ago
|
||
The assumption is that this already works with the implementation of SMS, assigning to Bocoup to confirm.
Assignee: vyang → boaz
From a UX perspective, this should not be any different than what we already have in place with SMS.
Flagging Peter for NeedsInfo to confirm that the current implementation fulfills this requirement.
Flags: needinfo?(pdolanjski)
Updated•12 years ago
|
Assignee: boaz → cassie
Reporter | ||
Comment 4•12 years ago
|
||
(In reply to Casey Yee [:cyee] from comment #3)
> From a UX perspective, this should not be any different than what we already
> have in place with SMS.
>
> Flagging Peter for NeedsInfo to confirm that the current implementation
> fulfills this requirement.
It does. This requirement is basically in place to ensure that this continues to be the case with MMS.
Flags: needinfo?(pdolanjski)
Comment 5•12 years ago
|
||
Same for notifications. It's not a bug because it's already working, and we will ensure that this feature will be working as well with MMS. We should close these type of US due to there is no bug, there is no new feature. However, IMHO, these US are so confusing when checking the work to be done for MMS. Peter, Wdyt?
Flags: needinfo?(pdolanjski)
Reporter | ||
Comment 6•12 years ago
|
||
(In reply to Borja Salguero [:borjasalguero] from comment #5)
> Same for notifications. It's not a bug because it's already working, and we
> will ensure that this feature will be working as well with MMS. We should
> close these type of US due to there is no bug, there is no new feature.
> However, IMHO, these US are so confusing when checking the work to be done
> for MMS. Peter, Wdyt?
I'd prefer to verify that this works with MMS first (although it is the same app, this should be a quick verification once MMS is working).
Flags: needinfo?(pdolanjski)
Comment 7•12 years ago
|
||
Per partner and release-driver discussions, marking blocking- until all MMS functionality in bug 849867 is complete, allowing it all to be uplifted at once to avoid SMS bustage.
blocking-b2g: leo+ → -
Updated•12 years ago
|
Flags: in-moztrap?
Comment 8•12 years ago
|
||
leo+ as this is a part of MMS and part of v1.1 to be included in leo+ queries. No_UPLIFT for now before the whole MMS is completed
blocking-b2g: - → leo+
Whiteboard: [LOE:M] → [LOE:M] [NO_UPLIFT]
Updated•12 years ago
|
Assignee: mike → cassie
Updated•12 years ago
|
Whiteboard: [LOE:M] [NO_UPLIFT] → [LOE:M]
Comment 10•12 years ago
|
||
Comment #6 is a noisy way of doing this. The MMS functionality is an iteration on the existing SMS code. Closing this, and QA will reopen when testing if for some reason the devs regress this functionality.
Updated•12 years ago
|
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•