Closed Bug 919977 Opened 6 years ago Closed 6 years ago

[User Story][Messages] Support delivery reports

Categories

(Firefox OS Graveyard :: Gaia::SMS, defect, P1, blocker)

Other
Gonk (Firefox OS)
defect

Tracking

(Not tracked)

RESOLVED FIXED
1.4 S2 (28feb)

People

(Reporter: wmathanaraj, Assigned: steveck)

References

Details

(Keywords: feature, Whiteboard: [ucid:Comms28, 1.4, ft:comms])

Attachments

(8 files, 3 obsolete files)

User Story:

As a user I want an option to request delivery reports for sms and mms. 


Acceptance Criteria:

AC 1: As a user I want to be able to set this up independently for SMS and MMS.

AC 2: As a user I want a location to define default options for requesting delivery receipts but I also want to be able to define it on a per message basis.

AC 3: As a user I want to the per message basis configuration to override the default configuration.
Flags: in-moztrap?(jhammink)
Summary: [User Story] Support delivery reports for SMS/MMS → [User Story] Support delivery reports for SMS/MMS (FFOS 1.3)
Summary: [User Story] Support delivery reports for SMS/MMS (FFOS 1.3) → [Messages] Support delivery reports (FFOS 1.3)
Probably a dup of #899025?
Whiteboard: 919995
yeah, definitely one is the dupe of the other :)

