Project Visibility, project features, permissions settings API

#1

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!

#2

Hi,

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.

Cheers,
Michael

#3

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.

#4

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?

#5

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:

55 AM
55 AM1646×2060 291 KB

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

>>> attrs = pa.gl.projects.get_create_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.

#6

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, https://python-gitlab.readthedocs.io/en/stable/gl_objects/users.html#user-custom-attributes

Pages

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.

./app/models/project_feature.rb

  STRING_OPTIONS = HashWithIndifferentAccess.new({
    'disabled' => DISABLED,
    'private'  => PRIVATE,
    'enabled'  => ENABLED,
    'public'   => PUBLIC
  }).freeze

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

Cheers,
Michael

#7

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

09 AM
09 AM1360×854 85.6 KB

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!

#8

Hi,

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: https://gitlab.com/dnsmichi/api-playground

Setup python-gitlab

pip install python-gitlab

vim $HOME/.python-gitlab.cfg

[global]
default = gitlab.com

[gitlab.com]
url = https://gitlab.com
private_token = xxx
api_version = 4
ssl_verify = true

Simple query

#!/usr/bin/env python

import gitlab

PROJECT_ID=15013654

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

print("Project attributes required for creation")
print(gl.projects.get_create_attrs())

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

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

Tests

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
builds_access_level
snippets_access_level
repository_access_level
issues_access_level
merge_requests_access_level
wiki_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.

29
291020×598 78.2 KB

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 .

vs

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/projects.md:| `wiki_enabled` | boolean | no | (deprecated) Enable wiki for this project. Use `wiki_access_level` instead |
./doc/api/projects.md:| `wiki_access_level` | string | no | One of `disabled`, `private` or `enabled` |
./doc/api/projects.md:| `wiki_enabled` | boolean | no | (deprecated) Enable wiki for this project. Use `wiki_access_level` instead |
./doc/api/projects.md:| `wiki_access_level` | string | no | One of `disabled`, `private` or `enabled` |
./doc/api/projects.md:| `wiki_enabled` | boolean | no | (deprecated) Enable wiki for this project. Use `wiki_access_level` instead |
./doc/api/projects.md:| `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.

Cheers,
Michael

#9

I was too busy, luckily someone else implemented it for 12.8 :slight_smile:

Cheers,
Michael