919977 - [User Story][Messages] Support delivery reports

Status: RESOLVED FIXED

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

Description

[Wilfred Mathanaraj [:WDM]]

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.

Comment 1

[Rick Waldron [:rwaldron]]

Probably a dup of #899025?

Comment 2

[Julien Wajsberg [:julienw]]

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.

Comment 4

[Steve Chung [:steveck]]

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.

Comment 5

[Wilfred Mathanaraj [:WDM]]

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?

Comment 6

[Gene Lian (I already quit Mozilla)]

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).

Comment 7

[Gene Lian (I already quit Mozilla)]

(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).

Comment 8

[Gene Lian (I already quit Mozilla)]

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)?

Comment 9

[Wilfred Mathanaraj [:WDM]]

The same would apply here as in bug 919974

Comment 10

[Al Tsai [:atsai]]

Steal the in-moztrap? flag and start to analysis the user story

Comment 11

[Al Tsai [: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?

Comment 12

[ayman maat :maat]

Attachment: FFOS_MessageApp_V1.3_20121025_V5.0.pdf

**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

Comment 13

[Wilfred Mathanaraj [:WDM]]

for concatenated SMS user gets one notification when the full SMS has been received and displayed to the user.

Comment 14

[Steve Chung [:steveck]]

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.

Comment 15

[Kai-Chih Hu [:khu]]

Joe, this should be changed to sprint 6 because the target milestone for bug 933133 is sprint 6, right?

Comment 17

[ayman maat :maat]

Attachment: FFOS_MessageApp_V1.3_20131119_V7.0.pdf

**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

Comment 18

[José Vittone]

Attachment: SMS_MMS_message_settings.png

Comment 19

[José Vittone]

Attachment: SMS_MMS_messageReport.png

Comment 20

[José Vittone]

Attachment: required_assets.zip

Comment 21

[José Vittone]

Attachment: SMS.MMS.Message_report [SPEC]

Hi everyone, 

Visual design related to Message Reports is ready. Please, ask me if you have any question.

Comment 22

[Paul Yang [:pyang] (away)]

Take this bug and start to create test cases

Comment 23

[ayman maat :maat]

Attachment: FFOS_MessageApp_V1.3_20131125_V8.0.pdf

**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

Comment 24

[Julien Wajsberg [:julienw]]

I think this bug should be moved to 1.4 too, is it ok Joe?

Comment 25

[Joe Cheng [:jcheng] (please needinfo)]

team decided to move this to 1.4

Comment 26

[José Vittone]

Attachment: SMS_MMS_reports no subject

Comment 27

[José Vittone]

Attachment: SMS_MMS_reports not a contact

Comment 28

[José Vittone]

Attachment: SMS_reports

Comment 29

[José Vittone]

Attachment: SMS.MMS.Message_report [SPEC]

Comment 30

[Paul Yang [:pyang] (away)]

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?

Comment 31

[Paul Yang [:pyang] (away)]

in-moztrap+ since basic functionality covered.
https://moztrap.mozilla.org/manage/cases/?&pagenumber=1&pagesize=20&sortfield=created_on&sortdirection=desc&filter-tag=2364&filter-suite=497

Comment 32

[Julien Wajsberg [:julienw]]

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) ?

Comment 33

[Joe Cheng [:jcheng] (please needinfo)]

features should not block release, remove blocking flag

Comment 34

[Wilfred Mathanaraj [:WDM]]

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.

Comment 35

[Joe Cheng [:jcheng] (please needinfo)]

features should not block. remove blocking flag

Comment 36

[Kai-Chih Hu [:khu]]

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. :-)

Comment 37

[Julien Wajsberg [:julienw]]

From comment 34, the "per message basis" is the only thing missing if I'm not wrong.

Comment 38

[Bevis Tseng[:bevis][:btseng](Exited)]

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?

Comment 39

[Paul Yang [:pyang] (away)]

I believe we've discussed this item in last work week, and the decision should be merge into one switch.

Comment 40

[Joe Cheng [:jcheng] (please needinfo)]

Since this is high priority item, assign to steve as the remaining work required to finish this user story is all assigned to steve

Comment 41

[Wesley Huang [:wesley_huang] (EPM) (NI me)]

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.

Comment 42

[Wilfred Mathanaraj [:WDM]]

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?

Comment 43

[Bevis Tseng[:bevis][:btseng](Exited)]

NO, if per message configuration is not necessary for now, 
there is no gecko work required and we should remove bug 927716 from dependency.

Comment 44

[Wesley Huang [:wesley_huang] (EPM) (NI me)]

According to comment 42, I'm removing bug 927716 from dependency.

Comment 45

[Julien Wajsberg [:julienw]]

And since Bug 933133 is not necessary for the basic feature, I'm closing this feature bug as well, per comment 34.

yay!