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)

x86
macOS
defect

Tracking

(blocking-b2g:koi+, firefox26 fixed)

RESOLVED FIXED
blocking-b2g koi+
Tracking Status
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
Blocks: b2g-wap-push
Depends on: 891762, 853782, 853715
Summary: [WAP Push][User Story] SI/SL message handling → [User Story][WAP Push] SI/SL message handling
What are the acceptance criteria for this user story?
Would there be option for user to choose the way handling SL message?
blocking-b2g: --- → koi+
SI is used for text messages, SL has links.
Flags: in-moztrap?(echu)
QA Contact: echu
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)
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)
Whiteboard: [ucid:WAP-Push2], [FT:RIL] → [ucid:WAP-Push2, FT:RIL, KOI:P1]
QA can verify this user story.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Depends on: 911947, 911934, 911940, 911944
test completed with issues found.
Component: General → RIL
See Also: → 1067731
You need to log in before you can comment on or make changes to this bug.