Closed
Bug 919977
Opened 12 years ago
Closed 11 years ago
[User Story][Messages] Support delivery reports
Categories
(Firefox OS Graveyard :: Gaia::SMS, defect, P1)
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.
Updated•12 years ago
|
Flags: in-moztrap?(jhammink)
Reporter | ||
Updated•12 years ago
|
Summary: [User Story] Support delivery reports for SMS/MMS → [User Story] Support delivery reports for SMS/MMS (FFOS 1.3)
Updated•12 years ago
|
Summary: [User Story] Support delivery reports for SMS/MMS (FFOS 1.3) → [Messages] Support delivery reports (FFOS 1.3)
Comment 1•12 years ago
|
||
Probably a dup of #899025?
Reporter | ||
Updated•12 years ago
|
Whiteboard: 919995
Comment 2•12 years ago
|
||
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
Updated•11 years ago
|
Summary: [Messages] Support delivery reports (FFOS 1.3) → [User Story][Messages] Support delivery reports (FFOS 1.3)
Updated•11 years ago
|
Whiteboard: [ucid:Comms28, 1.3:p1]
Assignee | ||
Comment 4•11 years ago
|
||
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.
Reporter | ||
Comment 5•11 years ago
|
||
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)
Comment 6•11 years ago
|
||
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•11 years ago
|
||
(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•11 years ago
|
||
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)
Reporter | ||
Comment 9•11 years ago
|
||
The same would apply here as in bug 919974
Flags: needinfo?(wmathanaraj)
![]() |
||
Comment 10•11 years ago
|
||
Steal the in-moztrap? flag and start to analysis the user story
Flags: in-moztrap?(jhammink) → in-moztrap?(atsai)
![]() |
||
Comment 11•11 years ago
|
||
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)
Updated•11 years ago
|
blocking-b2g: --- → 1.3+
Comment 12•11 years ago
|
||
**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
Updated•11 years ago
|
Assignee: nobody → evelyn
Reporter | ||
Comment 13•11 years ago
|
||
for concatenated SMS user gets one notification when the full SMS has been received and displayed to the user.
Flags: needinfo?(wmathanaraj)
Assignee | ||
Comment 14•11 years ago
|
||
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
Updated•11 years ago
|
Priority: -- → P1
Updated•11 years ago
|
Target Milestone: --- → 1.3 Sprint 5 - 11/22
Comment 15•11 years ago
|
||
Joe, this should be changed to sprint 6 because the target milestone for bug 933133 is sprint 6, right?
Flags: needinfo?(jcheng)
Updated•11 years ago
|
Whiteboard: [ucid:Comms28, 1.3:p1] → [ucid:Comms28, 1.3:p1, ft:comms]
Comment 17•11 years ago
|
||
**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
Updated•11 years ago
|
Flags: needinfo?(jcheng)
Target Milestone: 1.3 Sprint 5 - 11/22 → 1.3 Sprint 6 - 12/6
Comment 18•11 years ago
|
||
Comment 19•11 years ago
|
||
Comment 20•11 years ago
|
||
Comment 21•11 years ago
|
||
Hi everyone,
Visual design related to Message Reports is ready. Please, ask me if you have any question.
Comment 22•11 years ago
|
||
Take this bug and start to create test cases
Flags: in-moztrap?(atsai) → in-moztrap?(pyang)
Comment 23•11 years ago
|
||
**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
Comment 24•11 years ago
|
||
I think this bug should be moved to 1.4 too, is it ok Joe?
blocking-b2g: 1.3+ → 1.4?
Flags: needinfo?(jcheng)
Updated•11 years ago
|
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]
Comment 25•11 years ago
|
||
team decided to move this to 1.4
Target Milestone: 1.3 Sprint 6 - 12/6 → ---
Updated•11 years ago
|
No longer blocks: comms_1.3_committed, 937014
Comment 26•11 years ago
|
||
Comment 27•11 years ago
|
||
Comment 28•11 years ago
|
||
Comment 29•11 years ago
|
||
Attachment #8336257 -
Attachment is obsolete: true
Reporter | ||
Updated•11 years ago
|
Blocks: 1.4-comms-committed
Comment 30•11 years ago
|
||
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?
Blocks: b2g--telephony-1.4
Updated•11 years ago
|
Flags: sec-review?
![]() |
||
Updated•11 years ago
|
Flags: sec-review? → sec-review?(ptheriault)
Comment 31•11 years ago
|
||
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
Flags: in-moztrap?(pyang) → in-moztrap+
Updated•11 years ago
|
Flags: sec-review?(ptheriault) → sec-review?(stephouillon)
Updated•11 years ago
|
blocking-b2g: 1.4? → 1.4+
Comment 32•11 years ago
|
||
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)
Comment 33•11 years ago
|
||
features should not block release, remove blocking flag
blocking-b2g: 1.4+ → ---
Updated•11 years ago
|
Whiteboard: [ucid:Comms28, 1.4:? ft:comms] → [ucid:Comms28, 1.4, ft:comms]
Updated•11 years ago
|
Target Milestone: --- → 1.4 S2 (28feb)
Reporter | ||
Comment 34•11 years ago
|
||
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)
Updated•11 years ago
|
blocking-b2g: --- → 1.4+
Comment 36•11 years ago
|
||
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. :-)
Updated•11 years ago
|
No longer blocks: 1.4-comms-committed
Comment 37•11 years ago
|
||
From comment 34, the "per message basis" is the only thing missing if I'm not wrong.
Comment 38•11 years ago
|
||
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)
Comment 39•11 years ago
|
||
I believe we've discussed this item in last work week, and the decision should be merge into one switch.
Updated•11 years ago
|
Flags: needinfo?(wmathanaraj)
Comment 40•11 years ago
|
||
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
Comment 41•11 years ago
|
||
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)
Reporter | ||
Comment 42•11 years ago
|
||
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•11 years ago
|
||
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•11 years ago
|
||
According to comment 42, I'm removing bug 927716 from dependency.
No longer depends on: 927716
Comment 45•11 years ago
|
||
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: 11 years ago
Resolution: --- → FIXED
No longer blocks: b2g--telephony-1.4
Updated•11 years ago
|
Flags: sec-review?(stephouillon) → sec-review+
Updated•11 years ago
|
Flags: needinfo?(jcheng)
You need to log in
before you can comment on or make changes to this bug.
Description
•