1061548 - [User Story] As a Helpee, I want my help request to be categorized automatically based on my phone settings, so that my help request gets answered more quickly and efficiently.

Status: VERIFIED FIXED

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

Comment 1

[Anthony Ricaud (:rik)]

Pasting Mike's email on the metadata API:

* On question detail views, there is now a metadata property ( https://support.allizom.org/api/2/question/1010091/ )
 * The format, which is a bit unfortunate, is metadata: [{name: "category", value: "troubleshooting"}]. That is, a list of objects with keys "name" and "value".
* You can add metadata to questions at creation using the same format as above.
* When editing questions via POST or PATCH you can include metadata.
* To manipulate individual metadata keys, there are two more endpoints:
 * http POST /api/2/question/1010091/set_metadata name=category value=troubleshooting
 * http POST /api/2/question/1010091/delete_metadata name=category
* You can't filter by metadata yet.

Comment 2

[Anthony Ricaud (:rik)]

To collect this data, here's what I wrote in an email:

We have 4 informations to collect: 
- OS language is already accessible via navigator.language I believe.
- OS version is accessible via navigator.userAgent. It is the Gecko version so we need to convert that into a FxOS version. Also, parsing user agents is always tricky…
- handset type is accessible via the deviceinfo.product_model mozSetting. Bug 846200 already landed. I have the same issue as Paul when testing this. I’ve asked the reviewer of the patch to help us here.
- operator: We need to use the mobilenetwork permission and access navigator.mozMobileConnections[0].lastKnownHomeNetwork. This will return the mcc, mnc and network name. That reminds me, we need to know which SIM to use for multi SIM devices.

Comment 3

[Schalk Neethling [:espressive]]

(In reply to Anthony Ricaud (:rik) from comment #2)
> To collect this data, here's what I wrote in an email:
> 

Thanks for the info Anthony.

> We have 4 informations to collect: 
> - OS language is already accessible via navigator.language I believe.

This seems like the one we want so, I will go ahead and use it.

> - OS version is accessible via navigator.userAgent. It is the Gecko version
> so we need to convert that into a FxOS version. Also, parsing user agents is
> always tricky…

Yeah, but this should be ok, will take care of it.

> - handset type is accessible via the deviceinfo.product_model mozSetting.
> Bug 846200 already landed. I have the same issue as Paul when testing this.
> I’ve asked the reviewer of the patch to help us here.

Let me know once you get feedback on this. For now, I will just mock it.

> - operator: We need to use the mobilenetwork permission and access
> navigator.mozMobileConnections[0].lastKnownHomeNetwork. This will return the
> mcc, mnc and network name.

Will this be exposed as part of bug 846200 ? I see this is not part of mozSetting and is marked for internal applications only.

> That reminds me, we need to know which SIM to use
> for multi SIM devices.

Good point, you have any idea/suggestion?

Comment 4

[Anthony Ricaud (:rik)]

(In reply to Schalk Neethling [:espressive] from comment #3)
> > - operator: We need to use the mobilenetwork permission and access
> > navigator.mozMobileConnections[0].lastKnownHomeNetwork. This will return the
> > mcc, mnc and network name.
> 
> Will this be exposed as part of bug 846200 ? I see this is not part of
> mozSetting and is marked for internal applications only.
It is already exposed, since 1.1, and is accessible to privileged applications. As I said, add the "mobilenetwork" permission in the manifest. Then you can acess that info via navigator.mozMobileConnections[0].lastKnownHomeNetwork.

> > That reminds me, we need to know which SIM to use
> > for multi SIM devices.
> 
> Good point, you have any idea/suggestion?
Let's ask Romain for this.

Comment 5

[Romain Testard [:RT]]

(In reply to Anthony Ricaud (:rik) from comment #4)
> (In reply to Schalk Neethling [:espressive] from comment #3)
> > > - operator: We need to use the mobilenetwork permission and access
> > > navigator.mozMobileConnections[0].lastKnownHomeNetwork. This will return the
> > > mcc, mnc and network name.
> > 
> > Will this be exposed as part of bug 846200 ? I see this is not part of
> > mozSetting and is marked for internal applications only.
> It is already exposed, since 1.1, and is accessible to privileged
> applications. As I said, add the "mobilenetwork" permission in the manifest.
> Then you can acess that info via
> navigator.mozMobileConnections[0].lastKnownHomeNetwork.
> 
> > > That reminds me, we need to know which SIM to use
> > > for multi SIM devices.
> > 
> > Good point, you have any idea/suggestion?
> Let's ask Romain for this.

I discussed a couple of options with Wilfred:
1 Use the default data SIM
2 Use the default SIM (slot 0) and let the user change the default SIM for BuddyUp in the settings

"1 Use the default data SIM" is far more realistic as users of BuddyUp should not be considered savvy enough to do "2 so let's go with that.

Comment 6

[Anthony Ricaud (:rik)]

To go with option 1, we'll have to verify if we can get the data SIM chosen by the user through the Settings API.

Comment 7

[Anthony Ricaud (:rik)]

So even if bug 846200 works, we need to revisit this user story to account for <2.1 devices. We can't get the device name from Settings on those devices. We might be able to parse the user agent to get the device name because most devices have shipped with a modified user agent. But we need to be pretty resilient here.

So here's how I'm suggesting we modify this user story:
- If we can't identify the user's device, we won't store nor display the helpee's device. 
- The helpee can set his device name in the Profile view. In that case, we can store and display the helpee's device in questions posted after that setting.

For the helper user story, we would display questions that are matching the handset filter preference and questions without a handset.

Romain: Does that sound reasonable?

Comment 8

[Romain Testard [:RT]]

(In reply to Anthony Ricaud (:rik) from comment #7)
> So even if bug 846200 works, we need to revisit this user story to account
> for <2.1 devices. We can't get the device name from Settings on those
> devices. We might be able to parse the user agent to get the device name
> because most devices have shipped with a modified user agent. But we need to
> be pretty resilient here.
> 
> So here's how I'm suggesting we modify this user story:
> - If we can't identify the user's device, we won't store nor display the
> helpee's device. 
OK
AC updated above
> - The helpee can set his device name in the Profile view. In that case, we
> can store and display the helpee's device in questions posted after that
> setting.
> 
This is here to match helpers and helpees better. If we let the helpee set this manually it seems we'll have a high chance it won't be entered correctly - and probably even more likely the helpee won't bother at all.
I'd say let's not do that as it feels like work for little/no value

> For the helper user story, we would display questions that are matching the
> handset filter preference and questions without a handset.
> 
Yes
Updated bug 1074989 so it's tracked
> Romain: Does that sound reasonable?

Comment 9

[Schalk Neethling [:espressive]]

Currently doing a POST to:
https://support.allizom.org/api/2/question/?format=json

with the following as the data, I get a 500 error from the server:

{
    "title": "asking a new question",
    "product": "firefox-os",
    "content": " ",
    "topic": "basic-features",
    "locale": "en-US",
    "metadata": [
        {
            "name": "os_version",
            "value": "20100101"
        },
        {
            "name": "handset_type",
            "value": "Alcatel"
        },
        {
            "name": "operator",
            "value": "Movistar"
        }
    ]
}

The only change from what was previously submitted and what is submitted now, is the addition of the locale and metadata properties.

Comment 10

[Michael Cooper [:mythmon]]

What I said in that first email was, unfortunately, incorrect. Between then and now (in particular, when implementing user settings). I figured out that I had a made a mistake with this style of DRF binding (the foreign key to name/value pairs). I spend some time on it, and wasn't able to make it work that way.

The only way I was able to make editing metadata work is by doing seperate requests to

    http POST kitsune/api/2/questions/1234/set_metadata name=os_version value=20100101

this is pretty lame, but I couldn't find a sane way to make it work the other way consistently. Sorry about that. I could put more time into this later, but I think it would require bigger changes that affect the rest of SUMO.

Comment 11

[Schalk Neethling [:espressive]]

(In reply to Mike Cooper [:mythmon] from comment #10)
> 
> The only way I was able to make editing metadata work is by doing seperate
> requests to
> 
>     http POST kitsune/api/2/questions/1234/set_metadata name=os_version
> value=20100101

Ok, so separate requests for each meta data entry, got it. Thanks

Comment 12

[Schalk Neethling [:espressive]]

(In reply to Mike Cooper [:mythmon] from comment #10)
> What I said in that first email was, unfortunately, incorrect. Between then
> and now (in particular, when implementing user settings). I figured out that
> I had a made a mistake with this style of DRF binding (the foreign key to
> name/value pairs). I spend some time on it, and wasn't able to make it work
> that way.
> 
> The only way I was able to make editing metadata work is by doing seperate
> requests to
> 
>     http POST kitsune/api/2/questions/1234/set_metadata name=os_version
> value=20100101
> 

I have tried this two different ways, the first was to use a request with auth but, then I get an error that POST is not allowed and, if I attempt to call it without auth I get unauthorised.

The data that will be sent is something like:
{"name":"os_version","value":"20100101"}

And the request is made to:
https://support.allizom.org/api/2/question/1010403/?format=json

Comment 13

[Michael Cooper [:mythmon]]

Are you trying to modify the question as the question creator? So far only the creator can edit a question, including adding metadata. This is something I'm planning on changing, but it hasn't been needed yet. In general, "Unauthorized" means that the server knows who you are, and won't give you permission to do something.

Additionally, you used the wrong url. The request needs to be made to 

    https://support.allizom.org/api/2/question/1010403/set_metadata?format=json

Otherwise you're trying to post to a question which isn't allowed.

Comment 14

[Schalk Neethling [:espressive]]

(In reply to Mike Cooper [:mythmon] from comment #13)
> Are you trying to modify the question as the question creator? So far only
> the creator can edit a question, including adding metadata. This is
> something I'm planning on changing, but it hasn't been needed yet. In
> general, "Unauthorized" means that the server knows who you are, and won't
> give you permission to do something.
> 
> Additionally, you used the wrong url. The request needs to be made to 
> 
>    
> https://support.allizom.org/api/2/question/1010403/set_metadata?format=json

meh, my bad :/ that is most likely the problem. And, with regards to your other question, I am adding the metadata as the creator yes.

Comment 15

[Schalk Neethling [:espressive]]

(In reply to Mike Cooper [:mythmon] from comment #13)
> Are you trying to modify the question as the question creator? So far only
> the creator can edit a question, including adding metadata. This is
> something I'm planning on changing, but it hasn't been needed yet. In
> general, "Unauthorized" means that the server knows who you are, and won't
> give you permission to do something.
> 
> Additionally, you used the wrong url. The request needs to be made to 
> 
>    
> https://support.allizom.org/api/2/question/1010403/set_metadata?format=json
> 
> Otherwise you're trying to post to a question which isn't allowed.

Ok, so I am now posting to:
https://support.allizom.org/api/2/question/1010409/set_metadata?format=json

also tried:
https://support.allizom.org/api/2/question/1010409/set_metadata/?format=json (just in case)

with:
{"name":"handset_type","value":"Alcatel"}

And I am getting 301 Moved Permanently

--

I did this both with and without auth i.e. passing the user token. Just some additional info. I am doing this when the question is first posted so:

I post the questions, and once the response returns, I use the ID of the new post response to add the metadata.

So, send the request to the server for the new question, on response, get the id of the question and then use that for the follow on requests to set_metadata.

Comment 16

[Schalk Neethling [:espressive]]

You can see the code here:
https://github.com/ossreleasefeed/buddyup/blob/bug1061548-add-user-metadata-to-question-on-post/app/js/sumo_db.js#L66

Comment 17

[Michael Cooper [:mythmon]]

hmm. I did

$ http POST 'https://support.allizom.org/api/2/question/1010264/set_metadata/?format=json' Authorization:'Token XXX' name=test value=metadata

and it worked fine. Where is the 301 moved permanently sending you? I get 301 when I leave off the trailing /, but when I having the trailing slash it works fine. It looks like you left the trailing slash off in the code you linked.

Comment 18

[Schalk Neethling [:espressive]]

(In reply to Mike Cooper [:mythmon] from comment #17)
> hmm. I did
> 
> $ http POST
> 'https://support.allizom.org/api/2/question/1010264/set_metadata/
> ?format=json' Authorization:'Token XXX' name=test value=metadata
> 
> and it worked fine. Where is the 301 moved permanently sending you? I get
> 301 when I leave off the trailing /, but when I having the trailing slash it
> works fine. It looks like you left the trailing slash off in the code you
> linked.

hmmm, I believe I tried both. Let me give it another go. Thanks!

Comment 19

[Schalk Neethling [:espressive]]

the / slash did the trick. I could have sworn I tried it though but alas, it is working now \o/

Comment 20

[Schalk Neethling [:espressive]]

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

Comment 21

[Anthony Ricaud (:rik)]

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

We'll also need some server side changes. 

We have some small changes to do on the pull request, nothing major.

Comment 22

[Anthony Ricaud (:rik)]

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

We have just one tiny change for the regexp. You can land once that is done (with commits squashed too).

Comment 23

[Schalk Neethling [:espressive]]

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

Please give this one more review and test round from your end. I kinda feel I missed something.

Comment 24

[Schalk Neethling [:espressive]]

PR merged - https://github.com/ossreleasefeed/buddyup/commit/0604ae45bdb1eb1a1f2b8ea4ec6d2daff38f8561

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

Comment 25

[Anthony Ricaud (:rik)]

The merge commit is actually https://github.com/mozilla/buddyup/commit/49de4da818274753b8beae5e7cb07443cd82e502