Implement configuration checks for content server

[data-sync-user]

See https://jira.mozilla.com/browse/FXA-1664 for config details

┆Issue is synchronized with this Jira Task ┆Issue Number: FXA-1838

[data-sync-user]

➤ Barry Chen commented:

[~djustice@mozilla.com] I've got a couple questions based on the comment from FXA-1664 (and what I can recall from the code I've seen so far).

1. Check if the user has been shown a survey in the past month (this will be set in local storage the first time a survey is shown.

We don't save anything to local storage at this point IIRC. Have you decided on the name and the shape of the value for local storage?

2. Go through each survey until we find a survey where all of the conditions are met.

The code at the moment get all the surveys that satisfy the conditions and then pick one from the list. This sounds like it just pick the first one that satisfy the condition. Is this simply outdated and what's in the code is correct?

[data-sync-user]

➤ Barry Chen commented:

[~djustice@mozilla.com] [~jgruen@mozilla.com]

So far I've seen the example of {platform: 'mobile', region: 'southernHemisphere', lang: 'pt', relier: 'email'} for the conditions. Note that some of that info are not readily available on the client side or at all. Any IP based geo info is not on the client side. Platform/OS or anything that can be derived from the useragent string is of course possible, but UA is not currently parsed on the client side.

[data-sync-user]

➤ David Justice commented:

[~bchen@mozilla.com] We need to have conditions confirmed by [~jgruen@mozilla.com]. that example was mostly a placeholder.

We don't save anything to local storage at this point IIRC. Have you decided on the name and the shape of the value for local storage?

I haven't decided, from what me and john discussed the ask is just for no survey to be shown more frequently than 30 days, so something as simple as localStorage.setItem('surveysShown', new Date()) should be sufficient.

[data-sync-user]

➤ Barry Chen commented:

We need to have conditions confirmed by John Gruen. that example was mostly a placeholder.

Ok. I'll wait for a decision before going farther with this issue.

[data-sync-user]

➤ John Gruen commented:

So i think we will at least have to parse the UA client side, as well as pull the locale...if we can't do geo client side, maybe that's okay for the MVP, though i would generally prefer to have it.

I think for the MVP the following is fine:

• Platform - string
• Browser - string
• Relier - string - The relier for which the user is autheticating
• ReliersList - array - We wouldn't want to filter down to an exact matched list here, but would want to be able to survey ppl signing into service X who have already signed into service Y.
• hasNonDefaultAvatar - bool - (hypothesis, ppl that set an avatar are power users)
• SubscriptionsList: - array - we would want to be able to target users who have subscribed to anything and also a specific thing

[data-sync-user]

➤ John Gruen commented:

Obviously for some views we wouldn't have access to all of this info, that's totally fine.

[data-sync-user]

➤ Barry Chen commented:

So i think we will at least have to parse the UA client side, as well as pull the locale

Content server client does already have a lib for parsing the UA, so we are good there.  IP based geo location would require a new endpoint to return that info (or maybe we can get it from the devices list).  There's a list of user configured languages in window.navigator.languages if the preferred language matters.

Does "Platform" mean operating system, or some kind of form factor / device type (mobile, tablet, or desktop)?  I will make both available, but I want to keep the domain language consistent to reduce confusion.

[data-sync-user]

➤ John Gruen commented:

Yeah fair, i think we can split that into device type and OS?

[data-sync-user]

➤ Barry Chen commented:

Yeah fair, i think we can split that into device type and OS?

Most def.

[data-sync-user]

➤ Barry Chen commented:

ReliersList

There is no such list.  I don't think we can include this for the MVP.

[data-sync-user]

➤ Barry Chen commented:

ReliersList

There is no such list.  I don't think we can include this for the MVP.

Oh wait, what am I talking about... there's that list for the "Devices & apps" section.

[data-sync-user]

➤ Barry Chen commented:

IP based geo location would require a new endpoint to return that info (or maybe we can get it from the devices list).

Oh wait, what am I talking about... there's that list for the "Devices & apps" section.

Geo location filtering is going in!

[data-sync-user]

➤ Barry Chen commented:

Oh I just noticed that the title of this issue explicitly include "payment" so I should mention that everything above is regarding the content server.

[data-sync-user]

➤ Barry Chen commented:

Oh I just noticed that the title of this issue explicitly include "payment" so I should mention that everything above is regarding the content server.

I used my editing powers to remove the mention of payments from the title.