@Bixilon I don't think we want to accept this change to support your custom use case. The members finders are used elsewhere internally in the code base without passing a user argument and making this change will be much more involved than what you have here.
We cannot simply remove this permission because it is a valid permission used for authorization checks.
@ajaythomasinc This issue is not related to the column but to ensure that the organization ID for gPATS is updated when users are transferred to a different organization.
@ajaythomasinc This issue is not related to the column but to ensure that the organization ID for gPATS is updated when users are transferred to a different organization.
Thanks for the clarification @dblessing that is helpful. One question I have about the TLG transfer is related to users. What if a user is a member of more than one TLG?
For example, if a user is a member of TLG A and B and group A is transferred to organization X would that mean that users would not longer have access to group B since they are now in a different organization?
The way the MR is written I think for the member roles we shouldn't use user records to figure out what to move. Member roles are either instance-level (for self-managed or admin roles) or namespace-level (for saas). So if a TLG is transferred to an organization in SaaS then we should just use MemberRole.by_namespace(transferred_namespace_id) to move the member roles. For self managed maybe we would need to copy the member roles/admin roles into the organization since there may be users assigned to those roles that are not associated with the transfer. Does that make sense?
This MR moves the permissions for code repository rules. These permissions are explicitly listed and granted directly to maintainer roles and users with the admin push rules custom role rather than through the intermediary permission. The change moves these permission definitions from the policy files into a centralized configuration file, making the permission system more organized and easier to maintain.
| Before | After |
|---|---|
Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.
Ian Anderson (40e8ee79) at 18 Mar 03:48
Ian Anderson (cfbce70c) at 18 Mar 03:48
Merge branch 'dlrussel/move-ee-role-permissions-to-yml' into 'master'
... and 1 more commit
This MR reorganizes how user permissions are managed in the system by moving permission definitions from declarative policy files into configuration files. Instead of having permissions scattered throughout the codebase, they're now centrally defined in YAML configuration files for each role.
This restructuring makes the permission system more maintainable and easier to understand, as all permissions for each role are now clearly listed in dedicated configuration files rather than being embedded in complex policy code.
| Before | After |
|---|---|
Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.
This MR reorganizes how user permissions are managed in the system by moving permission definitions from declarative policy files into configuration files. Instead of having permissions scattered throughout the codebase, they're now centrally defined in YAML configuration files for each role.
This restructuring makes the permission system more maintainable and easier to understand, as all permissions for each role are now clearly listed in dedicated configuration files rather than being embedded in complex policy code.
| Before | After |
|---|---|
Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.
Related to !227784 (merged)
@dlrussel Can you take the review for this small cleanup MR?
Remove unneeded policy conditions
Since the IssuablePolicy delegates to the container we do not need to specifically check role access when enabling mark_note_as_internal since that is already enabled by the appropriate roles.
| Before | After |
|---|---|
Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.
Related to #593261
Ian Anderson (1ee417d4) at 17 Mar 23:12
Remove unneeded policy conditions