Drew Blessing (9dc42dd3) at 18 Mar 04:38

... and 1 more commit

Drew Blessing (6a069418) at 18 Mar 04:37

This MR contains the following updates:

Package	Update	Change	MyDiffEnd
kramdown (source)	patch	2.5.1 -> 2.5.2	https://my.diffend.io/gems/kramdown/2.5.1/2.5.2

MR created with the help of gitlab-org/frontend/renovate-gitlab-bot

---

Configuration

📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻️ Rebasing: Whenever MR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this MR and you won't be reminded about this update again.

---

• If you want to rebase/retry this MR, check this box

---

This MR has been generated by Renovate Bot.

Drew Blessing (434490ba) at 17 Mar 21:04

... and 1 more commit

Drew Blessing (d95e63f5) at 17 Mar 21:04

This MR contains the following updates:

Package	Update	Change	MyDiffEnd
kramdown (source)	patch	2.5.1 -> 2.5.2	https://my.diffend.io/gems/kramdown/2.5.1/2.5.2

MR created with the help of gitlab-org/frontend/renovate-gitlab-bot

---

Configuration

📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻️ Rebasing: Whenever MR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this MR and you won't be reminded about this update again.

---

• If you want to rebase/retry this MR, check this box

---

This MR has been generated by Renovate Bot.

What does this MR do and why?

Adds prevent_editing_approval_rules boolean to the policy approval settings JSON schemas and the ApprovalSettings value object.

This is MR 1 of 5 — a data-layer only change with no enforcement behavior. It unblocks all other MRs.

Changes

File	Change
ee/app/validators/json_schemas/approval_policy_content.json	Add prevent_editing_approval_rules: boolean to approval_settings.properties
app/validators/json_schemas/scan_result_policy_project_approval_settings.json	Add prevent_editing_approval_rules: boolean to properties
ee/lib/security/scan_result_policies/approval_settings.rb	Add prevent_editing_approval_rules accessor method

Verification steps

1. Create a project

2. Go to Secure Policies

3. In the project, create an approval policy:

   approval_policy:
     - name: Prevent editing approval rules
       description: ''
       enabled: true
       actions:
         - type: require_approval
           approvals_required: 1
           role_approvers:
             - owner
             - maintainer
         - type: send_bot_message
           enabled: true
       rules:
         - type: any_merge_request
           branch_type: protected
           commits: any
       approval_settings:
         block_branch_modification: false
         prevent_pushing_and_force_pushing: false
         prevent_approval_by_author: false
         prevent_approval_by_commit_author: false
         remove_approvals_with_new_commit: false
         require_password_to_approve: false
         prevent_editing_approval_rules: true
       fallback_behavior:
         fail: closed
       enforcement_type: enforce
   

4. In rails console, verify that prevent_editing_approval_rules is persisted correctly:

   Security::Policy.last.approval_policy.approval_settings.prevent_editing_approval_rules # => true

Related

Part of #593362 Related to #588291

Changelog: added EE: true

What does this MR do and why?

Adds prevent_editing_approval_rules boolean to the policy approval settings JSON schemas and the ApprovalSettings value object.

This is MR 1 of 5 — a data-layer only change with no enforcement behavior. It unblocks all other MRs.

Changes

File	Change
ee/app/validators/json_schemas/approval_policy_content.json	Add prevent_editing_approval_rules: boolean to approval_settings.properties
app/validators/json_schemas/scan_result_policy_project_approval_settings.json	Add prevent_editing_approval_rules: boolean to properties
ee/lib/security/scan_result_policies/approval_settings.rb	Add prevent_editing_approval_rules accessor method

Verification steps

1. Create a project

2. Go to Secure Policies

3. In the project, create an approval policy:

   approval_policy:
     - name: Prevent editing approval rules
       description: ''
       enabled: true
       actions:
         - type: require_approval
           approvals_required: 1
           role_approvers:
             - owner
             - maintainer
         - type: send_bot_message
           enabled: true
       rules:
         - type: any_merge_request
           branch_type: protected
           commits: any
       approval_settings:
         block_branch_modification: false
         prevent_pushing_and_force_pushing: false
         prevent_approval_by_author: false
         prevent_approval_by_commit_author: false
         remove_approvals_with_new_commit: false
         require_password_to_approve: false
         prevent_editing_approval_rules: true
       fallback_behavior:
         fail: closed
       enforcement_type: enforce
   

4. In rails console, verify that prevent_editing_approval_rules is persisted correctly:

   Security::Policy.last.approval_policy.approval_settings.prevent_editing_approval_rules # => true

Related

Part of #593362 Related to #588291

Changelog: added EE: true

What does this MR do and why?

Preserve SAML identities in the PruneDeletionsWorker.

This means that SAML identities are preserved for users who are removed from a group via the dormant group users feature.

Ultimately, this is to solve #588829. In that issue, we will push SCIM membership removal upon user deletion into a background job using the Members::ScheduleDeletionService. This is the same service that we use during membership removal for dormant group users.

When memberships are removed during a SCIM request to delete a user, the SAML identity is preserved. When memberships are removed during dormant membership removal, the SAML identity is deleted. We believe this seems to be a minor error and can be changed - the SAML identity can be preserved in this case as well.

So in this MR, we will preserve the SAML identity during dormant membership removal, so that it will also be preserved when we use the same service during SCIM user removal.

References

• Issue: #588829
• Draft MR and discussion: !226577
• !121226
• See discussion in this thread: !226577 (comment 3153267791)

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.

Drew Blessing (86e02164) at 17 Mar 20:30

Current.organization will be set for all requests.

Drew Blessing (0b29b933) at 17 Mar 19:07

Drew Blessing (08a86c97) at 17 Mar 19:01

... and 2797 more commits

Drew Blessing (767884b2) at 17 Mar 18:46

... and 299 more commits

Drew Blessing (f0449b19) at 17 Mar 16:24

Drew Blessing (58ed989c) at 17 Mar 16:20

... and 293 more commits

@imand3r @ajaythomasinc To clarify, top-level groups are transferred from the default organization into a new organization. They are not promoted from a TLG to an organization.

After glancing quickly at the issue, MR and database structure here are my quick thoughts.

• Copy the member_roles and admin_roles when transferring to a new organization.
  • Are these roles always the same, or customizable per organization?
    • If they're customizable, then what we can do is copy them when transferring a user to a new organization. That way we're not breaking existing references and we have a solid reference for the role in the new organization.
• Transfer user_admin_roles and user_member_roles when the user transfers to a new organization. In my opinion, this makes sense even for admin roles which are instance level, because the records themselves refer to the user object, which is moving.

There may be other considerations but hopefully these ideas help.

Drew Blessing (f65ebbbe) at 17 Mar 15:17

... and 1 more commit

What does this MR do and why?

Clean up/follow-up to !225916 to remove the User helper method in favor of moving the check to policy.

References

gitlab-org#19424

Screenshots or screen recordings

Before	After

How to set up and validate locally

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.

@imand3r It makes more sense in the next MR. Here, we add a root controller for /admin or /o/:org/admin which will then route to the instance dashboard or organization dashboard based on access. Instance admin will end up at admin/instance while organization owners end up at admin/organization.

But instance admins can also view the org dashboard. And eventually, custom roles should be able to also - potentially depending on whether they have any organization custom roles? To be determined.