Allow admins to make specific project services unavailable

Description

An administrator may wish to disable the use of certain project services globally, or for a particular group or project. In particular, the "terminal websocket" support in !7690 (merged) may need disabling in some contexts.

Proposal

Extend service templates so the administrator can make some of them unavailable to project owners.

Stretch: Allow their use to be restricted to a whitelist or blacklist of names (by user, group or project).

Links / references

changed title from Allow admins to disable project services to Allow admins to make specific project services unavailable

@nick.thomas I need this proposed feature as well, minus the "Stretch" capability. Are you imagining roughly a new enabled boolean on the Service model that is only relevant when template is true?

As an admin, I want to be able to quickly disable many or all of the project features without drilling into each template, and ideally I want to be able to control this via API as well.

Would a merge request be accepted for this capability? I am interested in working on this, but I assume it needs some design first. Please advise. Thanks!

@ryehle we've had no input from product yet. Terminal websocket support - the main driver for this issue when I opened it - has gotten a special-case method of disabling it globally, so this isn't required for that any more. However, I still think this could be useful.

/cc @mydigitalself

@nick.thomas @ryehle I'm fine with it from a product standpoint, I just think it may need some UX input, but isn't a priority right now for our design team.

We are doing some work on Integration Settings in general https://gitlab.com/gitlab-org/gitlab-ce/issues/34059

@tauriedavis perhaps you could consider what Service Templates look like in the Admin area as the design is pretty much the same as the Project Integration Settings. Having a way for an Admin to completely disable an integration could be something to consider as part of the design.

@mydigitalself Given that we are likely a ways off from getting a design for this feature, I'm wondering what contribution I could make in the interim that would get my team by. We are currently running custom code that entirely hides the Project Services option in Integrations since we don't have a way to pick and choose those that are exposed. Possibilities that would work for us:

• Disable ALL project services on the instance. This would be a single checkbox (in Application Settings I presume). When enabled, the Project Services section doesn't appear on the project Integrations page. I don't have a preference as to whether enabling this option also disables the Service Templates for admins. I'd be inclined not to touch that.
• Low bar support for what we describe above. Add a "Disabled" column to the Service Templates page that allows an admin to select the services that should not appear on the Integrations page.
• Open to other suggestions... Please advise. Thanks!

@ryehle I'm loathe to do anything with the overall UI of that page (e.g. your second option) as it's going to change quite soon with the work we are doing trying to overhaul integrations.

I know it's a bit laborious, but do you think it's a massive stretch to change the active checkbox on an integration into a drop-down, which would be:

• Disabled
• Inactive
• Active

For reference, I'm referring to this page on each integration:

The default being Inactive.

You could then go through all of the ones you don't want people to change and change them to Disabled. If an integration is Disabled then it doesn't appear in the list to choose in a project.

@tauriedavis do you think that would be an ok interim solution for Accepting Merge Requests ?

Yeah, I think so. Only admins would see the option for disabling the integration.

There should be some help text along with it: Disabled integrations can only be managed by project admins. They will not be displayed in the integrations list for other project members.

It would also be good to show some indication on list that is disabled so admins can easily tell.

Thanks @mydigitalself / @tauriedavis. @mydigitalself are you envisioning this checkbox becoming a dropdown only for Service Templates, or would it be a dropdown with only two options for the actual instances in projects? @tauriedavis agree only admins would see the option for disabling the integration, but to clarify, I think we mean site admins, not project admins. Integrations would be disabled on the instance, not per project. Agree we would ideally have an indication on the Service Templates list to quickly see which are disabled and which are available for projects. @mydigitalself didn't want to touch that page, but perhaps a read-only column showing the status of Disabled/Inactive/Active would be ok??

changed milestone to %Next 3-6 months

moved to gitlab#7411

Hey!

GitLab is moving all development for both GitLab Community Edition and Enterprise Edition into a single codebase. The current gitlab-ce repository will become a read-only mirror, without any proprietary code. All development is moved to the current gitlab-ee repository, which we will rename to just gitlab in the coming weeks. As part of this migration, issues will be moved to the current gitlab-ee project.

If you have any questions about all of this, please ask them in our dedicated FAQ issue.

https://gitlab.com/gitlab-org/gitlab-ee/issues/13855

You can also find more information here:

• https://gitlab.com/gitlab-org/gitlab-ee/issues/13304
• https://about.gitlab.com/2019/08/23/a-single-codebase-for-gitlab-community-and-enterprise-edition/

Frequently Asked Questions

For an up to date list of questions and answers, please take a look at https://gitlab.com/gitlab-org/gitlab-ee/issues/13855

What will we do with the repository names?

https://gitlab.com/gitlab-org/gitlab-ee/ will become https://gitlab.com/gitlab-org/gitlab, and https://gitlab.com/gitlab-org/gitlab-ce will become https://gitlab.com/gitlab-org/gitlab-foss.

Why rename gitlab-ce to gitlab-foss?

Using "gitlab" and "gitlab-ce" would be confusing, so we decided to rename gitlab-ce to gitlab-foss to make the purpose of this FOSS repository more clear

I created a merge requests for CE, and this got closed. What do I need to do?

You will need to create a merge request at https://gitlab.com/gitlab-org/gitlab-ee/. This link will eventually redirect to https://gitlab.com/gitlab-org/gitlab.

How does the licensing work in this new setup?

Everything in the ee/ directory is proprietary. Everything else is free and open source software. If your merge request does not change anything in the ee/ directory, the process of contributing changes is the same as when using the gitlab-ce repository.

Will you accept merge requests on the gitlab-ce/gitlab-foss project after it has been renamed?

No. Merge requests submitted to this project will be closed automatically.

Will I still be able to view old issues and merge requests in gitlab-ce/gitlab-foss?

Yes.

How will this affect users of GitLab CE using Omnibus?

No changes will be necessary, as the packages built remain the same.

How will this affect users of GitLab CE that build from source?

Once the project has been renamed, you will need to change your Git remotes to use this new URL. GitLab will take care of redirecting Git operations so there is no hard deadline, but we recommend doing this as soon as the projects have been renamed.

Where can I see a timeline of the remaining steps?

https://gitlab.com/gitlab-org/gitlab-ee/issues/13304

Will community contributions submitted to the new "gitlab" repository be available in the new gitlab-foss repository?

Yes, these changes will be synced to gitlab-foss automatically, several times per day.

locked this issue