Closed Bug 923443 Opened 11 years ago Closed 11 years ago

[User Story] Single variant: Pre-polulate some WiFi SSID by SIM

Categories

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

Product:
Firefox OS Graveyard
Component:
Gaia::System
Platform:
ARM
Gonk (Firefox OS)
Type:
defect

Tracking

(feature-b2g:2.0, tracking-b2g:backlog)

Status:
RESOLVED FIXED
Milestone:
1.4 S5 (11apr)
Project Flags:
feature-b2g 2.0
tracking-b2g backlog

People

(Reporter: sonmarce, Assigned: macajc)

References

Details

(Keywords: feature, Whiteboard: [systemsfe][ucid:System12, systemsfe][p=5][leave open])

User Story

As an Operator I want to have a number of predefined stored WiFi SSID per country, so that users can connect to them automatically

Acceptance criteria:
* WiFi SSID will be configured per each MCC/MNC after inserting a new SIM card and entering PIN code for the first time
* All required parameters will be stored depending on the kind of WiFi SSID
* In case there are already some WiFi SSID previously configured by the user, they will be preserved, just adding the new ones
* Replacing or removing SIM card later on will imply no change in WiFi SSID configuration
* After a factory reset, WiFi SSID configuration will follow same process as a brand new device

Attachments

(1 file, 3 obsolete files)

