Alex Pooley (4508cdac) at 20 Mar 05:31

... and 1 more commit

Alex Pooley (fb7ea8cc) at 20 Mar 04:15

... and 2 more commits

Summary

• Lifts the Cells 1.0 temporary constraint that limited organizations to private visibility only
• Frontend form now offers both private and public visibility options
• REST API now accepts visibility_level as a create param and exposes it in responses
• GraphQL organizationCreate mutation now accepts an optional visibility_level argument
• Updates generated OpenAPI (v2 + v3) and GraphQL reference docs

Screenshots

Create organization form

Edit organization settings → Visibility

Test plan

• yarn jest spec/frontend/organizations/shared/components/new_edit_form_spec.js
• bundle exec rspec spec/requests/api/organizations_spec.rb
• bundle exec rspec spec/requests/api/graphql/mutations/organizations/create_spec.rb
• Manually visit organization creation form and confirm both public and private radio buttons are selectable

Alex Pooley (222e162d) at 20 Mar 03:27

... and 2 more commits

@rymai @smaglangit I answered in the ADR thread. I believe that things have moved on a lot since these discussions...

Oh, I just saw gitlab-org/gitlab!228030 (comment 3174913544) 😆

That discussion appears to be based off now obsolete context sorry.

@rymai The Organization level is equivalent to the self managed instance level. Visibility of a SM is determined by infra rules e.g. firewalling. The SM instance is either visible (public) or not visible (private).

Public Org can be seen by everyone.

Furthermore, if a public Org can not be seen by everyone then we can not replicate existing behavior for public projects.

I'm curious if you have a specific concern?

If we're moving a group directly into an isolated organization than I can see the need

@dblessing Yes, that's what I meant by "but as part of the isolation enablement process".

transferring groups into a non-isolated organization can happen outside a single transaction so we're not blocking other write actions.

I agree.

I think we're saying the same thing. I was speaking more towards the two workstreams / timing confusion that I think Chen was missing.

Here's my understanding of where we've landed:

@chen-gitlab Yep 👍 There's also another need when an Organization is transferred to another Cell. That can't happen until we have Isolated Orgs. I agree on the open question. There's some nuance depending on how we see the UX going with some of these things.

@ayufan can you please take another look? 🙇

!216754 (diffs) 👍

A bit more DRY.

Alex Pooley (cc8db74f) at 19 Mar 07:22

@chen-gitlab We have two streams related to this area currently, there's the recent and more important push to get non-isolated Organizations into production. Then a secondary older push towards isolated Organizations later in the year.

If the consensus is that TLG-level read-only is no longer needed and we should scope this to Organizations instead, I'm happy to pivot.

TLG-level read only is required, but as part of the isolation enablement process. (secondary older push stream).

is there still a near-term need for namespace-level enforcement

No, but @rutgerwessels is working on enforcing isolation currently.

draft a revised/separate plan targeting Organization-scoped read-only

Regardless of timing, it's best to capture your thoughts while you have the context now.

I hope this helps clear things up?

Alex Pooley (0e88fdd5) at 18 Mar 06:36

Alex Pooley (305cd4f4) at 18 Mar 06:04

... and 17344 more commits

Alex Pooley (378e2b58) at 18 Mar 05:15

@ayufan I've memoized the endpoint id for re-use. Can you please take another look?

Alex Pooley (33e3fa24) at 17 Mar 06:36

Alex Pooley (b415606c) at 17 Mar 04:43

Alex Pooley (4f38aa06) at 17 Mar 04:43

... and 1 more commit