Assigning an event to a user

[exitgames]

To avoid having to go to external issue trackers, it would be a nice addition, to be able to assign an Exception/Event to one of the users.

[niemyjski]

We'd have to assign at the stack level, as an event may be deleted due to retention.

I think the following should happen:

1. Assign to an existing user and they are emailed.
2. UI indicates who it's currently assigned to..

What should happen when the user is removed or the stack is deleted?

• Should we assign the event to the deleting user or unassign the person?
• Should we email the user to let them know they've been unassigned?

[exitgames]

I agree on 1. and 2. (+ filter events to view assigned by user).
3. user removed, stack deleted - unassign the person.
4. email - I would not do that when unassigning a user. It could make sense, when deleting a stack.

[niemyjski]

Seems when you are assigned, you'd want a notification anytime that stack changes (marked fixed, deleted). But what if you were the one that marked it as fixed. I guess then you shouldn't get notified.

[exitgames]

Yes, makes sense.
In the process of user notifications, you could think about a watch-stack-feature, but I think that may be a separate feature request, though a bit coupled to this one.

[niemyjski]

Yeah, I think that would be a separate feature request :)

[niemyjski]

I think the nice thing about this if we did it, is it would cut down on the amount of notifications every one gets as only the assigned person would get them.

[daniel-miller]

This would be helpful for our team as well. +1!

[caesay]

I think this should be closed - an issue tracker is useful because of its richness and focus, integration with source control, ticket workflow and automatic elevation to other users for testing / uat etc. There's no way to duplicate or do it well here. It would be much more useful if exceptionless could elevate an issue stack to an existing tracker integrated with source control (i believe it already can do this?) and then provide a link from then on to view that ticket so another is not created.

[niemyjski]

We already support this with zappier but it would be nice to have some metadata on the stack or maybe even a notes section that could be used to document whose working on it / what's going on.

[niemyjski]

I want to stay away from being a full issue tracker, there are services that just do that and I don't think we should ever try to compete on that, we should focus on one thing and do it well.

[twomm]

For smaller teams/projects simply assigning an error to a user might already be a great help. No need for a full blown separate issue tracker for those. So adding something simple here would be a nice addition.

[caesay]

@twomm I can see where you are coming from, but if you use Bitbucket, Github, TFS, VSO, Gitlab, Sourceforge, codeplex, or almost anything other than just a simple git server you already get issue tracking built in and integrated with your commits - I just didn't think that the wheel needed to get re-invented over here.