[Scope] location settings are enabled by default

[Thomas Strehl]

This is in contrast to the rest of the system where user have to explicitly grant access right upfront.

Possible solution would be to add a new page in phone setup wizard asking for whether scopes are allowed to use location or not and then applying this to individual scope location settings.

--------UX comment---------

Potential new project: When scopes will be launched as apps, we'll probably need some coach marks // independent onboard experience to explain data consumption and location services usage.

[Pat McGowan (pat-mcgowan)]

This really needs to work the same as the rest of the system, the first time the scope tries to access location the user is prompted to grant access, and the access can thereafter be managed in settings. This could be all scopes but specific scope grants would be better.

[Thomas Strehl (strehl-t)]

We haven't yet completely figured the part of scopes requesting trusted prompt or rather the dash on behalf of the scopes. There are some options but those will take a little bit more effort to implement. Also we need to make sure that we don't break scopes as they currently get their location as query parameter and not requesting this directly via location service which usually triggers trusted prompt.

Triggering a trusted prompt for each scope utilizing location means an avalanche of prompts the phone is used the very first time. Consistent but probably not best user experience.

[Pat McGowan (pat-mcgowan)]

Seems that Nearby which uses weather, yelp wikipedia and songkick would need permissions or each ot the four. We could pre-seed permission for these which would allow access but user could disable them.

Adding UX for guidance

[Thomas Strehl (strehl-t)]

Possible fix would be to add a page to phone setup wizard asking users whether they allow, by default, scope to access location data or not. That setting will also be available via Settings|Privacy. Then, we'd change the individual scope location settings to provide two states, system|off ("system" being default). With this, scopes by default take the system or rather scopes wide system settings but it still offers the possibility to disable location for individual scopes. Also note that changing the location settings value would not require any changes to existing scopes.

[Michi Henning (michihenning)]

The problem appears to be the avalanche of trusted prompts that will be triggered on the first search on an aggregator that talks to a bunch of child scopes. This creates an OOBE that truly sucks.

Rather than have five or more prompts in a row, would it be possible, the first time an aggregator that needs location info gets a search, to trigger a *single* dialog that is nice and friendly? Something along the lines of "The following scopes have requested access to location information: Scope1, scope2, scope3. Do you want to permit this? You can change these settings at any time in system settings, or click here to do this now."

At least this would stop popping a while series of prompts.

Also, for some scopes that we "trust", would it be possible to have them installed with permission already enabled? I don't know whether there is such a thing as a "trusted click package". But, if we could do this, we would avoid the trusted prompt for at least some of the scopes.

[Paty Davila (dizzypaty)]

Potential new project: When scopes will be "launched as apps", we'll probably need some coach marks // independent onboard experience to explain data consumption and location services usage.

[Paty Davila (dizzypaty)]

Also, we may want to consider changing the wording of 'Enable location data' for something like: 'Allow this scope to use your default location settings'. And the position of the Location list item in Scope settings should be consistent - always at the top or at the bottom of the list. My recommendation will be to place it at the top.

[Pat McGowan (pat-mcgowan)]

Adding for tracking, need to determine if its a blocker for ota

[Jason Yen (jasonyen)]

@Pat,

After the discussion with Rex. This is a potential blocker for CTA Level 1. Can we add it to the blocking list? Thanks.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Alejandro J. Cura (alecu)]

Adding location service to the bug.

[Paweł Stołowski (stolowski)]

Currently blocked on https://bugs.launchpad.net/trust-store/+bug/1547573

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Paweł Stołowski (stolowski)]

This is now in silo 65 and the test plan https://wiki.ubuntu.com/Process/Merges/TestPlan/scopes has been updated.

[Launchpad Janitor (janitor)]

This bug was fixed in the package unity-scopes-shell - 0.5.7+16.10.20160615-0ubuntu1

---------------
unity-scopes-shell (0.5.7+16.10.20160615-0ubuntu1) yakkety; urgency=medium

  * Use Qt Location API. (LP: #1419829)

 -- Pawel Stolowski <email address hidden> Wed, 15 Jun 2016 20:18:25 +0000