unified_analytics does not understand opt-out from legacy analytics

[jcollins-g]

@jacob314

Currently, unified_analytics does not recognize opt-outs from the legacy analytics. Jacob indicated that this functionality has been discussed as being a possible enhancement for 3.0 to reduce unnecessary prompting, so we should add the ability to read legacy analytics and forward an opt-out there to a reporting=0 in the new config file. We should only forward an opt-out.

[eliasyishak]

As a follow up, I think it would probably be best for the each client using this package to make the new package "aware" of the legacy opt out status.

This PR (flutter/flutter#124606) is an example of how the flutter tool will set telemetry to false if the legacy analytics class is reporting that the developer has opted out

Thoughts @jcollins-g ? I feel like this may be easier than trying to find where each tool persists files for opt out status within the package

[jcollins-g]

I had thought that legacy analytics was driven entirely through the https://pub.dev/packages/usage package. But if that's not the case and every tool has its own location to pick up analytics, then yes it might make sense to do that.

[eliasyishak]

Perfect, I'll go ahead and close this issue then. Feel free to reopen if something comes up

[jcollins-g]

I am a little confused here, again I thought that legacy analytics was driven through one entry point which would mean in my view that unified_analytics should just handle it for all clients.

[eliasyishak]

hm let me know if this example explains it? I could totally be missing what you're trying to say.

So consider that a flutter developer has been using flutter for the past year and has already opted out. Once they upgrade to the new version that includes unified_analytics, the flutter tool will be able to communicate to unified_analytics to let it know that this user has already opted out. So internally within flutter tools, it will invoke the analytics.setTelemetry(false) method.

// Trivial example
if (!legacyAnalytics.enabled && unifiedAnalytics.telemetryEnabled) {
  unifiedAnalytics.setTelemetry(false)
}

We would essentially have any tool that is a client of this package do this check with it's legacy analytics runner.

[bwilkerson]

... any tool that is a client of this package ...

I think that's the crux of the comment. Why should every tool repeat this code? The unified_analytics package could have the same check so that every tool would do the right thing without adding any code to the tool.

[eliasyishak]

Because each client using this package would know how to access their telemetry opt in status best instead of having this package attempt to check for a persisted file that each tool uses. I think there would be a lot more variability encountered that can be error prone.

ie. in my example above, it's much easier for the client using the package to invoke the pseudo command 'legacyAnalytics.enabled` than it would be for the package to know where this state is being persisted for flutter_tools. Especially considering certain users may have several flutter versions on their machine

[bwilkerson]

Because each client using this package would know how to access their telemetry opt in status best ...

One premise of the question is that, as far as we know, all of the current and future clients of this package were using the usage package to report analytics, so there is, as far as we know, only one place that would need to be queried.

[eliasyishak]

Following discussion:

Need to check the following files for legacy opt out status:

• Dart: $HOME/.dart/dartdev.json
• Flutter: $HOME/.flutter

I believe that's all we need to check right? @jcollins-g

[jcollins-g]

@eliasyishak Yes, that's correct to my reading of the code.