[PM-28446] Log package types #17496
[PM-28446] Log package types #17496
Conversation
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## main #17496 +/- ##
==========================================
+ Coverage 40.91% 41.11% +0.19%
==========================================
Files 3544 3544
Lines 101673 101867 +194
Branches 15234 15271 +37
==========================================
+ Hits 41602 41880 +278
+ Misses 58318 58224 -94
- Partials 1753 1763 +10 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
|
New Issues (1)Checkmarx found the following issues in this Pull Request
|
| return null; | ||
| } | ||
|
|
||
| async packageType(): Promise<string> { |
There was a problem hiding this comment.
Is there a reason why we're using "Unsandboxed" as a default here? Could we expand this to capture all of the desktop packaging methods that we can, and say "Unknown" as the default instead?
For example, adding isWindowsPortable? Perhaps that's the only missing one? I assume we don't have a way to identify whether the client is .deb or .rpm, for example?
There was a problem hiding this comment.
Updated. I think deb / rpm detection requires additional research to perform correctly and I felt it is out of scope here.
🎟️ Tracking
https://bitwarden.atlassian.net/browse/PM-28446
📔 Objective
We currently lack insight into which sandboxing packaging types are used actively. Specifically, for Linux, we don't know how many users use Snap/Flatpak versus the unsandboxed unsupported types (AppImage, deb, rpm). On Mac, the same applies for DMG/MacAppStore. This makes it hard to gauge where to spend resources / prioritize feature and bug-fix development.
This PR adds insight by adding a new header, "Bitwarden-Package-Type". This adds information that is not already contained in the "Bitwarden-Client-Name" header about specifically which package type is used.
The considered alternative was to add new device entries. However, the migration path here is long and would not give insight into existing installations.
📸 Screenshots
⏰ Reminders before review
🦮 Reviewer guidelines
:+1:) or similar for great changes:memo:) or ℹ️ (:information_source:) for notes or general info:question:) for questions:thinking:) or 💭 (:thought_balloon:) for more open inquiry that's not quite a confirmed issue and could potentially benefit from discussion:art:) for suggestions / improvements:x:) or:warning:) for more significant problems or concerns needing attention:seedling:) or ♻️ (:recycle:) for future improvements or indications of technical debt:pick:) for minor or nitpick changes