Affecting customer https://github.com/sourcegraph/accounts/issues/3 and https://github.com/sourcegraph/accounts/issues/580.
Customer workflow is such that a Sourcegraph admin and an application owner share a batch change; the Sourcegraph admin creates the batch change, writes the spec, and executes it server-side, then they share the preview with the application owner (who is not a Sourcegraph admin) to apply and take over ownership to track to merge. However, today, this workflow is not possible. Regardless of where a batch change is created, be it in a user namespace or an organization namespace, only the batch change creator or a Sourcegraph admin can apply it. For organization namespaces, this is a bit counterintuitive and likely is just a reflection of our lack of investment into organizations due to the longterm plan to replace them with "teams".
As a high impact short term solution, then, we can unblock this customer by adding a setting to change how batch change ownership works in organizations. The setting would enable batch changes in organizations to be administered by their creator, an admin, OR another member of the organization. This wouldn't interfere with an eventual migration to entity-based controls for RBAC or teams and could be guarded behind a setting for organizations which would be disabled by default.
To complete this would involve:
- Adding new organization setting for "all members are batch changes admins", which is default off
- Exposing setting in the org settings UI
- Adding new auth check like
CheckSiteAdminOrSameUser that also checks org membership, such as CheckSiteAdminOrSameUserOrOrgMember, which takes an org id and also passes if the currently-authenticated user is a member of the org with that id
- For batch change administration operations such as apply, close, and delete, which currently employ
CheckSiteAdminOrSameUser, if the batch change belongs to an org and the new org setting is enabled, check CheckSiteAdminOrSameUserOrOrgMember instead
- Adding tests to ensure existing behavior is preserved when setting is off, new behavior is enabled when setting is on
Affecting customer https://github.com/sourcegraph/accounts/issues/3 and https://github.com/sourcegraph/accounts/issues/580.
Customer workflow is such that a Sourcegraph admin and an application owner share a batch change; the Sourcegraph admin creates the batch change, writes the spec, and executes it server-side, then they share the preview with the application owner (who is not a Sourcegraph admin) to apply and take over ownership to track to merge. However, today, this workflow is not possible. Regardless of where a batch change is created, be it in a user namespace or an organization namespace, only the batch change creator or a Sourcegraph admin can apply it. For organization namespaces, this is a bit counterintuitive and likely is just a reflection of our lack of investment into organizations due to the longterm plan to replace them with "teams".
As a high impact short term solution, then, we can unblock this customer by adding a setting to change how batch change ownership works in organizations. The setting would enable batch changes in organizations to be administered by their creator, an admin, OR another member of the organization. This wouldn't interfere with an eventual migration to entity-based controls for RBAC or teams and could be guarded behind a setting for organizations which would be disabled by default.
To complete this would involve:
CheckSiteAdminOrSameUserthat also checks org membership, such asCheckSiteAdminOrSameUserOrOrgMember, which takes an org id and also passes if the currently-authenticated user is a member of the org with that idCheckSiteAdminOrSameUser, if the batch change belongs to an org and the new org setting is enabled, checkCheckSiteAdminOrSameUserOrOrgMemberinstead