Frontend: Visual bug : "Allow access to this project with a CI_JOB_TOKEN" does the opposite of what it is supposed to do

Summary

The setting "Allow access to this project with a CI_JOB_TOKEN"

• Allows access when it is disabled
• Does not allow access when it is enabled

Steps to reproduce

1. Have a private project (namespace/my-private-project) with a container registry. This container registry should have a tagged image that can be pulled (my-image:latest).
2. For the private project, ensure the following settings : Settings > CI/CD > Token Access > Allow access to this project with a CI_JOB_TOKEN disabled (like the screenshot above).
3. Build another project (namespace/test-project) in the same namespace with a gitlab-ci.yml file that has the following configuration :

test-job:
    image: registry.gitlab.com/my-private-project/my-image:latest
    script:
        - echo 'Hello world'

The important aspect is that we need to pull my-image with authentication for the job.

4. Launch the job in the test-project.

What is the current bug behavior?

The test-project job can correctly pull the image from my-private-project when the setting "Allow access to this project with a CI_JOB_TOKEN" is explicitly disabled in my-private-project.

If we enable the setting, we have an authentication error that looks like this :

ERROR: Job failed: failed to pull image "registry.gitlab.com/namespace/my-private-project/my-image:latest" with specified policies [always]: Error response from daemon: pull access denied for registry.gitlab.com/namespace/my-private-project/my-image, repository does not exist or may require 'docker login': denied: requested access to the resource is denied (manager.go:237:0s)

What is the expected correct behavior?

It should be the opposite :

• When the setting is disabled, we should have the authentication error.
• When the setting is enabled, we should be correctly authenticated.

Reproduction

The bug was reproduced on a project by chance, I spent half a day trying to understand this.

Proposal

Update per comments below, we believe the text is causing confusion. Our proposed language change: