Closed Bug 891724 Opened 7 years ago Closed 6 years ago

[User Story] Support Contacts Runtime Customization by SIM

Categories

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

ARM
Gonk (Firefox OS)
defect
Not set

Tracking

(blocking-b2g:koi+, b2g-v1.2 fixed)

VERIFIED FIXED
blocking-b2g koi+
Tracking Status
b2g-v1.2 --- fixed

People

(Reporter: pdol, Assigned: aus)

References

Details

(Keywords: feature, Whiteboard: [ucid:System21, FT:systems-fe, KOI:P1][systemsfe])

Attachments

(1 file, 2 obsolete files)

User Story:

As an OEM, I want to be able to specify which support contacts (under Settings>Help) should be used on the device based on the MNC/MCC setting from the SIM card inserted during the First Run Experience in order to target customizations to locales without needing to use separate builds. 


Acceptance Criteria:

1. If a certain support contacts are specified to be included for an MNC/MCC combination, and a SIM card with that MNC/MCC combination is in the device during the First Run Experience, the support contacts (under Settings>Help) display the specified contacts.
2. If no SIM card is inserted during the First Run Experience, the specified default support contacts are displayed under Settings>Help.
3. If no SIM card is inserted during the First Run Experience, and no default support contacts are specified, no support contacts are displayed under Settings>Help.
After further partner discussion, the scenario where no SIM is used during First Run, but inserted after the fact needs to be considered:

As an OEM, I want to be able to specify which support contacts (under Settings>Help) should be used on the device based on the MNC/MCC setting from the SIM card inserted during the First Run Experience or when the SIM card is inserted for the first time in order to target customizations to locales without needing to use separate builds. 

Also, one additional acceptance criteria:
4. If no SIM card is inserted during the First Run Experience, the first time a SIM card is inserted, the support contacts, as per acceptance criteria 1, are now shown on the Settings>Help screen.
Whiteboard: [ucid:System21] → [ucid:System21, FT:systems-fe, KOI:P1]
koi+ per https://wiki.mozilla.org/B2G/Roadmap
blocking-b2g: --- → koi+
Flags: in-moztrap?(atsai)
QA Contact: atsai
Hi Peter, could you help to clarify that will the support contact changes if there's SIM card changes?

STR:
1. Insert SIM card and boot to pass FTE
2. Check Settings->Help->Support Contact
3. Power off and change a SIM card w/ different MNC/MCC which also support by the built-in MNC/MCC combination
4. Power on DuT
5. After booting, check Settings->Help->Support Contact

Expect Result:
2. Target Support Contact for the MNC/MCC is shown
5. "Support Contact for the original one" or "Support Contact for the new one" ←???
Flags: needinfo?(pdolanjski)
Sorry for the flip flopping on the expectations here.
After much back and forth:
To simplify things for the Koi release, we are only considering the SIM being entered on First Run.

So, Al, in your scenario, the original support contact would be shown.
Flags: needinfo?(pdolanjski)
Thanks for clarification. I'll start to work on test case development now.
MozTrap #9559, #9560, #9561, #9562, #9563
Flags: in-moztrap?(atsai) → in-moztrap+
Assignee: nobody → mri
Ghislain 'Aus' Lacroix changed story state to started in Pivotal Tracker
Whiteboard: [ucid:System21, FT:systems-fe, KOI:P1] → [ucid:System21, FT:systems-fe, KOI:P1][systemsfe]
Assignee: mri → nobody
So
Assignee: nobody → kyle
Right now, support contacts are taken from a json file embedded in the systems app. We can't rewrite the file in the app on FTU/SIM change, so this probably needs to be turned into a setting of some type. However, should we completely remove the file, or just fall back to it if no setting is present?
Flags: needinfo?(pdolanjski)
This is a "I haven't even run it yet" WIP for support contacts, just to lay down the basic idea of "Settings first, then file". Want to make sure this is sane before continuing.
Attachment #806215 - Flags: feedback?(aus)
Comment on attachment 806215 [details]
Patch 1 (v1) - WIP: Support Contacts Customization based on variant

This looks good to me. Fall back to file is my preferred approach (and gwagner's). 

Do we have to have empty values in settings.js? It might be confusing to see those empty values there. One will probably assume they can replace the defaults by editing that file only to find out they overrode what was the default in the json file.
Attachment #806215 - Flags: feedback?(aus) → feedback+
Here's the 411:

* No possible sane defaults in settings.js => We have no support contact to direct people to other than their carrier. The carrier is responsible for the first line of support. We just tell the user to contact their carrier if none is specified.
* The global default is in a JSON file that's specifically for support contacts and is part of the build. It is not writable at runtime. It is the carrier's / partner responsibility to update this file when they make their build.
* The customization json file is where one would add their runtime overrides to the support contacts. This file also takes care of wallpaper and ringtones by SIM MCC/MNC.

This all sounds good to me! It preserves the current flow that carriers/partners follow while enabling the extra functionality requested.
(In reply to Kyle Machulis [:kmachulis] [:qdot] from comment #9)
> Right now, support contacts are taken from a json file embedded in the
> systems app. We can't rewrite the file in the app on FTU/SIM change, so this
> probably needs to be turned into a setting of some type. However, should we
> completely remove the file, or just fall back to it if no setting is present?

Comment 12 sounds reasonable to me.  As long as a default and locale specific contacts can be specified, such that the default is used when there is no SIM or if no specifics exist for a given locale, then that should be sufficient.
Flags: needinfo?(pdolanjski)
Assignee: kyle → aus
NOTE: Please see https://wiki.mozilla.org/Release_Management/B2G_Landing to better understand the B2G approval process and landings.

[Approval Request Comment]
[Bug caused by] (feature/regressing bug #):
[User impact] if declined:
[Testing completed]:
[Risk to taking this patch] (and alternatives if risky):
[String changes made]:
Attachment #807522 - Flags: review?(kyle)
Attachment #807522 - Flags: approval-gaia-v1.2?(anygregor)
Attachment #806215 - Attachment is obsolete: true
Attachment #807522 - Attachment mime type: text/plain → text/html
Note - koi+ bugs don't need approval to land.
Attachment #807522 - Flags: review?(kyle)
Attachment #807522 - Flags: review+
Attachment #807522 - Flags: approval-gaia-v1.2?(anygregor)
Fixed!

Master: https://github.com/mozilla-b2g/gaia/commit/dce497b5cf19183f51a867334dd0524c816493dc
v1.2: https://github.com/mozilla-b2g/gaia/commit/dce497b5cf19183f51a867334dd0524c816493dc

bug 918592 for minor follow up work already filed.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Ghislain 'Aus' Lacroix changed story state to finished in Pivotal Tracker
Ghislain 'Aus' Lacroix changed story state to accepted in Pivotal Tracker
Ghislain 'Aus' Lacroix changed story state to accepted in Pivotal Tracker
Keywords: verifyme
Reopening. Had to back it out and update some unit-tests. Going to reland shortly.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Attachment #807522 - Attachment is obsolete: true
Attachment #807562 - Flags: review?(kyle)
Attachment #807562 - Attachment mime type: text/plain → text/html
Attachment #807562 - Flags: review?(kyle) → review+
https://github.com/mozilla-b2g/gaia/commit/bc00bf37715b7afb0a0c1d9c1b90092fd74ebc49
Status: REOPENED → RESOLVED
Closed: 6 years ago6 years ago
Resolution: --- → FIXED
Hi Kyle,
We are changing the structure of the customization file here:
https://bugzilla.mozilla.org/show_bug.cgi?id=917740

Changes agreed here:
https://bugzilla.mozilla.org/show_bug.cgi?id=917740#c0

I've added to you a needinfo here:
https://bugzilla.mozilla.org/show_bug.cgi?id=891730#c9

After talking with Reuben and Albert, we agree that instead of having a file per MNC/MCC, we are going to create a file which contain one entry per MNC/MCC of the carrier, and inside we are going to have URI to the resources needed (wallpaper, ringtone...).
In this case, we should have a 'supportsetting.json' file, where all this info will be, and point this URI from 'customization.json'. Im gonna add this modifications in the bug 917740 (Koi+), where we are working together for changing this structure, so we ask you to review this part of the code. Thanks!
Uplifted bc00bf37715b7afb0a0c1d9c1b90092fd74ebc49 to:
v1.2: 0f1f3ca57a6ede31e3888930699a80108c186146
Aus - I'm trying to figure out how to update sample reference customization to align with the changes made here. Can you provide a sample support.json demonstrating how support contacts would be customized?
Flags: needinfo?(aus)
Reuben clarified this in IRC. He says I need to generate a file with <MCC>-<MNC>.json that points to other relevant files. Something like:

214-02.json which contains:

{
   "support_contacts" : "support_contacts.json"
}

That should result in preloading support contacts for the MCC = 214, MNC = 02 SIM.
Flags: needinfo?(aus)
(In reply to Jason Smith [:jsmith] from comment #26)
> Reuben clarified this in IRC. He says I need to generate a file with
> <MCC>-<MNC>.json that points to other relevant files. Something like:
> 
> 214-02.json which contains:
> 
> {
>    "support_contacts" : "support_contacts.json"
> }
> 

Is this because of 917740? Because that's not how they work currently.

> That should result in preloading support contacts for the MCC = 214, MNC =
> 02 SIM.

Not exactly, unless that's changing.

Here's what the JSON data looks like for support_contacts, it can be inserted into the same MCC-MNC.json file as other customizations (like wallpaper, contacts, ringtones).

{
  "supportcontacts": {
    "onlinesupport": {
      "title": "Mozilla Support",
      "href": "http://test.mozilla.org/support"
    },
    "callsupport1": {
      "title": "Call Support (Primary)",
      "href": "tel:14155550001"
    },
    "callsupport2": {
      "title": "Call Support (Secondary)",
      "href": "tel:14155550002"
    }
  }
}

This would define all available support contacts (online, direct call info 1 and direct call info 2).
Depends on: 918592
(In reply to Ghislain 'Aus' Lacroix from comment #27)
> (In reply to Jason Smith [:jsmith] from comment #26)
> > Reuben clarified this in IRC. He says I need to generate a file with
> > <MCC>-<MNC>.json that points to other relevant files. Something like:
> > 
> > 214-02.json which contains:
> > 
> > {
> >    "support_contacts" : "support_contacts.json"
> > }
> > 
> 
> Is this because of 917740? Because that's not how they work currently.
> 
> > That should result in preloading support contacts for the MCC = 214, MNC =
> > 02 SIM.
> 
> Not exactly, unless that's changing.
> 
> Here's what the JSON data looks like for support_contacts, it can be
> inserted into the same MCC-MNC.json file as other customizations (like
> wallpaper, contacts, ringtones).
> 
> {
>   "supportcontacts": {
>     "onlinesupport": {
>       "title": "Mozilla Support",
>       "href": "http://test.mozilla.org/support"
>     },
>     "callsupport1": {
>       "title": "Call Support (Primary)",
>       "href": "tel:14155550001"
>     },
>     "callsupport2": {
>       "title": "Call Support (Secondary)",
>       "href": "tel:14155550002"
>     }
>   }
> }
> 
> This would define all available support contacts (online, direct call info 1
> and direct call info 2).

Trying to configure support_contacts I get an error if the json format is:

{
  "supportcontacts": {
    "onlinesupport": {
      "title": "Mozilla Support",
      "href": "http://test.mozilla.org/support"
    },
    "callsupport1": {
      "title": "Call Support (Primary)",
      "href": "tel:14155550001"
    },
    "callsupport2": {
      "title": "Call Support (Secondary)",
      "href": "tel:14155550002"
    }
  }
}

It works removing supportcontacts:

{
  "onlinesupport": {
    "title": "Mozilla Support",
    "href": "http://test.mozilla.org/support"
  },
  "callsupport1": {
    "title": "Call Support (Primary)",
    "href": "tel:14155550001"
  },
  "callsupport2": {
    "title": "Call Support (Secondary)",
    "href": "tel:14155550002"
  }
}

Which is the correct format?
Flags: needinfo?(aus)
Depends on: 923653
(In reply to Albert [:albert] from comment #28)
> (In reply to Ghislain 'Aus' Lacroix from comment #27)
> > (In reply to Jason Smith [:jsmith] from comment #26)
> > > Reuben clarified this in IRC. He says I need to generate a file with
> > > <MCC>-<MNC>.json that points to other relevant files. Something like:
> > > 
> > > 214-02.json which contains:
> > > 
> > > {
> > >    "support_contacts" : "support_contacts.json"
> > > }
> > > 
> > 
> > Is this because of 917740? Because that's not how they work currently.
> > 
> > > That should result in preloading support contacts for the MCC = 214, MNC =
> > > 02 SIM.
> > 
> > Not exactly, unless that's changing.
> > 
> > Here's what the JSON data looks like for support_contacts, it can be
> > inserted into the same MCC-MNC.json file as other customizations (like
> > wallpaper, contacts, ringtones).
> > 
> > {
> >   "supportcontacts": {
> >     "onlinesupport": {
> >       "title": "Mozilla Support",
> >       "href": "http://test.mozilla.org/support"
> >     },
> >     "callsupport1": {
> >       "title": "Call Support (Primary)",
> >       "href": "tel:14155550001"
> >     },
> >     "callsupport2": {
> >       "title": "Call Support (Secondary)",
> >       "href": "tel:14155550002"
> >     }
> >   }
> > }
> > 
> > This would define all available support contacts (online, direct call info 1
> > and direct call info 2).
> 
> Trying to configure support_contacts I get an error if the json format is:
> 
> {
>   "supportcontacts": {
>     "onlinesupport": {
>       "title": "Mozilla Support",
>       "href": "http://test.mozilla.org/support"
>     },
>     "callsupport1": {
>       "title": "Call Support (Primary)",
>       "href": "tel:14155550001"
>     },
>     "callsupport2": {
>       "title": "Call Support (Secondary)",
>       "href": "tel:14155550002"
>     }
>   }
> }
> 
> It works removing supportcontacts:
> 
> {
>   "onlinesupport": {
>     "title": "Mozilla Support",
>     "href": "http://test.mozilla.org/support"
>   },
>   "callsupport1": {
>     "title": "Call Support (Primary)",
>     "href": "tel:14155550001"
>   },
>   "callsupport2": {
>     "title": "Call Support (Secondary)",
>     "href": "tel:14155550002"
>   }
> }
> 
> Which is the correct format?

The second format is correct. The format changed as part of the work for bug 917740.
Flags: needinfo?(aus)
Depends on: 925520
Depends on: 914790
Tested through the basics on this - the dependencies highlight the immediate issues that were found. Marking verified to indicate sanity testing was done on this.
Status: RESOLVED → VERIFIED
Keywords: verifyme
Depends on: 927205
Depends on: 933997
You need to log in before you can comment on or make changes to this bug.