Open Bug 1345937 Opened 8 years ago Updated 2 years ago

Consolidate the ping upload check logic

Categories

(Toolkit :: Telemetry, enhancement, P3)

enhancement

Tracking

()

Tracking Status
firefox55 --- affected

People

(Reporter: Dexter, Unassigned)

Details

(Whiteboard: [measurement:client])

As found in bug 1341349, we might need to check if we're allowed to send pings in places other than TelemetrySend.jsm. We should consolidate and expose a single API from TelemetrySend to check if we're good to send pings. (In reply to Georg Fritzsche [:gfritzsche] from bug 1341349 comment #5) > > Concerns: > (1) don't send data before the privacy policy was accepted > (1a) start sending data once the privacy policy was accepted > (2) don't send data from non-official builds etc. > (3) handle data upload pref switches > (3a) stop sending when data upload is disabled > (3b) start sending again when data upload is enabled > > (1) & (2) can be addressed using e.g. TelemetrySends canSendNow() & > sendingEnabled(). > (1a) needs a TelemetryReportingPolicy listener. > (3) needs upload pref listeners. > > ... > > I agree that we should consolidate the upload check logic, not duplicate it > (whether in TelemetrySend, TelemetryController, ...). > Quickly checking around, the different pieces of the logic are still a > bit... distributed and could be centralized. > In the end this is one state machine (with different actions on state > transitions etc.).
Priority: -- → P3
Whiteboard: [measurement:client]
I've been looking into this in the context of bug 1341349 and I still believe we need to expose at least two methods for this: if TelemetrySend.sendingEnabled() returns false then not only the ping is not sent, but it's not persisted either; if TelemetrySend.canSendNow() returns false on the other hand the ping is not sent but it's persisted to disk.
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.