As of February 15, 2024, Code Suggestions will transition from a free to a paid feature. Users will required a purchased license for access. To ensure a smooth transition, it's important to enhance the UI to clearly communicate the change and guide users on the necessary steps to continue using Code Suggestions.
Proposal
An API will allow us to check for user's license status. If user does not have a Code Suggestions license provisioned, the Duo icon should be crossed out to indicate disabled status. Hovering over the icon will reveal a tooltip: Code Suggestions is now a paid feature, part of Duo Pro. Contact your GitLab administrator to upgrade. This will inform users about the new requirement and direct them to their admin to get access.
Additional Considerations
Because this feature is tied to a specific date, consider feature toggle.
If it seems reasonable, what do we need to build in Rails to facilitate this? I assume an API that exposes code suggestions provisioned true/false given a user.
Can we force everyone to update IDE versions in order to have this? Do we need to?
I think this makes sense. What action should trigger the popup that tells users about this in the IDE? I assume we don't want a popup every time they start a new window. Maybe some of them will just never get a seat provisioned and it would just be frustrating?
what do we need to build in Rails to facilitate this? I assume an API that exposes code suggestions provisioned true/false given a user.
That sounds right. I'd let backend engineers figure the details out, but I assume it's rather straightforward.
Can we force everyone to update IDE versions in order to have this? Do we need to?
We can't force them. We also don't really have to, adoption is very fast (couple days to get to 90%+). See adoption chart for VS Code.
What action should trigger the popup that tells users about this in the IDE?
Not a popup, just a message next to the Code Suggestions setting in the UI telling them why they can't enable it. So it's visible only if a user actively tries to enable it.
Once a seat has been provisioned - the user shouldn't have to take another step and enable code suggestions in the IDE. But they should have the ability to disable it even if they have a seat.
Maybe a table well help here on the different permutations. Let me know if I can help create one after my start-of-holiday brain fog clears next week.
Not a popup, just a message next to the Code Suggestions setting in the UI telling them why they can't enable it. So it's visible only if a user actively tries to enable it.
I'm not sure we're able to display text dynamically like an error in the settings page (1st screenshot). We can find out.
Once a seat has been provisioned - the user shouldn't have to take another step and enable code suggestions in the IDE. But they should have the ability to disable it even if they have a seat.
I believe Code Suggestions is already enabled by default in the IDE settings, so that should be fine. Right @phikai?
Maybe a table well help here on the different permutations.
Maybe! There are a couple of cases here.
E.g. how would we prevent unprovisioned users from enabling the settings in the IDE, since it's enabled by default
@kbychu@francoisrose I think we should leave the setting in the UI alone and then we could add additional information in the pop-up from the bottom bar to the effect of Code Suggestions is not provisioned for your user, please contact your account owner. And we just keep the disabled state of the icon.
It'd be nice if we could tie even showing that to something else, likely dynamically enabling/disabling if the feature was enabled based on if a subscription exists for your namespace at all. We'll likely want to think through how much we want to "advertise" and balance that with being annoying for users who will never subscribe.
All SUS-impacting issues need to have a proper severity label set.
Please add a severity label, remove the automation:ux-missing-labels label, and then reply to this comment briefly explaining your reasoning for providing this severity.
If you are not the DRI for this area and would like help determining the best severity, please @ the appropriate person for assistance.
@francoisrose In the parent epic, I didn't find any issue describing how we'll surface the addon infor in the Rails API. I think we should create that issue, cooperate closely with whoever will implement it and until we've got the addon info exposed through API (or at least till we know the contract), there's not much to do in the extensions.
And please ping me when we're ready to start finalizing the wording. I'd like to try shortening this wording, but I've been at work for something like 30 minutes so far in 2024 and my language processors aren't fully online yet.
@francoisrose this would need to extend to all of the extensions since the granular control does not limit it to a specific IDE. @kbychu can you confirm?
Today in the Neovim plugin the status line integration is very basic and text based. We can display that there or revisit the status line integration with a framework like https://github.com/nvim-lualine/lualine.nvim#screenshots that'd give a bit of a prettier representation for users.
Dasha Adushkinachanged title from User should know if they have code suggestions seat provisioned in the IDE to User Should Know in the IDE if They Have a Code Suggestions License Provisioned
changed title from User should know if they have code suggestions seat provisioned in the IDE to User Should Know in the IDE if They Have a Code Suggestions License Provisioned
Dasha Adushkinachanged the descriptionCompare with previous version
For transparency @katiemacoy -- here's the scope of work for letting the user know if they do not have the add-on license. I'm using your original wording :)