Decouple Classification Labels from External Authorization

Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.

Proposal

At present, the classification label feature is only available when enabling external authorization. A US Federal customer has proposed decoupling classification labels from external authorization, in order to use classification labels on projects without external authorization enabled.


Relevant customer information:


Further details

I performed two tests below that show the default classification label is still added to the projects API metadata, but not shown in the UI unless External Authorization is enabled. Based on the below tests, I believe the functionality is already present and applied to projects, but may need to be decoupled from the requirement of enabling external authorization, or allow an option to apply classification labels to projects at the instance, group, and project level.

  1. On my Helm deployment, I enabled external authorization (empty service URL) and added a label to the "Default classification label" field, then disabled external authorization. I found the project's API response still contains the classification label:
$ curl -s --header "PRIVATE-TOKEN: $PRIVATE_TOKEN" https://[REDACTED/api/v4/projects/30 | jq .external_authorization_classification_label
"4737-testing-label"
  1. Without enabling external authorization (empty service URL), upon adding a label to the "Default classification label" field and saving the changes, the "Default classification label" is applied to projects, as indicated in the API response (this was tested on a separate instance with a relative URL):
$ curl -s --header "PRIVATE-TOKEN: $PRIVATE_TOKEN" https://[REDACTED]/gitlab/api/v4/projects/2 | jq .external_authorization_classification_label
"4737-testing-label"
Edited by 🤖 GitLab Bot 🤖