Add a button (or some other action) to errors in the error table within GitLab that allows someone to open an issue with an information about the error in it.
The MVC could be an issue with a title and description the same as the Sentry error with a link to the error in Sentry. Further iterations should include a more detailed summary, embedded stack trace, etc.
We should consider what issues look like when they are created from Sentry into GitLab. The style and functionality should match. It is ok if this happens in two milestones.
WIP design
Short-term, single "add issue" button
Tooltip for hover state
Permissions and Security
Documentation
Testing
What does success look like, and how can we measure that?
What is the type of buyer?
Links / references
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.
Your proposal makes sense to me. Posted first thoughts for this as part of #32464 (closed) - essentially, I'm thinking we can add a button to "create an issue" within the list view (ie, the green "add issue" icon):
We would have to further detail the flow here but, essentially, the functionality would be similar to what's on the current Security Dashboard.
@ameliabauerly Looks great. I am participating in the discussion for the design review over on #32464 (closed), so I won't confuse everyone and split the discussion across two issues! We can update this issue once we have come to consensus on designs.
Cool, thanks! I have a few comments/questions specific to this issue. I will add them in new threads below. In the mean time, though, since I have them to hand, I'll add the latest version of where we're at from #32464 (comment 227656260).
In this issue, our focus would be on adding the second and third views shown in the table below:
In looking around our issue list, I found #33417, which appears to be an issue opened by a bot from Sentry. Here's how it looks when the error issue is created:
My assumption is that the bot that created the issue automatically added in the title, the link to the Sentry error, and the small code block. I'm thinking the link to the related support ticket was added in afterwards.
@deandre, since it looks like you edited the description on #33417, can you confirm a few details for me?
What information was automatically pre-populated when the issue was created from Sentry (assuming it was the title, link to the Sentry error and the small code block)?
Did you add in the section called "Related support tickets (internal)" - or was that also automatically added when the issue was created?
What information was automatically pre-populated when the issue was created from Sentry (assuming it was the title, link to the Sentry error and the small code block)?
That's correct. Here's how it looks:
Did you add in the section called "Related support tickets (internal)" - or was that also automatically added when the issue was created?
@sarahwaldner - I spotted the above in the description. Wondering if this should be a separate issue, as it isn't specifically related to the primary flow here, which I believe is, creating an issue directly from the error list view?
@ameliabauerly Yes I agree it should be a different issue! I have this issue opened which will capture work for automatic creation of GitLab issues based on error alerts at the endpoint. I've removed that line from the description of this issue.
Based on #33156 (comment 227943966), it does appear that #33417 is an example issue created from the Sentry UI. As a FYI, the "related support ticket" section was manually added after the issue was created.
When users opt to create an issue from the Sentry UI, they are required to select a repository (which I believe is actually a project), add in a title and a description. They can also optionally add in labels and assignees as part of this flow.
As a first pass, it seems like we could follow a similar path in the GitLab UI, but automate much of the process: the user clicks a button to create an issue, an issue is created in the same project they are working in (ie, whichever project they are viewing the Error Tracking list view in). The created issue is automatically populated with a title, a description, and a link to the Sentry error. Essentially, we could create something similar to the following, just by clicking a button:
In this example screenshot, though, the code block was manually entered in Sentry as the "description." If we pull what I believe is the error description from Sentry, we'll instead have a sentence like: "13:CreateRepositoryFromURL: clone cmd wait: exit status 128" rather than a chunk of code. So, if we build the issue automatically, it will have less content than the issue created from Sentry. But, it will be created more automatically. That feels like the trade-off here.
Longer term, we may want to think about a more robust interaction here. Perhaps clicking the "create issue" button would prompt a modal where users can add assignees, change projects, or even opt for associating the error with an existing issue instead. Unless you think we should plan for those longer term possibilities sooner rather than later?
I guess my question is: how much do we want to automate the issue-creation process here? The more automated it is, the simpler it is. But, users will also have less options for customizing the issue that's created until after it's created. Thoughts on this, @sarahwaldner, @nadia_sotnikova or @awhite-gl?
From Health call this morning, and a followup chat I had with @ameliabauerly (please correct/amend anything I've mis-explained).
If we have buttons in list view that take you away from that page, you lose context of the current list. I feel this a bit whenever I use the current "Resolve discussion in new issue" button. You go to create an issue, then clicking back you tend to lose a bit of context.
You also have buttons taking up space for every row, though they are only usable for a single item. We could work around this by making 'Create issue' from list view open a new tab to create the issue, which would allow easy multi-issue creation. But we can defer this until we know it's actually a real use-case (vs clicking detail view for an individual Error).
I think the Create Issue button on list view makes more sense once we add something like Amelia's Action Button Bar, as then there is a multi-row workflow from list view. e.g. "mute this, mute this, mark this as resolved, create an issue for this" etc
...there is a multi-row workflow from list view. e.g. "mute this, mute this, mark this as resolved, create an issue for this" etc
@psimyn - this workflow you are talking about, where someone goes through each list item and quickly mutes, resolves or creates issues for each item - this is also how I was imagining those buttons working. Does that describe how you currently work through the Sentry error list, line-by-line? Or do you instead just go through and bulk resolve/ignore items? (Or perhaps you do both?)
Also, @nadia_sotnikova brought up some great questions about button priority, and what would happen should users accidentally click the wrong button:
One thing I'm thinking about is whether there's a need to establish some type of hierarchy between those three buttons (Ignore, Resolve, and Create Issue)...For example, is Ignore a destructive action that would lead for the error to disappear, or can we view ignored errors by filtering the list? I'm asking because we don't want the user to accidentally delete an error that they meant to resolve. The buttons are very close to each other and have the same color. The destructive action needs to be de-emphasized. What action will be the most common? Will most errors be resolved? May be a good idea to somehow emphasize the primary action.
It seems like none of these actions (ignore, resolve, or create an issue) is destructive in that, if the error hasn't in fact been fixed, the error will keep recurring and a new error will show up in the list. However, to help address this concern, we could perhaps allow users to search for errors marked as resolved/ignored, or utilize a tab system at the top of the page where users can swap between all/ignored/resolved errors, similar to what we do for issues. Thoughts on either of these approaches?
In terms of the hierarchy concern: I'm wondering if all of these buttons need to be in each row. Sentry has resolved/ignore as bulk action buttons at the top of the page, and doesn't even allow users to create an issue until they view the detail page. Is there a "primary" action you are performing when you're looking through the errors? Could, perhaps, ignore/resolve errors be bulk actions only? I guess the short question is: which actions is it useful to have at the individual row level?
Since you actually use Sentry, would love any thoughts here, @psimyn
Does that describe how you currently work through the Sentry error list, line-by-line? Or do you instead just go through and bulk resolve/ignore items?
@ameliabauerly In my head I work through it line-by-line, if going through to clear out/triage errors. I usually only bulk-action a few items at a time maximum, such as any that can obviously be ignored (or are very old). Create Issue is usually likely to be a separate action, since then I have to go to another page, type stuff, add labels etc. If Create Issue just did it in the background and showed a Toast message of 'Issue created' then it might make sense. Then it kinda matches the workflow of the other items. Else I'd be happy to keep it as a separate thing.
It seems like none of these actions (ignore, resolve, or create an issue) is destructive in that, if the error hasn't in fact been fixed, the error will keep recurring and a new error will show up in the list
This is the case for Resolve, Ignore is designed to prevent this. They are all reversible actions though. We are changing the status of an Error, not deleting it.
How Sentry does things:
When you click Resolve/Ignore, an icon is added to the Error in the list. The item is not removed from the list until you refresh the page. This can prevent the effect of mis-clicks (if you accidentally clicked ignore you can toggle it back).
To view Resolved/Ignored errors there is a sidebar with filters
Ignore/Resolve can either be toggled again from the bulk actions, or you can click through to Error Detail page for a resolved/ignored error
For the MVC, are we also going to implement the filtering options? For example, are we going to default to filtering by unresolved and allow to view all errors? If so, we need to figure out a way to visually show resolved or ignored errors in the list.
I usually only bulk-action a few items at a time maximum, such as any that can obviously be ignored (or are very old). Create Issue is usually likely to be a separate action, since then I have to go to another page, type stuff, add labels etc. If Create Issue just did it in the background and showed a Toast message of 'Issue created' then it might make sense. Then it kinda matches the workflow of the other items. Else I'd be happy to keep it as a separate thing.
It'd be great to do a little research on what this workflow looks like for several different people. To me, it seems like:
If the workflow includes processing error line-by-line, then having all error specific action buttons on each line makes most sense. Since none of the actions are destructive,
I'm not worried about de-emphasizing any of the buttons.
One thing I'm not sure about is the "i" button. Each line item is a link that our user can click on and see extra details. Do we really need the "i" button? It also seems to serve a different purpose compared to "ignore" or "create issue". The latter two perform a major action while "i" is meant to open the extra information page. I'd either get rid of the "i" button or place it next to the error link (where the external link symbol used to be). What do you think?
If we could automate the issue creation to the point where the user doesn't have to break their flow and go to the new issue to add critical information, that'd be great. Creating an issue behind the scenes and providing a toast notification would work, however it can make things worse if we fail to include all the necessary information in that issue. In that case, the user will be forced to break their flow, go find the issue, etc. For the MVC, maybe we could allow for manual issue creation, and once we have enough data to see what information is critical, we could automate it.
Create Issue is usually likely to be a separate action, since then I have to go to another page, type stuff, add labels etc. If Create Issue just did it in the background and showed a Toast message of 'Issue created' then it might make sense.
I was thinking it would be the latter case (if possible): that the create issue button within each table row would automatically create an issue without the need for further user interaction. It could, for instance, pull the error title and description and automatically create an issue within the same project (and perhaps open the new issue in a separate tab, so users can additionally add labels or assignees as needed). So, users wouldn't need to fill out a form to create an issue, as they currently do in Sentry, which would hopefully streamline the process of creating an issue from an error in GitLab.
But, I think the outstanding question is whether users would ever know they need to create an issue just by looking at the list view of the error. This is something we'll likely need to validate. From our discussion last week (and Simon's comments above), it seems like creating an issue from the error detail page is a more likely flow.
For the MVC, are we also going to implement the filtering options? For example, are we going to default to filtering by unresolved and allow to view all errors? If so, we need to figure out a way to visually show resolved or ignored errors in the list.
From the way discussions are shaping up thus far, it sounds like the MVC won't include buttons for ignoring or resolving errors at all. I agree, though, when we get to the point where we introduce ignore/resolve functionality, we will need some way of viewing the errors that have been ignored or resolved. For the MVC, I think we are going to focus primarily on the button to create an issue from an error only. The remaining question is: should this happen from within the row, or should it just happen from the detail page? Which flow is more important?
One thing I'm not sure about is the "i" button.
Yeah, I agree! The 'i' button was from my first draft; I removed it in later iterations. Here is an example of the latest button group for ignore, resolve, and create issue. The icons here are still placeholder. But, again, I think this whole button group won't be part of the MVC, just the create issue button (if and only if it's needed).
This issue is being moved to await further demand. We have decided to prioritize the notion of Ignoring an error. Let's continue that discussion on #36245 (closed).