Wilfred, I'll let you dupe and add the good flags to whichever bug you chose to keep.
Flags: needinfo?(wmathanaraj)
Whiteboard: 919995
Duplicate of this bug: 899025
Summary: [Messages] Support delivery reports (FFOS 1.3) → [User Story][Messages] Support delivery reports (FFOS 1.3)
Whiteboard: [ucid:Comms28, 1.3:p1]
Hi Wilfred, Gene and I have the same concern about AC 3 and bug 919974 comment 3. Is this scenario necessary for user about having per message configuration? It also involve lots of UX/gaia/api changes but user might not get many benefits from it.
This came out of operator requirements to pass their certification so they can fully support MMS - can I get an estimate of the work that would be required to implement this?
Flags: needinfo?(wmathanaraj)
If so, from the point of view of Gecko, we need to have more API changes for the sending function, which needs to eat some parameters to decide if it needs to request read report or not. Overall, read report on the Gecko side is aimed to be done at sprint 4 (11/8).
(In reply to Gene Lian [:gene] (needinfo? encouraged) from comment #6)
> If so, from the point of view of Gecko, we need to have more API changes for
> the sending function, which needs to eat some parameters to decide if it
> needs to request read report or not. Overall, read report on the Gecko side
> is aimed to be done at sprint 4 (11/8).

Sorry. I misunderstood. This bug is for delivery report not read report. Anyway, we still need to have API changes for requesting SMS/MMS delivery report. The timeline is still the same (sprint 4 for Gecko).
Just like bug 919974, comment #8 which said we don't need to support requesting read report per MMS for V1.3. The question is similar: do we need to support requesting delivery report per SMS/MMS (AC 3 at comment #0)?
Flags: needinfo?(wmathanaraj)
The same would apply here as in bug 919974
Flags: needinfo?(wmathanaraj)
Steal the in-moztrap? flag and start to analysis the user story
Flags: in-moztrap?(jhammink) → in-moztrap?(atsai)
To clarify, if there's a long sms. We'll separate the SMS into multiple SMS to align the limitation of SMS length. Will a user receive multiple delivery reports or one report for all?
Flags: needinfo?(wmathanaraj)
blocking-b2g: --- → 1.3+
Attached file FFOS_MessageApp_V1.3_20121025_V5.0.pdf (obsolete) —
**Release Note**

new wireframes
- none

updated wireframes
- none

deleted wireframes
- none

new flows
- Forward Message : Message from thread
- Delivery / Read report : Setting reports from within phone settings
- Delivery / Read report : Setting reports from message app inbox
- Delivery / Read report : Setting reports from within new message
- Delivery / Read report : Setting reports from within message thread
- Delivery / Read report : View report from thread
- Delivery / Read report : View delivery report from notification
- Delivery / Read report : View read report from notification
- Message Module Interactions : Long press and MMS
- Message Module Interactions : Tap on email address and MMS
- Message Module Interactions : Tap on url and MMS
- Message Module Interactions : Tap on phone number and MMS
- Anonymous messages : Thread

updated flows
- none

deleted flows
- none

pages relevant to this bug: 13 - 20
Assignee: nobody → evelyn
for concatenated SMS user gets one notification when the full SMS has been received and displayed to the user.
Flags: needinfo?(wmathanaraj)
Hi Rick, based on the previous sprint planing delivery reports was assigned to me. The reason I left the assignee open is because this user story is based on ux/gecko/gaia integrated work. I will open other small tasks for gaia implementation if needed. Please ping me if you or your member is also interested in and has free cycle for some help, thanks.
Assignee: evelyn → nobody
Depends on: 933131
Depends on: 933133
Priority: -- → P1
Target Milestone: --- → 1.3 Sprint 5 - 11/22
Blocks: 937014
Joe, this should be changed to sprint 6 because the target milestone for bug 933133 is sprint 6, right?
Flags: needinfo?(jcheng)
Duplicate of this bug: 875514
Whiteboard: [ucid:Comms28, 1.3:p1] → [ucid:Comms28, 1.3:p1, ft:comms]
Attached file FFOS_MessageApp_V1.3_20131119_V7.0.pdf (obsolete) —
**Release note***

new wireframes
- Subject : maximum length of subject reached
- Subject : maximum length of message reached
- Subject : subject field
- Message report : outgoing message report

updated wireframes
- none

deleted wireframes
- none

new flows
- Message report : View report for received message

updated flows
Delivery / Read report : Setting reports from within phone settings
renamed: ‘Message report : Setting reports from within phone settings’

Delivery / Read report : Setting reports from message app inbox
renamed: ’Message report : Setting reports from message app inbox’

Delivery / Read report : Setting reports from within new message
renamed: ‘Message report : Setting reports from within new message’

Delivery / Read report : Setting reports from within message thread
renamed: ’Message report : Setting reports from within message thread’

Delivery / Read report : View report from thread
renamed: ‘Message report : View report for outgoing message from thread’
- ‘View message details’ CTA removed from frame ‘2. Message module options menu’
- annotation to frame ‘3. Message Report’ updated to reflect agreement in email thread

Delivery / Read report : View delivery report from notification
renamed: ’Message report : View delivery report from notification’

Delivery / Read report : View read report from notification
renamed: ‘Message report : View read report from notification’

deleted flows
- none
Attachment #822328 - Attachment is obsolete: true
Flags: needinfo?(jcheng)
Target Milestone: 1.3 Sprint 5 - 11/22 → 1.3 Sprint 6 - 12/6
Attached file required_assets.zip
Attached image SMS.MMS.Message_report [SPEC] (obsolete) —
Hi everyone, 

Visual design related to Message Reports is ready. Please, ask me if you have any question.
Take this bug and start to create test cases
Flags: in-moztrap?(atsai) → in-moztrap?(pyang)
**Release note***

new wireframes
- none

updated wireframes
- none

deleted wireframes
Drafts : Message thread
Due to removal of specification for saving multiple drafts in a message thread

Drafts : Draft message module options
Screen obsolete due to removal of specification for saving multiple
drafts in a message thread

new flows
- none

updated flows
Drafts : Save as draft from within messages app
Removal of specification for saving multiple drafts in a message thread

Drafts : Save as draft when navigating away from messages app
Removal of specification for saving multiple drafts in a message thread

Drafts : Opening draft messages from within thread
Removal of specification for saving multiple drafts in a message thread

deleted flows
- none
Attachment #8334455 - Attachment is obsolete: true
Depends on: 943224
I think this bug should be moved to 1.4 too, is it ok Joe?
blocking-b2g: 1.3+ → 1.4?
Flags: needinfo?(jcheng)
Flags: needinfo?(jcheng)
Summary: [User Story][Messages] Support delivery reports (FFOS 1.3) → [User Story][Messages] Support delivery reports
Whiteboard: [ucid:Comms28, 1.3:p1, ft:comms] → [ucid:Comms28, 1.4:? ft:comms]
team decided to move this to 1.4
Target Milestone: 1.3 Sprint 6 - 12/6 → ---
Attached image SMS_reports
Attachment #8336257 - Attachment is obsolete: true
Depends on: 949379
This bug includes not merely delivery report, but for providing detail report of incoming/outgoing message information.  Can we modify title and pass criteria so that we can design test cases for spec changes?
Flags: sec-review?
Flags: sec-review? → sec-review?(ptheriault)
Flags: sec-review?(ptheriault) → sec-review?(stephouillon)
blocking-b2g: 1.4? → 1.4+
Wilfred, is AC3 still accurate? I see this nowhere in the current wireframes.

Also, should we close this bug since the basic functionality is covered and file a new one for the additional functionality we need (which is basically the live update mechanism) ?
Flags: needinfo?(wmathanaraj)
features should not block release, remove blocking flag
blocking-b2g: 1.4+ → ---
Blocks: 960372
Whiteboard: [ucid:Comms28, 1.4:? ft:comms] → [ucid:Comms28, 1.4, ft:comms]
Target Milestone: --- → 1.4 S2 (28feb)
yes makes sense to create a new feature for any additional features that is required. the basic feature should be landed now.

Addition features can be contributed by individual partners who need a detailed level of support.

the two below are the two critical features 

AC 1: As a user I want to be able to set this up independently for SMS and MMS.
AC 2: As a user I want a location to define default options for requesting delivery receipts but I also want to be able to define it on a per message basis.
Flags: needinfo?(wmathanaraj)
blocking-b2g: --- → 1.4+
features should not block. remove blocking flag
blocking-b2g: 1.4+ → ---
All the opened depended bugs are owned by someone. In order to make sure this user story is on track, Joe, do you think you could be the owner for this user story? Thanks. :-)
From comment 34, the "per message basis" is the only thing missing if I'm not wrong.
For AC 1 in comment#34, Does that means we need to separate the setting of |Delivery Report| into 2 separated settings for SMS and MMS.
If yes, in IMHO, this is quite weird and conflict to what we have done to untify the sms/mms into the sms application and provide a unified experience for delivery report.

Is it what we are going to change?
Flags: needinfo?(wmathanaraj)
I believe we've discussed this item in last work week, and the decision should be merge into one switch.
Flags: needinfo?(wmathanaraj)
Since this is high priority item, assign to steve as the remaining work required to finish this user story is all assigned to steve
Assignee: nobody → schung
Hi Joe,
Will we still need "per message" based configuration?
Heard from Steve that it's not in wireframe.
If this is the scope, bug 927716 can be removed from dependency.
Flags: needinfo?(jcheng)
No longer blocks: 960372
This was a feature we defined within the comms team? Is this feature a must have for Madai? 
We decided at the early stage that we are not going to do any per message configuration.

With this in mind is there any outstanding gecko work required for this bug?
NO, if per message configuration is not necessary for now, 
there is no gecko work required and we should remove bug 927716 from dependency.
According to comment 42, I'm removing bug 927716 from dependency.
No longer depends on: 927716
And since Bug 933133 is not necessary for the basic feature, I'm closing this feature bug as well, per comment 34.

yay!
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
No longer blocks: b2g--telephony-1.4
Blocks: 976427
Flags: sec-review?(stephouillon) → sec-review+
Flags: needinfo?(jcheng)
You need to log in before you can comment on or make changes to this bug.