Closed
Bug 947161
Opened 11 years ago
Closed 11 years ago
[DSDS][Message] Message Report shows received SIM information
Categories
(Firefox OS Graveyard :: Gaia::SMS, defect, P1)
Tracking
(Not tracked)
VERIFIED
FIXED
1.4 S3 (14mar)
People
(Reporter: wmathanaraj, Assigned: steveck)
References
Details
(Whiteboard: [ucid:, 1.4, ft:comms])
As a user I want to know which SIM, phone number the message was received on in the message report
Acceptance Criteria
AC1: For SIM options I want to see SIM1 or SIM2
AC2: For phone number I want to see the phone number and if this can not be obtained I want to see "unknown"
Updated•11 years ago
|
Summary: [DSDS] Message Report shows received SIM information → [DSDS][Message] Message Report shows received SIM information
Updated•11 years ago
|
Blocks: b2g-dsds-1.4
Updated•11 years ago
|
Flags: in-moztrap?(pyang)
Comment 1•11 years ago
|
||
This will probably be done in bug 947142.
Comment 2•11 years ago
|
||
features should not block release, remove blocking flag
blocking-b2g: 1.4+ → ---
Updated•11 years ago
|
Whiteboard: [ucid:, 1.4, ft:comms]
Updated•11 years ago
|
Assignee: nobody → schung
Target Milestone: --- → 1.4 S2 (28feb)
Updated•11 years ago
|
Target Milestone: 1.4 S2 (28feb) → 1.4 S3 (14mar)
Assignee | ||
Comment 3•11 years ago
|
||
Although I landed the SIM information patch in bug 947142 and this one could be closed, I still want to clarify some UX behavior missed in bug 947142 before closing this one. Hi Ayman, Wilfred said we should display 'unknown' when the phone number is unavailable. The sad news is we could not guarentee phone number could be accessible on every SIM card(we fail to access phone number quite often actually). Do you think we should display 'unknown' for the unavailable SIM information, or just discard the field(SIM 1 , carrier, unknown - > SIM 1 , carrier)?
Flags: needinfo?(aymanmaat)
Comment 4•11 years ago
|
||
(In reply to Steve Chung [:steveck] from comment #3)
> Although I landed the SIM information patch in bug 947142 and this one could
> be closed, I still want to clarify some UX behavior missed in bug 947142
> before closing this one. Hi Ayman, Wilfred said we should display 'unknown'
> when the phone number is unavailable. The sad news is we could not guarentee
> phone number could be accessible on every SIM card(we fail to access phone
> number quite often actually). Do you think we should display 'unknown' for
> the unavailable SIM information, or just discard the field(SIM 1 , carrier,
> unknown - > SIM 1 , carrier)?
Hey Steve. you can just discard it. The rational behind this is that if the phone number is unavailable as far as i am aware it will always be unavailable ...which means that outputting 'unknown' just creates noise on the interface.
Flags: needinfo?(aymanmaat)
Comment 5•11 years ago
|
||
Updated•11 years ago
|
Flags: in-moztrap?(pyang) → in-moztrap+
Assignee | ||
Comment 6•11 years ago
|
||
(In reply to ayman maat :maat from comment #4)
> (In reply to Steve Chung [:steveck] from comment #3)
> > Although I landed the SIM information patch in bug 947142 and this one could
> > be closed, I still want to clarify some UX behavior missed in bug 947142
> > before closing this one. Hi Ayman, Wilfred said we should display 'unknown'
> > when the phone number is unavailable. The sad news is we could not guarentee
> > phone number could be accessible on every SIM card(we fail to access phone
> > number quite often actually). Do you think we should display 'unknown' for
> > the unavailable SIM information, or just discard the field(SIM 1 , carrier,
> > unknown - > SIM 1 , carrier)?
>
> Hey Steve. you can just discard it. The rational behind this is that if the
> phone number is unavailable as far as i am aware it will always be
> unavailable ...which means that outputting 'unknown' just creates noise on
> the interface.
Thanks! I think we can close this one for now.
Status: NEW → RESOLVED
Closed: 11 years ago
Flags: in-moztrap+ → in-moztrap?
Resolution: --- → FIXED
See Also: → 947142
Assignee | ||
Updated•11 years ago
|
Flags: in-moztrap? → in-moztrap+
You need to log in
before you can comment on or make changes to this bug.
Description
•