1074989 - [user story] As a Helper, I can set a friendly name, my preferred languages, my preferred operator and my preferred handset, so that I can define my profile

Status: VERIFIED FIXED

(support.mozilla.org :: BuddyUp, defect)

Description

[Kadir Topal [:atopal]]

As a Helper, I can set a friendly name, my preferred languages, my preferred operator and my preferred handset, so that I can define my profile

Comment 2

[Schalk Neethling [:espressive]]

I have implemented the layout for the helper's profile. Currently I am using fake data for the view, below then are the fields we would require from the API that returns a helper's profile data.

Note: some of these might already exists but, to ensure nothing is missed, I am listing all fields here.

//--

Friendly Name
Number of questions answered by helper
Number of helpful up votes received by helper

New comment on thread notification (on/off)
New question reminder notification (on/off)

Locale
[need to be able to request a list of locales]

Device Type
[need to be able to request a list of devices]

Operator
[need to be able to request a list of operators]

//--

For all of these, we would need read/write access.

Comment 3

[Schalk Neethling [:espressive]]

Will the profile contain a field indicating whether the user is a helper or a helpee?

Comment 4

[Schalk Neethling [:espressive]]

After the meeting yesterday the following was decided in terms of the handsets and operators:

For operators, take it from their device, don’t let them choose.
  Default is “All”
  The other choice is the operator they are currently using
  If no operator, default to all and disable select

For handset we use a multiple choice selector
  We’ll use only the handset makers, not models
  Hermina will provide the list

Comment 5

[Schalk Neethling [:espressive]]

Thinking more on comment 3, perhaps if we are using the create_user API, to auto generate a user, we can add a role=helpee to the response and if this user logged in with FxAccounts, the role will not be there (I assume) so we can take it as a role of helper. Thoughts?

Comment 6

[Schalk Neethling [:espressive]]

Scratch comment 3 and comment 5, we can probably do these easier on the client side.

Comment 7

[Schalk Neethling [:espressive]]

Some questions below:

Acceptance criteria:

* Helper can tap the “language” picker to open a list of languages and then select his preferred language. The Helper can validate his selected language.

>> Where should we pull the list of available languages from? Is there an API, a native way on the device or, should this be hard coded in the app?

* Helper can tap the “operator” picker to open a list of operators and then select as many operators as he wants. Helper can validate selected operators.

>> Is this correct? Helper can select multiple operators? I was under the impressions that it is either all, or a specific operator.

Comment 8

[Romain Testard [:RT]]

(In reply to Schalk Neethling [:espressive] from comment #7)
> Some questions below:
> 
> Acceptance criteria:
> 
> * Helper can tap the “language” picker to open a list of languages and then
> select his preferred language. The Helper can validate his selected language.
> 
> >> Where should we pull the list of available languages from? Is there an API, a native way on the device or, should this be hard coded in the app?
> 
I think I need Kadir's help here.
My understanding is that SUMO desktop currently limits access to the forum based on the URL you hit (https://support.mozilla.org/fr/products/firefox has no community support option).
The app will start with support of en, pt and es and it sounds like questions should only be supported in these languages (Kadir can probably confirm).
Under that assumption we should:
1 Only make the app available to users whose OS language is en, pt or es (helpee's language defaults to the OS language)
2 Let the helper select between en, pt or es to receive alerts on questions submitted in these languages

> * Helper can tap the “operator” picker to open a list of operators and then
> select as many operators as he wants. Helper can validate selected operators.
> 
> >> Is this correct? Helper can select multiple operators? I was under the impressions that it is either all, or a specific operator.
Yes, this seems to make better sense to implement this way, I'll change the AC

Comment 9

[Kadir Topal [:atopal]]

(In reply to Romain Testard [:RT] from comment #8)
> (In reply to Schalk Neethling [:espressive] from comment #7)
> > Some questions below:
> > 
> > Acceptance criteria:
> > 
> > * Helper can tap the “language” picker to open a list of languages and then
> > select his preferred language. The Helper can validate his selected language.
> > 
> > >> Where should we pull the list of available languages from? Is there an API, a native way on the device or, should this be hard coded in the app?
> > 
> I think I need Kadir's help here.
> My understanding is that SUMO desktop currently limits access to the forum
> based on the URL you hit (https://support.mozilla.org/fr/products/firefox
> has no community support option).
> The app will start with support of en, pt and es and it sounds like
> questions should only be supported in these languages (Kadir can probably
> confirm).
> Under that assumption we should:
> 1 Only make the app available to users whose OS language is en, pt or es
> (helpee's language defaults to the OS language)

Selecting a language for which we don't have any questions will result in an empty list, so it only makes sense to offer them languages that are active. For the start I think en, pt, es are as good as any. However you want to implement this is up to you.  


> 2 Let the helper select between en, pt or es to receive alerts on questions
> submitted in these languages

Not sure what this is about? Would we need several language pickers in this case?

Comment 10

[Schalk Neethling [:espressive]]

Attachment: https://github.com/mozilla/buddyup/pull/46

Comment 11

[Anthony Ricaud (:rik)]

While testing this, I see the server returns a 404 when we delete a setting that doesn't exist. That means we're falling into the .catch of our request_with_auth promise and so we're no setting the setting after deleting it.

Comment 12

[Anthony Ricaud (:rik)]

Comment on attachment 8543878 [details] [review]
https://github.com/mozilla/buddyup/pull/46

I've left a few comments for a better separation of concerns. Also I can't r+ this until we have a better way to store those settings.

Comment 13

[Romain Testard [:RT]]

> 
> > 2 Let the helper select between en, pt or es to receive alerts on questions
> > submitted in these languages
> 
> Not sure what this is about? Would we need several language pickers in this
> case?

Yes it would imply a new language picker. Not for phase 1 but it seems we'll need this for later - I assume a significant number of helpers will be able to deal with questions in their phone OS language as well as english. Do you allow this currently on SUMO?

Comment 14

[Kadir Topal [:atopal]]

No, on SUMO we only present a single language per view. If you want to answer questions in another language, you have to switch over to that language. We might want to deviate from that in BuddyUp, but as you said, not for phase 1.

Comment 15

[Anthony Ricaud (:rik)]

Comment on attachment 8543878 [details] [review]
https://github.com/mozilla/buddyup/pull/46

Can you please open a bug to remove the workaround once bug 1118037 is solved? It should depend on bug 1118037.

Comment 16

[Schalk Neethling [:espressive]]

(In reply to Anthony Ricaud (:rik) from comment #15)
> Comment on attachment 8543878 [details] [review]
> https://github.com/mozilla/buddyup/pull/46
> 
> Can you please open a bug to remove the workaround once bug 1118037 is
> solved? It should depend on bug 1118037.

Done, https://bugzilla.mozilla.org/show_bug.cgi?id=1118851

Comment 17

[Anthony Ricaud (:rik)]

Comment on attachment 8543878 [details] [review]
https://github.com/mozilla/buddyup/pull/46

Two comments have not been addressed and we need to send all values to the server.

Comment 18

[Anthony Ricaud (:rik)]

Comment on attachment 8543878 [details] [review]
https://github.com/mozilla/buddyup/pull/46

All good to go after squashing.

Comment 19

[Schalk Neethling [:espressive]]

Commit merged https://github.com/ossreleasefeed/buddyup/commit/935ec25fec2a6fb339c38cc69fbde2f0469109e1

https://github.com/mozilla/buddyup/pull/46

Comment 20

[Anthony Ricaud (:rik)]

The buddyup commit was https://github.com/mozilla/buddyup/commit/aefb50785407aef706ec873868df530a49c751aa