Refactor kMetricsRportingEnabled checks for all platformsChirag Arora```suggestion
Refactor kMetricsReportingEnabled checks for all platforms
```
Fix applied.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
bool MetricsReportingChoiceService::IsMetricsReportingDisabled(
const PrefService* local_state) {
CHECK(local_state);
if (ShouldUseMetricsConsentRestructure(local_state)) {
return local_state->IsManagedPreference(prefs::kMetricsReportingLevel) &&
!IsBasicMetricsReportingEnabled(local_state);
}
return local_state->IsManagedPreference(prefs::kMetricsReportingEnabled) &&
!IsBasicMetricsReportingEnabled(local_state);
}Chirag Aroranit: this seems a bit confusing, there's both an `IsReportingEnabled()` function and an `IsReportingDisabled()` function, yet they may both return false at the same time? it's not super obvious to me which one should be used at which time, is the plan to consolidate these? maybe add a todo comment
Makes sense. Renamed to `IsMetricsReportingDisabledByPolicy`.
if ((!base::FeatureList::GetInstance() ||
base::FeatureList::IsEnabled(
features::kRestructureMetricsConsentSettings)) &&
local_state->GetBoolean(prefs::kMetricsReportingMigrationDone)) {
// If FeatureList is not initialized yet (e.g., during early startup), we
// can't check the feature flag. But if the user has already migrated, we
// know they were in the experiment, so we should assume the feature is
// enabled to avoid downgrading the entropy provider or crash reporting
// unnecessarily.
switch (static_cast<MetricsReportingLevel>(
local_state->GetInteger(prefs::kMetricsReportingLevel))) {
case MetricsReportingLevel::kBasic:
case MetricsReportingLevel::kAdvanced:
return true;
default:
return false;
}
}
return local_state->GetBoolean(prefs::kMetricsReportingEnabled);Chirag Aroranit: i think this should be done in the parent CL that adds `IsBasicMetricsReportingEnabled()`?
Chirag AroraIt's being done to keep CLs small. Another CL will also be needed for replacing checks in the iOS codebase but it's not being added here since I'll create that from my local macOS copy of the repo. LMK what you think.
Luc NguyenAdded for iOS as well in this CL
Chirag Arorato be clear i didn't mean the whole CL, i meant this code specifically
in the parent CL you're moving/duplicating this exact code to a new `IsBasicMetricsReportingEnabled()` function ([link](https://chromium-review.git.corp.google.com/c/chromium/src/+/7784653/10/components/metrics/metrics_reporting_choice_service.cc)), seems pretty obvious to me that you should also remove this code in that other CL instead just completely duplicating it?
Makes sense. Moved to the CL below.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
bool MetricsReportingChoiceService::IsMetricsReportingDisabled(
const PrefService* local_state) {
CHECK(local_state);
if (ShouldUseMetricsConsentRestructure(local_state)) {
return local_state->IsManagedPreference(prefs::kMetricsReportingLevel) &&
!IsBasicMetricsReportingEnabled(local_state);
}
return local_state->IsManagedPreference(prefs::kMetricsReportingEnabled) &&
!IsBasicMetricsReportingEnabled(local_state);
}Chirag Aroranit: this seems a bit confusing, there's both an `IsReportingEnabled()` function and an `IsReportingDisabled()` function, yet they may both return false at the same time? it's not super obvious to me which one should be used at which time, is the plan to consolidate these? maybe add a todo comment
Makes sense. Renamed to `IsMetricsReportingDisabledByPolicy`.