Closed
Bug 862262
Opened 12 years ago
Closed 12 years ago
[MMS][User Story] Message Expiry
Categories
(Firefox OS Graveyard :: Gaia::SMS, defect)
Tracking
(blocking-b2g:leo+)
RESOLVED
DUPLICATE
of bug 868218
blocking-b2g | leo+ |
People
(Reporter: khu, Assigned: gnarf)
References
Details
Attachments
(1 file)
1.55 MB,
application/pdf
|
Details |
MMS messages might come with a relative expiry time period. Retrieving an expired message results in a generic error returned to content page. Should we expose this field to content so that UX may define behaviours for such messages?
This is for MMS only, and this is used for manual retrieval mode. Sender won't know when the MMS will be expired, but the recipients know.
Should we implement this feature? Thanks!
Reporter | ||
Updated•12 years ago
|
blocking-b2g: --- → leo?
Flags: needinfo?(ffos-product)
Updated•12 years ago
|
Blocks: mms-userstories
Summary: Message Expiry → [MMS][User Story] Message Expiry
Comment 1•12 years ago
|
||
Checking the specs, I've not seen any special requirement about it, so I would avoid implementing this feature
Comment 3•12 years ago
|
||
Kevin, what happens now in the event that the MMS is expired and the user attempts a download of the attachment?
Flags: needinfo?(khu)
Comment 4•12 years ago
|
||
Hi Maria / Peter
I think form a UX perspective we are going to need this. If an undownloaded MMS has a 'shelf life' and the user attempts to manually download the message after this 'shelf life' has expired we need to inform them that the message cannot be received as it has expired and therefore been deleted.
Comment 5•12 years ago
|
||
(In reply to Peter Dolanjski [:pdol] from comment #3)
> Kevin, what happens now in the event that the MMS is expired and the user
> attempts a download of the attachment?
We have alreadt handle message expiry in Gecko. A generic error is returned upon trying to retrieve a already expired message.
Flags: needinfo?(khu)
Comment 6•12 years ago
|
||
Given Vicamo's description, it sounds like this can be handled by ensuring that the error strings are clear. Ayman, would that suffice from a UX perspective?
I would be happy to have this handled in new UX if risk is not increased with the added scope.
Updated•12 years ago
|
Flags: needinfo?(aymanmaat)
Comment 7•12 years ago
|
||
Case covered in wireframe pack:
HTML5_SMS-MMSUserStorySpecifications_20130429_V7.0
page 44
let me know if you require more information
Flags: needinfo?(aymanmaat)
Comment 9•12 years ago
|
||
Maria, please re-evaluate per Ayman's most recent comments.
Flags: needinfo?(oteo)
Comment 10•12 years ago
|
||
I agree with Ayman's proposal, I just only commented that I didn't see any specific requirement about it in Telefónica spec but if it's feasible and important from the User experience point of view, let's go for it!
Flags: needinfo?(oteo)
Assignee | ||
Updated•12 years ago
|
Assignee: nobody → gnarf37
Assignee | ||
Comment 11•12 years ago
|
||
I made a bug to deal with all of these expiry based messages according to Ayman's latest wireframes - It includes the "past the expiration" message
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → DUPLICATE
Updated•12 years ago
|
Flags: in-moztrap-
Updated•12 years ago
|
Flags: in-moztrap- → in-moztrap?
Updated•12 years ago
|
Flags: needinfo?(ffos-product)
Updated•12 years ago
|
Flags: in-moztrap? → in-moztrap-
You need to log in
before you can comment on or make changes to this bug.
Description
•