Closed Bug 796381 Opened 12 years ago Closed 12 years ago

About should expose the some hardware address of the device such as NIC, Bluetooth, IMEI, ICCID

Categories

(Firefox OS Graveyard :: Gaia::Settings, defect)

defect
Not set
normal

Tracking

(blocking-basecamp:-, b2g18+ verified)

VERIFIED FIXED
blocking-basecamp -
Tracking Status
b2g18 + verified

People

(Reporter: ghtobz, Assigned: kaze)

References

Details

(Keywords: late-l10n, Whiteboard: [label:settings][label:UX][label:needsGeckoSupport][label:needsUXinput])

Attachments

(1 file)

[GitHub issue by nhirata on 2012-07-10T20:40:09Z, https://github.com/mozilla-b2g/gaia/issues/2301] ## Environment * Otoro phone, build 2012-07-10 * Gaia commit: d0fc2f0cdbec7bd94d6bd3fd782803b8787f8040 ## Repro 1. go to settings -> about ## Expected: * NIC address ## Actual: * NIC address is not listed. ## Note: 1.User Story: Having this would help make it easier to secure this phone as an allowed user on a home router
[GitHub comment by lco on 2012-07-11T21:37:38Z] See pg. 6 of my spec for where info like this should go: http://people.mozilla.com/~lco/Settings_B2G/Release_1_Specs/R1_Device_v1.pdf Since I didn't know what device info we'd like to include here, I just made it flexible to accommodate whatever text. See pg. 5 of the spec also for context on where this info should live.
[GitHub comment by autonome on 2012-08-09T04:39:30Z] This doesn't seem like a blocker, but a nice-to-have. Kaze, feel free to distribute to others helping on Settings.
[GitHub comment by autonome on 2012-08-09T04:40:00Z] @lco that URL is 404. do you have an updated link?
[GitHub comment by nhirata on 2012-08-09T04:44:15Z] Maybe she meant : http://people.mozilla.com/~lco/Settings_B2G/Release_1_Specs/R1_Device_v2.pdf ?
[GitHub comment by lco on 2012-09-28T18:21:38Z] And now it's been updated to : http://people.mozilla.com/~lco/Settings_B2G/Release_1_Specs/R1_Device_v3.pdf
The MAC Address is displayed in the “Device Information → more…” section and in the “Wi-Fi → Manage Networks” one. We probably could add the IP address in the latter section. Larissa, is the current implementation OK? Should we add the IP address and/or anything else?
Flags: needinfo?(lco)
> Larissa, is the current implementation OK? Should we add the IP address > and/or anything else? The MAC address is probably the most important one on that list, so I think the current implementation is ok. I don't know if it's worth it to add IP address or the rest of that info right now. Let's ask Clee.
Flags: needinfo?(lco)
Chris, can you let us know whether the MAC address is adequate for v1 in the device information > more information area?
Flags: needinfo?(clee)
Component: Gaia → Gaia::Settings
+1 for showing the IMEI in the Device Information screen.
Fabien, is it very straightforward to add the IP and/or IMEI? IMEI is often used for operator provisioning or during support calls.
Flags: needinfo?(clee) → needinfo?(kaze)
Peter, I think that: • the IP is already exposed by the mozWifiManager • the IMEI can be retrieved with a mozMobileConnection.sendMMI() request [1] • ICCID (and the device phone number, msisdn) are exposed by mozMobileConnection.iccInfo [2] FWIW, as a user I mostly miss the device phone number and I don’t care much of the IP. Larissa, would you submit wireframes to display these informations in the Settings app? [1] http://mxr.mozilla.org/mozilla-central/source/dom/network/interfaces/nsIDOMMobileConnection.idl#214 [2] http://mxr.mozilla.org/mozilla-central/source/dom/system/gonk/RILContentHelper.js#115
Flags: needinfo?(kaze)
Unless the effort is significant, I'd like to see the MAC and IMEI and phone number. Larissa, does this make sense to you? MAC for network whitelisting IMEI for support/remote provisioning Phone number in case the user forgets (unless there is another way to see this?)
Flags: needinfo?(lco)
Again, the MAC address is already visible in Device Information > More Information.
(In reply to Fabien Cazenave [:kaze] from comment #13) > Again, the MAC address is already visible in Device Information > More > Information. Thanks Fabien for the confirmation. The proposal is to also add IMEI/phone number (assuming lco agrees).
Just ran into this while activating a new SIM in my test device -- since IMEI isn't shown in Settings/Hardware info I had to turn the phone back off to look for the stickers under the battery. Would be nice to have IMEI listed in software. :)
How is this not a blocking+ bug, based on the popular requests?
blocking-basecamp: --- → ?
Triage: BB+, P3, C3 - our OEM partner is also asking for this. Please renom for BB- if the risk is high.
blocking-basecamp: ? → +
Priority: -- → P3
Target Milestone: --- → B2G C3 (12dec-1jan)
"Popular requests" does not seems enough to block on this one. Let's find another argument :)
blocking-basecamp: + → ?
Depends on: 824779
Attached file patch proposal (deleted) —
Sorry, my patch was almost ready when this bug lost its BB+ label… I couldn’t display the IMEI in this patch, see bug 824779, but the ICCID and the phone number work.
Attachment #695802 - Flags: review?(ehung)
I just fixed the IMEI part and updated the pull request, everything should now work as expected. As I don’t have any UX wireframes I’ve put the three items under the “Last Update” one and called them “IMEI”, “ICCID” and “Phone number” respectively. Josh, if you have a better suggestion (e.g. a dedicated section in the “More information…” panel), let me know.
Flags: needinfo?(jcarpenter)
Thanks Kaze. I suggest the following: * Make Phone Number the first entry of "Device Information" page. * Put IMEI and ICCID under "More Information" subsection.
Flags: needinfo?(jcarpenter)
Thanks for the quick response Josh, I’ve just updated the pull request accordingly.
Flags: needinfo?(lco)
Comment on attachment 695802 [details] patch proposal r=me, evelyn asked me to review this.
Attachment #695802 - Flags: review?(ehung) → review+
Keywords: late-l10n
blocking-basecamp: ? → +
If there is no legal requirement, no user impact I realy don't see why this is a blocker. It is a nice to have and not having the blocking flag does not means this patch won't land so please explain clearly why the phone can't be shipped without this.
blocking-basecamp: + → ?
Triage: BB-, tracking-b2g18+, but please set approval-gaia-master? to land
blocking-basecamp: ? → -
tracking-b2g18: --- → +
Priority: P3 → --
Target Milestone: B2G C3 (12dec-1jan) → ---
Comment on attachment 695802 [details] patch proposal NOTE: If blocking-basecamp+ is set, just land it for now. [Approval Request Comment] Bug caused by (feature/regressing bug #): ? User impact if declined: missing information in the Settings Testing completed: manual Risk to taking this patch (and alternatives if risky): low
Attachment #695802 - Flags: approval-gaia-master?(21)
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Argh! wrong bug!
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Status: REOPENED → RESOLVED
Closed: 12 years ago12 years ago
Resolution: --- → FIXED
Verified fixed in 2013-01-31-07-02-01 pvt nightly b2g18 build
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: