Hi,
Context:
This improvement proposal is relevant in the context of enrollments with multiple organizations. As the number of internal projects in an organization grows - and therefore exports in the data connections to external/internal systems - more users require “Expand access”.
Once a user is granted “Expand Access” in an internal project, it automatically gains the ability to propose a PR which unmarks the OrgMarking - and in any code repository. Moreover, he can self-approve the PR provide he has both Manager role and Expand Access.
In my understanding, an export to an internal database and stop requiring OrgMarkings in code repositories is different in nature and raises different risks depending on the project access groups constellations.
If the two below were available:
- “Expand access in data connections” and “expand access in code”, and
- Additional controls in the “Security Approvals” of code repositories,
Platform admins wouldn’t have to rely on the due diligence of the developers and could standardize data exchanges across organizations through project archetypes. This would also improve audibility of data exchanges in big enrollments.
Why we cannot do it today:
To my best knowledge, scoping removal of OrgMarkings through code cannot be done today. To run an export in a data connection, the user is required to have expand access plus remove marking permissions in case any marking is involved.
Workarounds:
There are no workarounds that I am aware of. One would have to rely on minimizing number of group members in shared projects, and there’s no eagle-eye view where the OrgMarking is being removed through changes in code.
Benefits::
-
Who can expand access through code changes?
Clear separation of concerns (users who can remove an OrgMarking through code from users who are doing exports potentially to other internal systems) -
Where “Expand Access” through code repositories takes place?
Security approvals with a toggle for OrgMarkings would provide a granular control similar to data connections. -
What Organization can be removed?
This would provide the final level of granularity.
Having all these ingredients, would allow to standardize data exchanges across organizations with minimal operations in multi-tenancy enrollments. Other alternative would be to leverage the “Approvals workflow”. This however would require administrators time and introduce overheads on something that can be standardized. I am leaving this topic to your product development team, but I hope there’s enough food-for-thought in this improvement proposal.