Skip to content

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

(17.0) gitlab-org/gitlab!159417 (merged)

(16.11) gitlab-org/gitlab!159418 (merged)

(16.10) gitlab-org/gitlab!159419 (merged)

(16.9) gitlab-org/gitlab!159421 (merged)

(16.8) gitlab-org/gitlab!159424 (merged)

(16.7) gitlab-org/gitlab!159426 (merged)

(16.6) gitlab-org/gitlab!159429 (merged)

(16.5) gitlab-org/gitlab!158110 (merged)

(16.4) gitlab-org/gitlab!158474 (merged)

(16.3) gitlab-org/gitlab!158475 (merged)

(16.2) gitlab-org/gitlab!158479 (merged)

(16.1) gitlab-org/gitlab!158476 (merged)

(16.0) gitlab-org/gitlab!158477 (merged)

Backport Versions

Product Manager Approval needs to be provided in the table below for each version. Without Product Manager Approval, the Backport Request will not be taken into consideration by Release Managers

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.

Edited by Eduardo Sanz García