Proposed patch, v3
(deleted), patch
vchang
: review+
Details | Diff | Splinter Review
As an Operator I want to have a number of predefined stored WiFi SSID per country, so that users can connect to them automatically Acceptance criteria: * WiFi SSID will be configured per each MCC/MNC after inserting a new SIM card * To complete connection, user will follow currently available process: authentication by password, captive portal, ...
Blocks: 1.3-systems-fe
Keywords: feature
Whiteboard: [systemsfe]
Priority: -- → P1
Whiteboard: [systemsfe] → [ucid:System12, systemsfe]
QA Contact: rafael.marquez
No longer blocks: 1.3-systems-fe
Target Milestone: --- → 1.3 C2/1.4 S2(17jan)
Whiteboard: [ucid:System12, systemsfe] → [systemsfe][ucid:System12, systemsfe]
Assignee: nobody → cjc
We have updated acceptance criteria to be as follows: * WiFi SSID will be configured per each MCC/MNC after inserting a new SIM card and entering PIN code for the first time * All required parameters will be stored depending on the kind of WiFi SSID * In case there are already some WiFi SSID previously configured by the user, they will be preserved, just adding the new ones * Replacing or removing SIM card later on will imply no change in WiFi SSID configuration * After a factory reset, WiFi SSID configuration will follow same process as a brand new device Also starting to use the new User Story field in Bugzilla.
User Story: (updated)
Target Milestone: 1.3 C2/1.4 S2(17jan) → 1.3 C3/1.4 S3(31jan)
blocking-b2g: --- → backlog
Attached patch Proposed patch - v1 (obsolete) (deleted) — — Splinter Review
The user history requires Pre-populating some WiFi SSID (and the set of SSIDs to prepopulate depend on the inserted SIM) when the phone is powered up for first time (and posiblemente said wifi networks aren't visible at the phone actual location). So we need the ability to associate a Wifi without trying to connect to it. The objective of this patch is allow to do it.
Attachment #8370600 - Flags: review?(vchang)
Attached file Proposed patch v1 - gaia (obsolete) (deleted) —
Attachment #8370602 - Flags: review?(francisco.jordano)
Target Milestone: 1.3 C3/1.4 S3(31jan) → 1.4 S1 (14feb)
Comment on attachment 8370602 [details] Proposed patch v1 - gaia Left some comments on github, non blocking, mainly style. Thanks Carmen!
Attachment #8370602 - Flags: review?(francisco.jordano) → review+
Flags: in-moztrap?(rafael.marquez)
Whiteboard: [systemsfe][ucid:System12, systemsfe] → [systemsfe][ucid:System12, systemsfe][p=5]
Comment on attachment 8370600 [details] [diff] [review] Proposed patch - v1 Review of attachment 8370600 [details] [diff] [review]: ----------------------------------------------------------------- ::: dom/wifi/WifiWorker.js @@ +2640,5 @@ > + let privnet = network; > + let dontConnect = privnet.dontConnect; > + delete privnet.dontConnect; > + > + if (!WifiManager.enabled && !dontConnect) { Why should we check dontConnect here ? @@ +2650,5 @@ > function networkReady() { > // saveConfig now before we disable most of the other networks. > function selectAndConnect() { > + if (dontConnect) { > + self._sendMessage(message, true, "Wifi has been recorded", msg); Can we check this flag out of selectAndConnect() function ? It makes more sense for the function name.
Attachment #8370600 - Flags: review?(vchang)
Attached patch bug923443_v2.patch (obsolete) (deleted) — — Splinter Review
This version includes the previous review comments
Attachment #8373439 - Flags: review?(vchang)
Comment on attachment 8373439 [details] [diff] [review] bug923443_v2.patch Review of attachment 8373439 [details] [diff] [review]: ----------------------------------------------------------------- ::: dom/wifi/WifiWorker.js @@ +2664,5 @@ > }); > } > > if (self._highestPriority >= MAX_PRIORITY) > self._reprioritizeNetworks(selectAndConnect); Do we also need to check dontConnect flag here ? The other question is do these default APs have lowest priority than APs chose by user ?
Attached patch Proposed patch, v3 (deleted) — — Splinter Review
You're right, when I took the condition check out of selectAndConnect I forgot about the other case. Fixed that. As for the priority, currently they're just added with the default priority. I don't think that's actually part of the user story. In any case, I don't think that on a normal use one of the default networks will collide with a user defined one (since mostly the default networks will correspond to operator provided public access points).
Attachment #8370600 - Attachment is obsolete: true
Attachment #8373439 - Attachment is obsolete: true
Attachment #8373439 - Flags: review?(vchang)
Attachment #8376546 - Flags: review?(vchang)
Comment on attachment 8376546 [details] [diff] [review] Proposed patch, v3 Review of attachment 8376546 [details] [diff] [review]: ----------------------------------------------------------------- Looks good, thank you.
Attachment #8376546 - Flags: review?(vchang) → review+
The try run looks good, requesting checkin. Please do not land the Gaia patch until the Gecko patch has landed.
Keywords: checkin-needed
https://hg.mozilla.org/integration/b2g-inbound/rev/5ba2e35f4d48 Just put checkin-needed back on this bug when you're ready for the Gaia PR to merge. :)
Keywords: checkin-needed
Whiteboard: [systemsfe][ucid:System12, systemsfe][p=5] → [systemsfe][ucid:System12, systemsfe][p=5][leave open]
Target Milestone: 1.4 S1 (14feb) → 1.4 S2 (28feb)
Blocks: 976008
Target Milestone: 1.4 S2 (28feb) → 1.4 S3 (14mar)
Is this 1.5 now?
Since we're moving all the Single Variant customizations into a stand alone app, I think it's better to just not land the Gaia part (and close this bug as it is). If you think different, I can fix the conflicts and merge the Gaia patch. Please, see bugs 978785 and 980301.
Please, see bug 978785 and bug 980301.
Blocks: 2.0-systems-fe
No longer blocks: 1.4-systems-fe
moving to next sprint since this won't land till after 3/17 FC
Target Milestone: 1.4 S3 (14mar) → 1.4 S4 (28mar)
Status: NEW → RESOLVED
Closed: 11 years ago
Depends on: 978785
Resolution: --- → FIXED
Attachment #8370602 - Attachment is obsolete: true
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Closed by mistake, still a dependent bug pending to be finished
Depends on: 986446
Target Milestone: 1.4 S4 (28mar) → 1.4 S5 (11apr)
Implementation completed in bug 978785
Status: REOPENED → RESOLVED
Closed: 11 years ago → 11 years ago
Resolution: --- → FIXED
feature-b2g: --- → 2.0
blocking-b2g: backlog → ---
tracking-b2g: --- → backlog
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: