Project Visibility, project features, permissions settings API

I was wondering if there is a way to pragmatically, through the API, update project configuration settings for: Visibility, project features, permissions. In particular the page visibility setting. Thanks!


you’ll need to jump straight into the API docs, and extract the specific settings and URL endpoints. The simplest approach will be curl. If you are planning with a more sophisticated solution, you might also want to look into existing API client libraries which maybe provide this in an abstracted manner.


Well that would be the obvious first start. I am asking here b/c I did not see an API which currently handles my ask. So I am asking here to see if I missed something or if I need to file a feature request.

As far as I can see, you can control the attributes you’ve asked for via the API. I’m curious though what you’ve tried thus far, or what exactly you’re struggling with. Can you share existing code attempts of yours?

Oh wait, I overlooked with_custom_attributes which I am assuming is how to update all of the sub-attributes of visibility.

Here is the link to the Python api docs for the custom project attrs

What I am not clear on is how to assign the 'pages' attr shown under visibility when set to private. And I am not seeing the attr from the list of possible attrs.

Here is a screenshot:

Also when using the python api, I can fetch a list of all project attrs like so:

>>> attrs =
>>> attrs
((), ('name', 'path', 'namespace_id', 'description', 'issues_enabled', 'merge_requests_enabled', 'jobs_enabled', 'wiki_enabled', 'snippets_enabled', 'resolve_outdated_diff_discussions', 'container_registry_enabled', 'shared_runners_enabled', 'visibility', 'import_url', 'public_jobs', 'only_allow_merge_if_pipeline_succeeds', 'only_allow_merge_if_all_discussions_are_resolved', 'merge_method', 'lfs_enabled', 'request_access_enabled', 'tag_list', 'avatar', 'printing_merge_request_link_enabled', 'ci_config_path'))

But I am not seeing how the attr I am looking for unless I can somehow achieve this by using the visibility attr.

Ok, so you are using an abstracted Python library already, very good.

The custom attributes seem to be the generic interface to allow GitLab developers add/remove certain attributes without breaking function interfaces.

Same as with the user where you may specify a role,


So, if I read the docs correctly, I’d say that depending on the visibility setting of the project, you may control the pages setting.

Since you don’t see the attribute, your access token might be limited. Maybe you need full access to the API here.

The source code says that the attribute should be called pages_access_level with values defined in the ProjectFeature class.


    'disabled' => DISABLED,
    'private'  => PRIVATE,
    'enabled'  => ENABLED,
    'public'   => PUBLIC

Maybe you’ll try to set the custom attribute pages_access_level to private and public and test how this looks like.


When I created my access token, I enabled all of the checkboxes:

Is there something further I need to do in order to upgrade to admin level. As you suggested, this might be why I am not seeing the page_access_level in the returned response from the client API code I referenced.

Thanks for you help!


this is my first time jumping into specific toggles via API, and now it is evening and couch time, so I can dig a little deeper. Also for anyone else looking into the issue - the code is located here:

Setup python-gitlab

pip install python-gitlab
vim $HOME/.python-gitlab.cfg

default =

url =
private_token = xxx
api_version = 4
ssl_verify = true

Simple query

#!/usr/bin/env python

import gitlab


gl = gitlab.Gitlab.from_config('', ['/Users/michi/.python-gitlab.cfg'])

print("Project attributes required for creation")

project = gl.projects.get(PROJECT_ID)
print("All project attributes")

print("Project attributes matching access_level")
for a in project.attributes:
    if "access_level" in a:


The last loop says the same, the pages_access_level is not there, but the feature is actually there and enabled.

Project attributes matching access_level

I’d say that I can reproduce the problem, but I don’t know if that’s a bug within GitLab’s API to not expose these settings. They clearly exist via the config form, as can be seen with Chrome’s dev console.

Let’s dig deeper in the code

The above list says, that we can e.g. control wiki_access_level.

grep -r pages_access_level .


grep -r wiki_access_level .

./lib/api/entities.rb:      expose(:wiki_access_level) { |project, options| project.project_feature.string_access_level(:wiki) }
./lib/api/helpers/projects_helpers.rb:        optional :wiki_access_level, type: String, values: %w(disabled private enabled), desc: 'Wiki access level. One of `disabled`, `private` or `enabled`'
./lib/api/helpers/projects_helpers.rb:          :wiki_access_level,

./doc/api/| `wiki_enabled` | boolean | no | (deprecated) Enable wiki for this project. Use `wiki_access_level` instead |
./doc/api/| `wiki_access_level` | string | no | One of `disabled`, `private` or `enabled` |
./doc/api/| `wiki_enabled` | boolean | no | (deprecated) Enable wiki for this project. Use `wiki_access_level` instead |
./doc/api/| `wiki_access_level` | string | no | One of `disabled`, `private` or `enabled` |
./doc/api/| `wiki_enabled` | boolean | no | (deprecated) Enable wiki for this project. Use `wiki_access_level` instead |
./doc/api/| `wiki_access_level` | string | no | One of `disabled`, `private` or `enabled` |

So, we’ve got a winner. The attribute is not implemented in the API entity.

Feature Request?

Well, actually, I’ve found issues already requesting that where I will link this topic too to raise awareness.

Merge Request?

When looking into an MR, I’ve found another example to learn from at

Let’s see how far my journey goes :wink:

Edit: Let’s try it.