Design:indicates user they are reaching the limits

added to epic &8084

@cam.x, Please add a group or category label to identify issue ownership.

You can refer to the Features by Group handbook page for guidance.

If you are unsure about the correct group, please do not leave the issue without a group label, and refer to GitLab's shared responsibility functionality guidelines for more information on how to triage this kind of issue.

This message was generated automatically. You're welcome to improve it.

changed the description

added UX groupsecurity policies labels

added Category:Security Policy Management devopsgovern sectionsec labels

changed milestone to %16.10

@cam.x - please see the following guidance and update this issue.

	1 Error
	Please add typebug typefeature, typemaintenance and optionally a subtype label to this issue.

If you do not feel the purpose of this issue matches one of the types, you may apply the typeignore label to exclude it from type tracking metrics and future prompts.

This message was generated automatically. You're welcome to improve it.

mentioned in epic &8084

added 3 designs

Hi team, @gitlab-org/govern/security-policies-frontend , @gitlab-org/govern/security-policies-backend , @g.hickman

As usual, I put the design in the description and video walkover.

Video
Figma

cc: @gitlab-com/gitlab-ux/secure-govern-ux

I like this idea. Simple and easy to understand. I do not see any technical challenges with this, although this limit will be configurable in the future to allow self-managed customers to modify it.

FYI: @gitlab-org/govern/security-policies-frontend , @gitlab-org/govern/security-policies-backend , @g.hickman @rdickenson

I decide to move the new policy(dropdown button) out of this design. Because the user might not find the choose policy type page additional steps, we need to confirm the problem first. So the solution will be like in the description now:

Show the message in the choose type page; they have reached the limit
Add a button to allow users to create disabled policy
Enable is disabled if the user has reached the limits

although this limit will be configurable in the future to allow self-managed customers to modify it.

@alan Thank you for the info! Could you tell me more? So, for self-manage, they won't have a limit from us, which means they won't reach technical capacity. Or do they need to assess how many policies they can handle? If yes, how would users know how many policies they can have?

Great questions, @cam.x! With Add application setting for limit of merge requ... (!143849 - merged) we have added ability to modify a limit of Merge Request Approval Policies by setting application setting. With this change admin of instances can modify that limit to up to 20 MR Approval Policies. This value is respected on frontend as well, so we simply allow that. As of now I do not believe we have any indicator of how many policies they can handle.

Maybe a silly question, so apologies... why do we have this limit? I initially thought it was a money thing, like we up charge for X more policies, but that doesn't sound like it's the reason.

@cam.x @g.hickman

@jmandell, it's related to potential performance issues. We are working now on Refine Policy Application Limits (&8084) to better understand what is possible, although we need to have these limits for now to not introduce any performance problems on GitLab.com or self-managed instances.

@alan Oh, that's interesting. If it's a performance limitation on our end, then I'm now wondering why we're providing a setting for users?

cc/ @cam.x @g.hickman

@jmandell, this is instance setting, so only instance admins will be able to modify it for their instance. We would like to use this setting to check the impact on GitLab.com by changing the limit to 10 at some point, however we also want to add customers ability to configure it on their self-managed instances differently, as the impact on performance on self-managed instance is much lower.

@alan Thank you for the information. I think the current solution is scalable; when we have the settings, we need to remember the following:

Who can change it since it is related to instance settings
Where the setting should be
Provide user guidelines on which limitation is the best.

Do we already have an issue with the settings?

@cam.x the settings are already implemented, it's part of the ApplicationSettings. The setting is security_approval_policies_limit. I think we should eventually extend the guidelines around this limit, right now it defaults to 5 to match the limit used before statically in the code. The maximum is 20 at the moment but we will need to first gradually increase it on GitLab.com to measure the impact and provide proper guidance.

@mcavoj From the doc, I need help finding the guidelines, like default is 5, max is 20. Should we add more details to the doc? @rdickenson

And is this setting reflected anywhere in the UI? (I mean for self-manage, is the code the only place where they can change those settings?) Do you know?

@cam.x there's no UI, it can be only changed via API at this point. The currently set value is reflected in the policies list when this limit is reached in the warning that we already show. I opened MR to add more details to the docs: !146178 (merged)

I also added a different copy for self-managed users.

I don't think user will change it very often, so it should be good to have it in code rather than UI for now.

@cam.x I think this all works. Let me know if there are any questions/concerns for me.

@alan We have a backend spike, we have a design. Any further breakdown needed from your view? Any concerns with the plan here?

Thanks @g.hickman! I'll leave this question for @mcavoj to confirm what's missing from both frontend and backend side here.

@g.hickman @alan No further questions, design has marked as done and information are in epic now.

@g.hickman @alan thanks! frontend looks straightforward, no concerns there

For backend, although not relevant for the design issue, but we should probably add a check of the limits on push of policy.yml as mentioned in &8084 (comment 1781403107). The issue Prevent from creating more than X policies for ... (#411854 - closed) seemed relevant for that, so I went ahead and updated the implementation plan to mention the push check. Happy to move it into a separate issue if you think it doesn't fit in there