Organizations may want to control what roles have access to be able to cancel a pipeline. Previously, anyone who could run a pipeline could also cancel a pipeline. Now, a project Maintainer will be able to select a setting that restricts pipeline and job cancellation by roles from the GitLab project settings. For more information view our documentation.
Proposal
Add radio buttons for:
Maintainer roles and up
Developer roles and up
No one
By default this is checked to Developer roles and up
This will be the frontend issue to track UI changes and necessary changes on the front end.
This page may contain information related to upcoming products, features and functionality.
It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes.
Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.
@jreporter@carolinesimpson I noticed this is blocked by the BE which is scheduled in 16.5. Should this issue be bumped to 16.6? Or do we feel the BE will completed early in the milestone?
@mfanGitLab, @jreporter, @pburdette, I see we wrote about an alternative design approach with no checkbox and a dropdown with maintainer and above, developer and above or no one. It seemed a little simpler to me, since we don't have to guess about what off means.
@allison.browne@jreporter@mfanGitLab Given the BE is not complete and we have a little time. Could we maybe get UX opinion on this one? And a quick mockup?
I tend to agree a checkbox seems like the better approach here.
But, I think we would want to support this feature in GitLab Premium as it addresses a common team use case for CI Adoption so, that is one conflicting barrier that I don't think would be tenable I will list it as a workaround though @hsutor
Ahh, @jreporter, you bring up a good point about tiering. I guess that kills it for customizable roles! Allison - customizable roles is GitLab Ultimate only.
@veethika, I think we also have to think about the UI around cancellation.
Does the button get hidden or disabled? Or is it clickable and there is an error that appears? There may be some small backend changes depending on what we want.
edit: I think the answer is that it just behaves how it usually would if the cancellation is not available.
@allison.browne in this case the button will go away since users are going ahead and checking this box to disallow a role from performing an action. In such cases we usually always hide.
For the pipeline entity there was already a field specific to cancellation(which was backed by update_pipeline but I changed it to use cancel_pipeline) so I don't think we need any changes to showing and hiding the cancel button on pipelines but it might be worth auditing any pipeline and job cancel button locations during the work :)
I bumped this weight up to a 3 initally after seeing the designs and the dynamic multi-select searchable dropdown. But actually I don't think this is feasible at the moment. I think we should simplify the designs and bump the weight back down.
All general pipeline settings are in HAML app/views/projects/settings/ci_cd/_form.html.haml
Which use a pattern of Save changes then all settings are updated. To build this out to these design specs we would need to inject a Vue app into the mix, which isn't really the best idea right now.
For these reasons...
We don't have the setting in GraphQL yet
If we had the setting, it would be click the field, make API call, field is updated. And we shouldn't inject that into the existing form.
What I think we should do now vs the future.
Now
Simplify these designs by adding one checkbox for enabling the setting. Then either a simple select field or more checkboxes.
Limit pipeline cancelation permission
Maintainers and up
Developers and up
No one
Future
Rebuild the General pipeline settings page to be a Vue/GraphQL app. Perks: easier to maintain and gives us the ability to build more complex designs that follow the design system. Also have the ability to toggle all setting values in GraphQL.
@veethika@allison.browne Okay I tested a few different UX flows and I think this one makes the most sense for now.
We have a default role here of developer so the radio would default to Developers and up then a user can change the value to any other roles. I tried the checkbox flow but it was odd since it didn't feel like we needed to enable anything since a value is already set for the developer role.
WDYT? I can move forward with this and we can iterate on it later.
EDIT: I also think it makes sense to show the Developers and up radio button selected by default so users can know exactly who has permissions.
Yeah I would agree with payton here. I think we could either do 3 radio buttons or 2 radio buttons and the checkbox. Enabling Developer roles and up(the default) creates no change to the current behavior.
Given that I've verified this on staging.gitlab.com today, I will be preparing for a global production rollout to gitlab.com tomorrow starting at 2:00 PM Tuesday, Coordinated Universal Time (UTC). If all goes to plan, this will happen incremental with a schedule like:
25% of projects at 2PM UTC (9AM EST)
50% of projects at 4PM UTC (11AM EST)
75% of projects at 6PM UTC (1PM EST)
100% of projects at 8PM UTC (3PM EST)
1
Jackie Porterchanged the descriptionCompare with previous version