@rutgerwessels looks like there are some merge conflicts, but other than that it looks good

What does this MR do and why?

This MR reverts !221493

In !221493, I introduced a change that would stub Current.organization for all requests specs (Grape specs). But that can mask errors because the actual code does not always have a Current.organization: it needs to be enabled per API.

So we need this disable this for request specs until #558544 is delivered.

specs in spec/request/api/graphql will still have the Current.organization available because GraphQL is a Rails controller and Rails controllers always have Current.organization configured

The most important change is in spec/support/shared_contexts/current_organization_context.rb.

References

• #558544
• !221493

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.

Thanks @Andyschoenen I have made the changes 🏓

Great catch ✅

Arpit Gogia (b3b2b142) at 20 Mar 09:18

... and 530 more commits

@hbakergitlab thanks for the review, I have followed up 🏓

Arpit Gogia (f16fb158) at 20 Mar 06:12

... and 740 more commits

@GitLabDuo this spec does check for integrity between the fragment and the file: !227622 (diffs)

This file has been generated using Duo and reviewed by humans.

Do you mean we will be specifying an access token in the security policy? 🤔

Apologies, nothing changed. I forgot to mention that this file has been generated using Duo 😅

This will violate the specification, we do want to different allow/deny rules to co-exist in the same configuration.

LGTM @timmccarthy

What does this MR do and why?

This MR adds missing belongs_to associations to Design Management models to support organization transfer functionality.

Models updated:

• DesignManagement::Action
• DesignManagement::Design
• DesignManagement::DesignUserMention
• DesignManagement::Version

Also updates all_models.yml to include namespace for design and actions sections.

This is part of a series of MRs split from !227325 to add missing associations across ~70 models.

MR acceptance checklist

Please evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.

Related MRs

This MR is part of a series splitting !227325 into smaller domain-specific changes:

Domain	MR
Geo models	!227739
Compliance & Audit Events	!227789
Merge Requests	!227790
Alert Management	!227791
Clusters	!227792
Design Management	!227793
Issues (Core)	!227794
Issues (Related)	!227795
Notes & Suggestions	!227796
Deployments & Misc	!227797
Analytics & Misc CE	!227798
EE Approval Rules	!227799
EE Boards & Epics	!227800
EE On-call	!227801
EE Misc	!227802

Thanks @adil.farrukh for the feedback and for sharing the entities used by Dependency Proxy. We will use a similar pattern when writing the code for this work item.

The concerns I had, and I see they are actually done differently for Dependency proxy is how the JWT has a dedicated audience for the end service it's going to be consumed by (Dependency Firewall vs container registery).

I agree and understand that the audience is different. However, creating a different token with dependency_firewall as the audience might put additional burden on the CR and download/upload operations since it would request the token from the Rails platform.

We are planning to add feature enablement within the existing JWT (#593143), so that could implicitly specify that the JWT is allowed to access the Dependency Firewall feature.

We can check with groupcontainer registry but I think Dependency Proxy uses a similar pattern to this, so the core idea works.

@jaime calling on you (again) for feedback on another aspect of the Container Registry <> Dependency Firewall communication 😅

please bear with us on response times as well, we have are hands full as it is 🙇

@jaime sure 🙇

Another thing that came to mind, has your team considered the CTO Modular GitLab notes?

Thanks for sharing, I will give this a read. The reason so far to keep the Dependency Firewall in the monolith is since it will also be used for the Package Registry and it integrates with the current Security Policies framework.

@Andyschoenen since you work on Security Policies, could you help review this as the backend maintainer?