Update GitLab Pages access control wording and options
What's the problem?
The original logic introduced in !176757 (merged) was intended to provide greater enforcement of access level permissions on a group for all project-level Pages configurations. As it exists today, this setting is being seen as misleading and is disruptive to users that utilise the Internal projects visibility setting. The setting will restrict access to Pages for project members only, but it is still possible for Pages deployments to be accessed as the project-level setting is retained.
The UI and documentation states:
Restrict access to only project members on all group projects
When enabled, all projects in the group and its subgroups become visible only to members.
The use of project members and members could be seen as misleading, and does limit the usefulness of this setting for Internal projects.
What does this MR do and why?
This MR:
- Removes the 'read-only' logic in the dropdown for changing the Pages visibility configuration. It permits users to choose what visibility the Pages deployment has, limited to the project visibility setting. See the comparison table below for reference.
- If 'public access' is disabled, remove the option to use
Everyoneas an option. This will still respect a project's visibility level, and provide the options accordingly. - Brings the group-level setting more in-line with the instance setting.
- It notes: "This can be helpful to restrict information published with Pages websites to the users of your instance only."
- This means there is no implied enforcement on just project members of the project.
- Updates the wording to better reflect that public-only access is removed:
- "Remove public access to GitLab Pages on all group projects"
- "When enabled, public access is removed for all projects in the group and its subgroups"
Comparison of available options between master and the feature branch:
Please note, this is just what is presented in the dropdown. The actual project access level can still exist and remains even if we don't show it here.
GitLab.com (Production)
| Access Control Forced? | Project setting | Options available |
|---|---|---|
| No | Private |
Only Project Members, Everyone
|
| No | Internal |
Only Project Members, Everyone With Access, Everyone
|
| No | Public |
Only Project Members, Everyone
|
| Yes | Private | Only Project Members |
| Yes | Internal | Only Project Members |
| Yes | Public | Only Project Members |
Feature Branch
| Access Control Forced? | Project setting | Options available |
|---|---|---|
| No | Private |
Only Project Members, Everyone
|
| No | Internal |
Only Project Members, Everyone With Access, Everyone
|
| No | Public |
Only Project Members, Everyone
|
| Yes | Private | Only Project Members |
| Yes | Internal |
Only Project Members, Everyone With Access
|
| Yes | Public |
Only Project Members, Everyone With Access
|
References
Screenshots or screen recordings
| Before | After |
|---|---|
 |
 |
How to set up and validate locally
- Deploy a GDK environment with GitLab Pages and access control enabled.
- In a top-level group, enable or disable the feature setting.
- Confirm availability of Pages visibility, based on the project's visibility.
MR acceptance checklist
Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.