833467 - [Help] Allow empty support info

Status: VERIFIED FIXED

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

Description

[Michelle Luna]

Hi,

This is another bug on the Settings > Help to make the contact details more generic so we can add Colombia and Venezuela details. 

Ideally, we need a way to provide support contact details with two factors; locale and operator. It could be the case that two different operators serve one locale. So, the use case is a person who puts in a chip from the other operator and they get the right support contact info in Settings > Help.

So, the first part of this request is to change the string 'Vivo' to 'Contact your operator' or something more generic if that string is too long. This is important for demos and trainings.

The second part is to add the following information for Colombia:

Phone -- *611

url -- http://www.movistar.co/Atencion_al_Cliente/

And add the following information for Venezuela:

Phone -- *811

url -- http://www.movistar.com.ve/particulares/ayuda/asistente/soy_cliente/asistente.asp

Comment 1

[Beatriz Rodríguez [:brg]]

This is important for certification and proper commercialization of the products.
If the device is not under the carrier distribution, there must be a list of "by default" contact details.
Only when the manufacturer has a signed agreement with the carrier, those contact details can be changed.
My suggestion is to have a default contact details and made them customizable by both operator/locale by manufacturer.
Please mark this as TEF +.

Comment 2

[Fabien Cazenave [:kaze]]

There’s no chance I can finish this before the end of the PST day. If that’s an issue, please reassign.

Comment 3

[Anthony Ricaud (:rik)]

A few questions before implementing this.

1 - Should the contact info update itself as you put or remove a SIM card?
2 - What should be the default contact info?

Comment 4

[Lukas Blakk [:lsblakk] use ?needinfo]

Marking status-b2g18 and status-b2g18-v1.0.0 as affected, please update the status to fixed once this is verified landed on v1-train and v1.0.0

Comment 5

[Michelle Luna]

Hi Anthony,

1. Yes, I think the contact info should update for the SIM card. 

2. I don't know what the default contact details should be as Beatriz suggested, adding needinfo? for Beatriz.

Thanks,
Michelle

Comment 6

[Beatriz Rodríguez [:brg]]

Sorry for my late response.
If the OEM and the OB had signed an agreement, then the OB or/and OEM could include their contact support, so this value should be customized by them.

However, if there is no agreement and the OEM will sell the device in the Open-worldwide market, maybe we can put just a sentence saying: "Please contact your local provider for support" and keep the link to the user manual(as it is right now). WDYT?

In latest version, the Vivo contacts are still there, IMHO we should remove them now that devices are around the world :-)

Comment 7

[Alex Keybl [:akeybl]]

Since this can be resolved as a customization, taking off the tef+ list.

Comment 8

[Beatriz Rodríguez [:brg]]

We need this issue to be changed asap. We are shipping products with Vivo contact details for support but the devices are not sold under Vivo channels.

Nominating for TEF+ again because we need a change in this settings asap.
Thanks.

Comment 9

[Anthony Ricaud (:rik)]

Changing the bug title to reflect the exact work that's happening here.

Comment 10

[Anthony Ricaud (:rik)]

Attachment: Pointer to https://github.com/mozilla-b2g/gaia/pull/8042

Comment 11

[Ben Francis [:benfrancis]]

Comment on attachment 712402 [details] [review]
Pointer to https://github.com/mozilla-b2g/gaia/pull/8042

r+me on latest pull request, but I think this needs localisation review for late l10n?

Comment 12

[Anthony Ricaud (:rik)]

Attachment: Screenshot if empty support info

Michelle: To be clear, this will not implement the new contact info from comment 0. This needs to be done in other bugs on a per-partner basis.
This bug only allows us to run without support info. The default support info has also not been changed since all our customisation info is specific to one partner for now.

If someone builds with an empty support info, this screen will look like the attachment.

Comment 13

[Axel Hecht [:Pike]]

Comment on attachment 712402 [details] [review]
Pointer to https://github.com/mozilla-b2g/gaia/pull/8042

stealing reviews from stas, r=me.

Comment 14

[Anthony Ricaud (:rik)]

Leaving this open till we get tef+ again.

Comment 15

[John Ford [:jhford] CET/CEST Berlin Time]

This commit does not apply cleanly to v1-train, v1.0.0.  If this patch depends on another bug, please comment here and I will retry when that bug is approved to land on all branches that this bug needs to land on.  If the merge conflict needs to be resolved by hand, the following commands could be a useful starting point:

cd gaia
git checkout v1-train
git cherry-pick -x 0185ab8779a6e21bf9117b87f1c6e5c22541f3b3
<resolve merge conflict>
git checkout v1.0.0
git cherry-pick -x $(git log --pretty=%H -n1 v1-train)

Comment 16

[Lukas Blakk [:lsblakk] use ?needinfo]

Batch edit: Bugs still affected on b2g18 after 2/13 merge to v1.0.1 branch are affected on v1.0.1 branch.

Comment 17

[Lukas Blakk [:lsblakk] use ?needinfo]

This is still marked as affected on branches - can someone confirm the uplifts have been done so this tef+ bug is fixed on v1.0.1?

Comment 18

[David Tenser [:djst]]

