-
-
Notifications
You must be signed in to change notification settings - Fork 4.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature request: manually add tags #5572
Comments
Could you explain your use case? We're considering adding something similar to GitHub's labels, but it'd be a single value, not key=value pairs. |
I don't want to describe our situation too much but we've got a class of problems that are probably related and we're investigating so it would be nice to be able to tag them. Grouping is a much too aggressive action for this.
Single tags instead of key-value would cover our use cases fine.
|
I agree with @boxed ! I need it too! For the same context. I would like to classify, without merge, just to investigate. I would like to put labels to issues (to organize visually). It's difficult to work with the list of issues without a way to organize in a personalized way. |
Just a heads up we're going to be revisiting this in the near future. I do agree that there's a lot of reasons to do this kind of thing, we just need to explore the technical and product implications, and decide if it can be the same 'tags' system we use today or if it needs to be something else. |
I could do with this to be able to manually add issue IDs from our internal issue tracker that we can't integrate with Sentry (it's not reachable from the network where we have Sentry deployed). |
+1, There are scenarios where errors come up which we were not expecting. I can then later add a tag to group ones which come up later on. But all the errors which have already been created will not show up in that group/filter. So being able to make sense and organize error which was not expected is really useful (and let's be honest, nobody expects an error). |
+1. We have a JIRA instance internal to our company, and I’d like to have a spot on a given issue where we can refer to a JIRA issue related to the Sentry issue. I’m thinking a custom, manually-managed tag could handle this use case reasonably. |
A few quick questions for anyone paying attention:
|
|
Speaking for myself:
|
|
FYI we're going to consider this as part of our incident management product set (Q2 timeline). Will update this thread with what we decide. |
If anyone is interested, here is the workaround I currently use to set tags for individual Exceptions Sentry.configureScope(scope => {
scope.addEventProcessor((event, hint) => {
if (event.extra && event.extra.tagged) {
return event;
}
Sentry.withScope(_scope => {
const { tagName, tagValue } = getTagFrom(event, hint);
_scope.setTag(tagName, tagValue);
_scope.setExtra('tagged', true);
Sentry.captureException(new Error(hint.originalException));
});
return null;
});
}); |
Our use case for having a tags system:
Based on that, here hare the answers regarding @dcramer's #5572 (comment):
Ideally, yes.
Yes. |
Where is this at? We need to add tags manually because sometimes issues arise by a part of the technology that did not cause the issue. For example, a wrapper in frontend gets an exception but there is a bug in the API. We want to be able to measure how many issues are caused by what parts of the technology. So in the previous example, we'd like to tag manually the issue (once we've found the root cause) with a tag similar to "bug:api". |
sometimes we need to manually triage the issues reported by sentry and categorise them into different severities, so manually adding tags/label is required |
We also have the same requirement in that we want to categorize issues. We might want to say some issues are high priority, others we keep an eye on. Some are easy to solve, some need the most senior person to look into. This is not possible now, unless referencing the issues in something like Jira with extra documentation work. |
This would be useful for doing some quick and lightweight triage or assessment on Content Security Policy (CSP) violation reports. We would like to categorise these violation reports according to probable cause - such as a certain plugin or embed, a feature in the web page, or the cause being potential malware etc. Currently this needs to be done in an external system which requires extra work and tends to be cumbersome. It is easy to ignore (or solve) a certain type of issue, but that's not really what we would like to do. Ideally it would be easy to look up all the issues under a certain manually applied category/tag/label. And it should be easy to add new issues under a pre-existing category, naturally. This way it would be easy to answer questions like
|
We would like to use this for triage between different teams.
|
This would be very useful for us. For our case we only need it to be in the issue level, not necessarily at the event level (although it should be fine wherever). We would like to search for issues that belong to a team and right now the only way to do this is if we set a team as an assignee. But if we need to assign individual users then we need a place to store the team information so that it's easier for users to see issues belonging to their team. Tags/labels would be useful in this case. |
A workaround I did for our use case is to create a dummy user (triage) for those tickets that have been triaged but not assigned to developers yet. |
+1 for this. I'd like to be able to add a level of manual organization via grouping while going through issues
1- Yes |
+1, please consider this request.
|
+1. I'm working on a legacy system that has some issues. One is with stripe, where there's a half dozen specific error cases that come up. it'd be useful to tag/group/label all these together so that they could be easily triaged. |
Use case: a security audit might be responsible for triggering certain issues and there might not be a clear shared fact to group them (no dedicated IP, no single user agent, etc.) and adding custom label/tag to be able to group events (which means: also be able to search for it) would be useful to assess the situation. |
+1. We'd benefit greatly from being able to manually label issues or group of issues and be able to search for these labels. |
Waiting for this feature too. Absence of manual tags or key value pairs on the UI level is keeping me away from switching to Sentry. So surprised such a basic and obvious feature is not supported. |
Came here looking for this. Need a way to be able to extend the searchable attributes of issues. Ideally would support key=value, not just labels. |
Are you looking for things that are based on context in the application or just arbitrary classification that'd require human triage to add? The former is pretty easy to do today within SDKs (using our context APIs). |
I'd like to automatically add tags to issues after they've been created. TBH, much of my motivation is to make certain attributes searchable that Sentry doesn't OOB. For instance, filtering by link to PR ( |
For those who have requested this feature....how much of the need is around manual tagging, and is that a sustainable workflow/ easy enough to maintain? Curious if would you want tools to automate that, like an option to "tag all issues that resemble [criteria] with [tag key: tag value]" |
I'm primarily interested in an API, so I can do these via webhook handler or cron job. |
Our use-case is: we have a team actively monitoring Sentry, but they're not always responsible for resolving the issues. It would be ideal for us to manually tag events and give better visibility on what each other team needs to investigate/solve. |
It would be really useful if one could manually add tags to events.
The text was updated successfully, but these errors were encountered: