Add a reason attribute to filePUT and fileGET #54244
Conversation
| @@ -360,10 +360,16 @@ export class TextFileEditorModel extends BaseTextEditorModel implements ITextFil | |||
| "fileGet" : { | |||
| "mimeType" : { "classification": "SystemMetaData", "purpose": "FeatureInsight" }, | |||
| "ext": { "classification": "SystemMetaData", "purpose": "FeatureInsight" }, | |||
| "path": { "classification": "SystemMetaData", "purpose": "FeatureInsight" } | |||
| "path": { "classification": "SystemMetaData", "purpose": "FeatureInsight" }, | |||
| "reason": { "classification": "SystemMetaData", "purpose": "FeatureInsight" } | |||
There was a problem hiding this comment.
The reason here is a number and so comes under measurements not properties in the eventual payload of the telemetry event. So add the "isMeasurement": true in the GDPR annotation here.
Same for the filePUT event
|
I love this idea and the approach (adding a property so we can check the delta) - is there a way to indicate an open based on a folder open that resulted in past windows that resulted in files opening again? e.g. I closed 15 windows last week (some JSON, Some JS, some Java) and opened that folder this week again (and they were restored)? You may have accounted for this already but asking anyhow. Sean |
|
@seanmcbreen no, it would all look like a normal editor open. Let's wait to see what the current changes tell us and then tweak this further if we have to. |
|
LGTM |
This adds a new reason property to
filePUTandfileGETthat could give a little bit more information why certain file types are so popular over others. Most specifically, for thefileGETcase we will be able to filter out those calls that did not originate from a normal editor open. To give an example, when you open a TS file, we also seem to resolve atsconfig.jsonfile from the TS extension. This file is not opened as editor but still resolved and we count afileGETfor this call. This seems to happen only once though.