(In reply to Anthony Ricaud (:rik) from comment #12)
> Created attachment 712428 [details]
> Screenshot if empty support info
> 
> Michelle: To be clear, this will not implement the new contact info from
> comment 0. This needs to be done in other bugs on a per-partner basis.
> This bug only allows us to run without support info. The default support
> info has also not been changed since all our customisation info is specific
> to one partner for now.
> 
> If someone builds with an empty support info, this screen will look like the
> attachment.

Is there any code freeze deadline that we need to be aware of for implementing partner-specific support contact info, or can that happen post code freeze? Since tThis bug removes all pointers to Support except the one hosted on support.mozilla.org, I want to be 100% sure we know of any time constraints for getting the Vivo (or similar) specific information back in before it's too late.

Thanks!

Comment 19

[Anthony Ricaud (:rik)]

(In reply to John Ford [:jhford] from comment #15)
> This commit does not apply cleanly to v1-train, v1.0.0.  If this patch
> depends on another bug, please comment here and I will retry when that bug
> is approved to land on all branches that this bug needs to land on.  If the
> merge conflict needs to be resolved by hand, the following commands could be
> a useful starting point:
> 
> cd gaia
> git checkout v1-train
> git cherry-pick -x 0185ab8779a6e21bf9117b87f1c6e5c22541f3b3
> <resolve merge conflict>
> git checkout v1.0.0
> git cherry-pick -x $(git log --pretty=%H -n1 v1-train)
AFAICT, the only issue whit merging this is a EOL whitespace change in settings.css. I'm pretty sure you can tell git to ignore whitespace changes when resolving conflicts but I can't remember how right now.

Lukas: I can confirm it has not been uplifted yet.

Comment 20

[Anthony Ricaud (:rik)]

(In reply to David Tenser [:djst] from comment #18)
> Is there any code freeze deadline that we need to be aware of for
> implementing partner-specific support contact info, or can that happen post
> code freeze?
The support info lives in build/application-data.js. This file is currently very partner-specific (see [1]). So it's obvious that it needs to be adapted for each partner. I'm not sure who's responsible for that though.

> Since tThis bug removes all pointers to Support except the one
> hosted on support.mozilla.org,
Actually, it doesn't remove pointers at all (see [1] again). This patch only prepares the UI in case support info is empty.

[1] https://github.com/mozilla-b2g/gaia/blob/master/build/applications-data.js#L223

Comment 21

[John Ford [:jhford] CET/CEST Berlin Time]

(In reply to Anthony Ricaud (:rik) from comment #19)
> (In reply to John Ford [:jhford] from comment #15)
> > This commit does not apply cleanly to v1-train, v1.0.0.  If this patch
> > depends on another bug, please comment here and I will retry when that bug
> > is approved to land on all branches that this bug needs to land on.  If the
> > merge conflict needs to be resolved by hand, the following commands could be
> > a useful starting point:
> > 
> > cd gaia
> > git checkout v1-train
> > git cherry-pick -x 0185ab8779a6e21bf9117b87f1c6e5c22541f3b3
> > <resolve merge conflict>
> > git checkout v1.0.0
> > git cherry-pick -x $(git log --pretty=%H -n1 v1-train)
> AFAICT, the only issue whit merging this is a EOL whitespace change in
> settings.css. I'm pretty sure you can tell git to ignore whitespace changes
> when resolving conflicts but I can't remember how right now.
> 
> Lukas: I can confirm it has not been uplifted yet.

Yep, it's a whitespace issue, but it's a whitespace adjustment in your commit that modifies code that's not present on v1-train.  Your patch fixes whitespace in the "* Media Storage settings" area of the stylesheet, but that entire section is absent from this file on the v1-train branch.  Since your change was a whitespace change on an unrelated part of the code, I'm going to merge this with that section of stylesheet removed to match v1-train.

I generally dislike whitespace ignoring options, but out of curiosity, I did set up my repository to ignore whitespace diffs and I still got this merge conflict.

v1-train: ee6b803fefdec4d0c0df5a2da454bcf2e09a2d3c
v1.0.1: d739932704bb25922686084936a645fe5f32d267

Comment 22

[Beatriz Rodríguez [:brg]]

This issue is not fixed yet in my version: 
Gecko-c78e478
Gaia-b8bd76b
can anyone double check that this issue is properly landed and fixed?

Comment 23

[Beatriz Rodríguez [:brg]]

I reopen the issue because I do not see this fix yet, tested using:
Gecko-b66cb2b
Gaia-0c80ae9
Device: unagi

Comment 24

[Anthony Ricaud (:rik)]

The part that I worked on has been landed (per comment 21). So re-closing.

I've already explained in comment 12 and comment 20 that the actual information changes should be done in another bug. This is a per-partner or per-build change so we need to find who is responsible for that.

Comment 25

[Chris Lee [:clee]]

Anthony, where has this been landed?  Thanks.

Comment 26

[Tim Guan-tin Chien [:timdream] (please needinfo)]

(In reply to Beatriz Rodríguez [:brg] from comment #23)
> I reopen the issue because I do not see this fix yet, tested using:
> Gecko-b66cb2b
> Gaia-0c80ae9
> Device: unagi

brg, clee,

Bug 846197 will replace the default value from Vivo to empty support info, in the mean time you should use

https://wiki.mozilla.org/B2G/MarketCustomizations

to replace the support info to the empty info.

Comment 27

[amiller]

Does not make sense to create a regression issue.

Comment 28

[Darren]

Cannot verify, need steps to blackbox test this issue.

Comment 29

[cbarker]

Michelle Luna if you can Verify this bug out, it would be much appreciated.

Comment 30

[Michelle Luna]

I can verify this is fixed in build v1.1.0 build ID: 20130426070204, tested on my unagi. And I *thank you* for fixing it! Huge load off my mind.

Comment 31

[Shally Li（leave from Mozilla）]

Per comment 30,I clear "Verifyme".