Closed
Bug 891248
Opened 11 years ago
Closed 11 years ago
[User Story][WAP Push] SI/SL message handling
Categories
(Firefox OS Graveyard :: RIL, defect, P1)
Tracking
(blocking-b2g:koi+, firefox26 fixed)
People
(Reporter: bhuang, Unassigned)
References
()
Details
(Whiteboard: [ucid:WAP-Push2, FT:RIL, KOI:P1])
User story: As an operator I expect both SI and SL to be handled the same as SI, to avoid any security concerns from users
Reporter | ||
Updated•11 years ago
|
Blocks: b2g-wap-push
Updated•11 years ago
|
Updated•11 years ago
|
Summary: [WAP Push][User Story] SI/SL message handling → [User Story][WAP Push] SI/SL message handling
Would there be option for user to choose the way handling SL message?
Updated•11 years ago
|
blocking-b2g: --- → koi+
Comment 3•11 years ago
|
||
SI is used for text messages, SL has links.
Updated•11 years ago
|
Flags: in-moztrap?(echu)
QA Contact: echu
Updated•11 years ago
|
Priority: -- → P1
Acceptance criteria from user story backlog: When a WAP Push SI message is received, user should be properly notified and content accessible. When a WAP Push SL message is received, the content should be displayed to user but the link should not automatically trigger.
Hi Bruce, As I review the SI spec, I come up with some test items, but that might not be implemented in v1.2, could you confirm the scope? 1. Acceptance criteria only requires receiving SI/SL. How about SI/SL that may be expired, out of order that need to perform delete and replacement before user reads it? 2. If WAP push message is sent with action attribute set, will we have to deal with it in v1.2? 3. Will SI/SL message be saved in any app in device that I can design test cases for device off, reboot and delete message scenario? If not, what is our design for received message? 4. If message can be saved, any limitation of how many WAP PUSH message can be saved? 5. If message cannot be saved, what is the UI flow after read the message? 6. What is the UI flow after receive a SL? Will there be pop up message to ask user whether he wants to execute it or not? Or will it look exactly like a SI?
Flags: needinfo?(bhuang)
Updated•11 years ago
|
Whiteboard: [ucid:WAP-Push2] → [ucid:WAP-Push2], [FT:RIL]
Attach reply from PM: > 1. Acceptance criteria only requires receiving SI/SL. How about SI/SL that may be expired, out of order that need to perform delete and replacement before user reads it? For expired messages, we should mark as "expired" or ignore if receiving when already expired. If there is an older SI received with the same ID, then we discard it silently. > 2. If WAP push message is sent with action attribute set, will we have to deal with it in v1.2? Yes, if the action is not "delete" or "none", then we display prioritized by high-medium-low. > 3. Will SI/SL message be saved in any app in device that I can design test cases for device off, reboot and delete message scenario? If not, what is our design for received message? > 4. If message can be saved, any limitation of how many WAP PUSH message can be saved? > 5. If message cannot be saved, what is the UI flow after read the message? > 6. What is the UI flow after receive a SL? Will there be pop up message to ask user whether he wants to execute it or not? Or will it look exactly like a SI? For 1.2 we will not store messages, so they should be received as notifications. SL messages are treated as SI except they can action on the link provided. Neo has provided a draft attached, we'll need to discuss further on how 1 and 2 are reflected in the flow:
Flags: needinfo?(bhuang)
Hi Bruce, Since there are some limitations that might not be able to support item 1 and 2 from previous comment, please let us know final scope for this user story(ex: not support priority, delete, replacement...), thank you.
Flags: needinfo?(bhuang)
Flags: in-moztrap?(echu)
Flags: in-moztrap+
Reply from PM: -If incoming message shares the same ID with an already received message already in notification: -- If new message has an older time stamp, drop the message -- If new message has a newer time stamp, display the message (since we can't replace) -Expired messages -- If message is already expired on receipt, drop the message -- If user taps an expired message, show "expired" on the full screen message content. (Neo, need your team's help on visual) At the moment we will not support: - Priority - action: delete - Replacing old messages by new messages with the same ID
Flags: needinfo?(bhuang)
Updated•11 years ago
|
Whiteboard: [ucid:WAP-Push2], [FT:RIL] → [ucid:WAP-Push2, FT:RIL, KOI:P1]
Comment 9•11 years ago
|
||
QA can verify this user story.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Comment 10•11 years ago
|
||
test completed with issues found.
Updated•11 years ago
|
Component: General → RIL
Updated•11 years ago
|
status-firefox26:
--- → fixed
You need to log in
before you can comment on or make changes to this bug.
Description
•