Backport UI banner for SM managed users informing them about token expiration
Issue link
https://gitlab.com/gitlab-org/gitlab/-/issues/462157+
Does this request relate to a bug or to a feature?
This is a request to backport a UI banner for SM users who would see a 1 year expiration set to tokens that are currently without one as part of the deprecation. The backport request is for GitLab version 16.0 to 16.5. A similar change was backported to 16.6
to 17.0
previously via https://gitlab.com/gitlab-org/release/tasks/-/issues/10973. See https://gitlab.com/gitlab-org/gitlab/-/issues/462157#note_1977851237 for leadership approval on the additional backport.
MR(s)
-
The same changes are already deployed to GitLab.com, and those MRs can be found in the Related Merge Requests table.
MRs | Does this cleanly apply to the desired branch? | Is the MR ready for merge? | Test Platform has verified results? | Notes |
---|---|---|---|---|
(Master) gitlab-org/gitlab!154944 (merged) and gitlab-org/gitlab!159231 (merged) |
|
N/A | N/A | original addition for reference |
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
Backport Versions
Version | Approval from Product (to confirm the bug justifies the upgrade cost) | Approval by Release Manager | Notes |
---|---|---|---|
17.0 | |||
16.11 | |||
16.10 | |||
16.9 | |||
16.8 | |||
16.7 | |||
16.6 | |||
16.5 | |||
16.4 | |||
16.3 | |||
16.2 | |||
16.1 | |||
16.0 |
Does this bug potentially result in data loss?
This change will not result in dataloss and is only a UI component that can be dismissed by the user.
Customer impact
On GitLab.com, we discovered that a large number of our customers were not prepared for the tokens to be expired. For self managed users we are using a multi-prong approach of sending communications via a variety of channels (emails/CSM outreach) but an in-app notofication that warns them about the risk and links to troubleshooting scripts has the best probability of being noticed.
Product DRI - @hsutor *
Workaround
There isn't a workaround if the users on these version don't see communications that were sent out around the breaking change.
@gitlab-org/release/managers please assign yourselves to this issue.