Skip to content
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

Open
boxed opened this issue Jun 15, 2017 · 60 comments
Open

Feature request: manually add tags #5572

boxed opened this issue Jun 15, 2017 · 60 comments

Comments

@boxed
Copy link

boxed commented Jun 15, 2017

It would be really useful if one could manually add tags to events.

@dcramer
Copy link
Member

dcramer commented Jun 15, 2017

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.

@boxed
Copy link
Author

boxed commented Jun 15, 2017 via email

@izabelavmelo
Copy link

izabelavmelo commented May 10, 2018

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.

@dcramer
Copy link
Member

dcramer commented May 10, 2018

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.

@CaptObvious
Copy link

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).

@marioaa
Copy link

marioaa commented Oct 3, 2018

+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).

@fosterbrereton
Copy link

+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.

@dcramer
Copy link
Member

dcramer commented Jan 17, 2019

A few quick questions for anyone paying attention:

  1. Do these tags need to exist in search?
  2. Do they need to exist in distribution graphs and other tag views on issue details?
  3. Do they need graphed (ignoring we dont provide graphs today)?

@dcramer
Copy link
Member

dcramer commented Jan 17, 2019

  1. Do you need more than one of these tags per issue? e.g. limit of one value per key (JIRA_ISSUE=X)

@boxed
Copy link
Author

boxed commented Jan 17, 2019

Speaking for myself:

  1. Yes
  2. Don't understand
  3. Don't understand
  4. One is infinitely better than zero

@fosterbrereton
Copy link

  1. Yes
  2. No, as long as they're visible on the main issue page
  3. No
  4. Only one needed at this time (though I could certainly see more being valuable)

@dcramer
Copy link
Member

dcramer commented Feb 4, 2019

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.

@silvainSayduck
Copy link

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;
  });
});

@Betree
Copy link

Betree commented Nov 27, 2019

Our use case for having a tags system:

  1. For grouping issues. For example we got a lot of exceptions from our internationalization system. We'd like to be able to group them to investigate them under a i18n tag and eventually get some statistics to track the evolution of issues related to a specific tag. Same goes with projects, would be useful for bug fixes hackathons and statistics to group by specific sub-projects. Example of tags: projects > gift-cards, projects > events...etc

  2. For assigning priorities or link to a roadmap. Example tags: priority > low, priority > high.

  3. For having custom statuses over issues. Example: status > investigated, status > to investigate, status > waiting for feedback


Based on that, here hare the answers regarding @dcramer's #5572 (comment):

  • Do these tags need to exist in search?

Ideally, yes.

  • Do you need more than one of these tags per issue? e.g. limit of one value per key

Yes.

@mavericreal
Copy link

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".

@liweinan0423
Copy link

sometimes we need to manually triage the issues reported by sentry and categorise them into different severities, so manually adding tags/label is required

@webjunkie
Copy link

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.

@jolkkola
Copy link

jolkkola commented Apr 7, 2020

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

  • how many unique users have potential malware in their browsers
  • which category types have most reports/unique users

@jakuub
Copy link

jakuub commented Jun 24, 2020

We would like to use this for triage between different teams.
The key-value will be good, but we don't necessarily need it.

  1. Yes
  2. No
  3. No
  4. currently we need one, but it would be beneficial if we could have more for the future.

@charlesverdad
Copy link

charlesverdad commented Jan 6, 2021

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.

@Proper-Job
Copy link

Proper-Job commented Jan 20, 2021

A few quick questions for anyone paying attention:

  1. Do these tags need to exist in search?
  2. Do they need to exist in distribution graphs and other tag views on issue details?
  3. Do they need graphed (ignoring we dont provide graphs today)?
  1. yes, definitely
  2. not necessarily
  3. not necessarily

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.

@YassienW
Copy link

YassienW commented Feb 5, 2021

+1 for this. I'd like to be able to add a level of manual organization via grouping while going through issues

A few quick questions for anyone paying attention:

  1. Do these tags need to exist in search?
  2. Do they need to exist in distribution graphs and other tag views on issue details?
  3. Do they need graphed (ignoring we dont provide graphs today)?

1- Yes
2 & 3 - Could be useful but not necessary for my use case

@blocknotes
Copy link

blocknotes commented Mar 5, 2021

+1, please consider this request.
We are in the same situation; we have some Sentry events (even some exceptions) that will be handled in the long-term so I think that it would be great to be able to flag them from the Sentry UI. As a workaround, we are also evaluating adding a string prefix in the code to mark those issues (ex. "[ignore-for-now] My nice exception") because it comes in handy also from the Sentry issues index page to catch them immediately.

A few quick questions for anyone paying attention:

  1. Do these tags need to exist in search?
  2. Do they need to exist in distribution graphs and other tag views on issue details?
  3. Do they need graphed (ignoring we dont provide graphs today)?
  1. Yes
  2. No
  3. No

@imajes
Copy link

imajes commented May 27, 2021

+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.

@mfn
Copy link

mfn commented Aug 9, 2021

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.

@aitorres
Copy link

+1. We'd benefit greatly from being able to manually label issues or group of issues and be able to search for these labels.

@getsantry getsantry bot removed the status in GitHub Issues with 👀 3 Jun 5, 2024
@invised
Copy link

invised commented Aug 14, 2024

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.

@maxnorth
Copy link

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.

@getsantry getsantry bot moved this to Waiting for: Product Owner in GitHub Issues with 👀 3 Jan 24, 2025
@dcramer
Copy link
Member

dcramer commented Jan 24, 2025

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).

@maxnorth
Copy link

maxnorth commented Jan 27, 2025

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 (is:linked doesn't include these). Would be nice if I could just automate that myself. I think there's a couple strong motives for you all to make this possible: 1) reduce the pressure of feature requests by equipping people to do things themselves, 2) learn a lot about common product needs by observing what custom tags people most often create.

@getsantry getsantry bot moved this to Waiting for: Product Owner in GitHub Issues with 👀 3 Jan 27, 2025
@rachrwang
Copy link

rachrwang commented Jan 28, 2025

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]"

@maxnorth
Copy link

I'm primarily interested in an API, so I can do these via webhook handler or cron job.

@hugobessa
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: No status
Status: No status
Status: No status
Development

No branches or pull requests