Disable pages access control for projects created before enabling it on gitlab.com
We want to enable pages access control on gitlab.com.
The default value for pages_access_level
is ProjectFeature::ENABLED
not ProjectFeature::PUBLIC
, and if we enable access control right now, all of them will become available only for project members after any update of JSON config(e.g. running new pipeline).
We need to change access control level to ProjectFeature::PUBLIC
for each project created after releasing of pages access-control feature.
Originally we thought that we also need to run Projects::UpdatePagesConfigurationService.new(project).execute
to update JSON configs. But reading https://gitlab.com/gitlab-org/gitlab-ce/issues/56386 and original MR for access control suggests that pages configs always have access control disabled while access control is disabled on instance level:
Extracted from discussion https://gitlab.com/gitlab-com/gl-infra/infrastructure/issues/5576#note_151695397
This was an intentional design decision at the time we introduced the feature: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/18589#note_81609062
To restate the reasoning briefly: it seemed like it would be very unexpected for thousands of currently-public Pages sites to become private on deploy day. Private projects could already use Pages, and the admins must have known that their pages were publicly available, and been OK with that. Making them all private automatically would contravene that decision, and quite probably break many existing sites relative to their owners' expectations.
Having new projects default to private meets expectations at the time the project is created. It's a setting the user can review.
I guess a new discontinuity has been introduced by the fact that it's taken us some time to enable access control for pages on GitLab.com though - and maybe this is what you're referring to? E.g. we now have three groups of projects:
- Created before access control for pages existed
- Default value is public
- Meets user expectations
- Created after accesss control for pages existed, but before it was enabled on GitLab.com
- Default value is private, but pages are public since access control is disabled
- Perhaps doesn't meet user expectations - should they be treated more like the first group?
- Created after access control for pages was enabled on GitLab.com
- Default value is private
- Meets user expectations
The second group is weird. Since access control for pages hasn't been enabled on GitLab.com, the user never saw the "Pages access control" slider, so if they're using pages, they (almost) certainly noticed the pages were public, and either deleted them, or were OK with the situation.
On the other hand, it seems a bit scary to take projects in this group and automatically set them to be public. That seems scary for GitLab.com, and similarly scary for our self-managed users.
Do we have a go-live date for enabling this on GitLab.com? Perhaps the right thing to do here is to send an email to people responsible for the projects in group 2, notifying them that their pages will become private on that date and asking them to get in touch if they'd like us to keep them public. We don't have UI in GitLab for this, so we'd probably have to generate support tickets :/
Additionally, I agree, we should change GitLab so it takes account of whether access control is enabled when setting the default for this column. If it's disabled, we can create new projects with
pages_access_control: public
.Note that we can't just update rows in the database to make the existing pages private - we'll also have to update tens of thousands of
config.json
files on disk for the change to take effect.