- 
                Notifications
    
You must be signed in to change notification settings  - Fork 273
 
Update telemetry: emit auth scopes in user state #4944
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
          Qodana Community for JVM4 new problems were found 
 💡 Qodana analysis was run in the pull request mode: only the changed files were checked Contact Qodana teamContact us at [email protected] 
  | 
    
| 
           The userState() function in AuthTelemetry did not have a parameter for authScopes-- hence just calling the TelemetryService function directly to add that datum in place. That's how VSCode was doing it  | 
    
        
          
                ...community/src/software/aws/toolkits/jetbrains/core/gettingstarted/GettingStartedAuthUtils.kt
              
                Outdated
          
            Show resolved
            Hide resolved
        
      | createTime(Instant.now()) | ||
| unit(Unit.NONE) | ||
| value(1.0) | 
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
these are implicit
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
They are implicit if you use the userState function in AuthTelemetry-- which just calls the TelemetryService function using these values. I thought I had to add them here since I was not using the userState function and they weren't being set. I did not see a method signature in AuthTelemetry that would let me pass in the extra authScopes datum-- and I wasn't sure where/if I could update the userState method.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This metric is currently in telemetryOverride. We need to use the one from common.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I understand that our AuthTelemetry is being generated. no version of AuthTelemetry.userState() accepts authScopes as a parameter. I think this might be why? :
I'll try making some changes to common locally to see if I can generate a version of the function that does.
| val scopes = ToolkitAuthManager.getInstance().listConnections().flatMap { connection -> | ||
| when (connection) { | ||
| is ProfileSsoManagedBearerSsoConnection -> connection.scopes | ||
| is LegacyManagedBearerSsoConnection -> connection.scopes | ||
| else -> emptyList() | ||
| } | ||
| }.toSet() | 
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
honestly it seems odd that we inspect every connection instead of what the extension is actively using, which seems more useful
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
VScode seems to be doing this same thing: grabbing the scopes from every SSO connection returned from listConnections so that's why I did it this way.
…brains/core/gettingstarted/GettingStartedAuthUtils.kt Co-authored-by: Richard Li <[email protected]>
| authStatus = getAuthStatus(project), | ||
| passive = true | ||
| ) | ||
| val explorerConnection = ToolkitConnectionManager.getInstance(project).activeConnection() | 
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right now, I am just grabbing the connection being used by the explorer. I see that the activeConnection() function is marked as deprecated, but there is no alternative for getting the explorer connection from what I've seen. The getActiveConnectionForFeature function seems to work only for Q, CodeCatalyst, and CodeWhisperer.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we want to look at all the active connections, I think it would be easy enough to use a function like:
Line 23 in 80abea5
| fun getEnabledConnectionsForTelemetry(project: Project?): Set<AuthFormId> { | 
to get the scopes from each active connection. If we are looking at enabled connections in this Telemetry metric, why not the scopes for those enabled connections?
…onnected/expired.
          Qodana Community for JVMIt seems all right 👌 No new problems were found according to the checks applied 💡 Qodana analysis was run in the pull request mode: only the changed files were checked Contact Qodana teamContact us at [email protected] 
  | 
    
| createTime(Instant.now()) | ||
| unit(Unit.NONE) | ||
| value(1.0) | 
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This metric is currently in telemetryOverride. We need to use the one from common.
| val codeCatalystConnection = checkBearerConnectionValidity(project, BearerTokenFeatureSet.CODECATALYST) | ||
| addScopes(codeCatalystConnection) | ||
| 
               | 
          ||
| val codeWhispererConnection = checkBearerConnectionValidity(project, BearerTokenFeatureSet.CODEWHISPERER) | 
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wonder if we still need this since Q or we should just record Q
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
From Dhruvi: " let's not be concerned about old customers since most of them have migrated"
I'll remove it.
| } | ||
| } | ||
| 
               | 
          ||
| val explorerConnection = checkIamConnectionValidity(project) | 
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We could also probably check the connection type and use the addScopes function only if the connection type is IDC. We can probably just hardcode it anyway
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Check the connection type of the explorer only? Would that not ignore the other connections/scopes available if those other features are using the IdC connection type while the explorer isnt?
      
        
              This comment was marked as outdated.
        
          
      
    
    This comment was marked as outdated.
Sorry, something went wrong.
| ActiveConnection.ValidIam(connectionType = connectionType, activeConnectionIam = currConn) | ||
| } | ||
| } | ||
| 
               | 
          
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wrote this because the other function was using isCredentialSSO would always return IAM, even in cases where it should be IAM_IDC.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The other function is for the getting started auth which contains a dialog that accepts a session name.
Where does this function determine the credential type?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I saw that there was a CredentialType enum attached to the selected credentials so I thought I could use that. If the credentialType is an SsoProfile, does that not mean it is part of an IDC session?
| fun getEnabledConnections(project: Project?): String = | ||
| getEnabledConnectionsForTelemetry(project).joinToString(",") | ||
| 
               | 
          ||
| fun getAuthScopesForTelemetry(project: Project?): Set<String> { | 
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The function above repeats some of the logic used here, can we move the common logic to a function?
| ActiveConnection.ValidIam(connectionType = connectionType, activeConnectionIam = currConn) | ||
| } | ||
| } | ||
| 
               | 
          
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The other function is for the getting started auth which contains a dialog that accepts a session name.
Where does this function determine the credential type?
* add authScopes to emitUserState telemetry * add authScopes to emitUserState telemetry * Replace userState function with direct TelemetryService record function to capture authScopes * add value parameter * fix whitespace * Update plugins/core/jetbrains-community/src/software/aws/toolkits/jetbrains/core/gettingstarted/GettingStartedAuthUtils.kt Co-authored-by: Richard Li <[email protected]> * Check current explorerConnection for scopes only * Add function to grab scopes from each activeConnection used that is connected/expired. * remove TelemetryOverride definition and use common's telemetry function instead * remove unused imports * Change the way explorer connection scope is checked * remove check for CodeWhispererConnection: merged into qConnection & qScopes * add common logic to one function * Update telemetryOverride.json missed { --------- Co-authored-by: Richard Li <[email protected]>
Types of changes
Description
Changed the emitUserState function to add authScopes to the telemetry record. Scopes were previously not recorded with this metric.
Checklist
License
I confirm that my contribution is made under the terms of the Apache 2.0 license.