General Feedback
-
Customise "New Crash Issue" Slack message body (e.g. add Custom Fields)
Hi Martin,
We've had the Slack integration set up for the last year or so and get a lot of value out of it; however the main thing we need to know when we see a new crash report come in is identify what user (for which of our customers) the crash occurred for.
We have this information stored in Custom Field data, so pretty much every time a crash comes in, someone has to click the link in Slack, log into Tracepot, click Crashes then click one particular crash, then copy/paste the data from the "Custom data" tab into…
3 votesHi Andrew,
After closer review this may not be possible to do the way you requested it.
Notification is send only for new crash. As you know new crash is based on the hash created from crash report fields. Custom Field data are not used to generate the hash so you may have multiple users generating the same crash. We can send any Custom Field data in the notification but this will be misleading as what you really get is data from the first report that generated this new crash notification.
Regards,
Martin -
Add comment on crash
Hello,
I like your tools, I tested it since few days and it's really cool. By the way, a little improvement could be the possibility to add comment on a crash without closing it. Is it possible to add it in the future ?
Regards
1 voteHi, we already started working on this feature and it will be included in next major version.
-
Improve issue grouping, or make configurable
So far only two crashes have come in to Tracepot naturally, and they've both been grouped into one "issue" which isn't correct.
The top level exception in the stack trace in these two crashes is different, but I believe Tracepot is trying to be smart and decides which part of the stack trace is relevant for grouping (presumably that is the line which is highlighted in bold in the stack trace, and I'm guessing that is determined as the first trace element which contains the app package name).
The problem with the grouping is that almost all crashes from our…
2 votesHi Andrew,
We group issues by class name, file name (including the line number) and app version code. We do not use the whole first line of a stack trace anymore because it created lots of issues where only the first line was slightly different but the rest of the stack trace was the same. Usually when an ID of some sort is included that changes every time like a window ID.
But I understand your problem. You are catching javascript exceptions and re-throwing them as java exceptions. In the current state all happens in the same file with the same class name and therefore is grouped as 1 issue.
This is not an easy task to solve because I need to take into consideration stack traces from all other apps and there is no clear sign that this is javascript exception so use different grouping. I found some pattern…
-
connect this perfect service to trello as task manager
We use Trello service for managing our team tasks and it would be perfect to be able to connect these two useful services.
7 votesThank you for your feedback. We will consider this when we will be compiling a list of task managers that will be integrated as first.
-
Easier way to switch between individual and aggregated crash report
There doesn't seem to be an easy way to switch to/from aggregated view. I.e. once I click on an individual report the only way back to the aggregated overview is with the browser back button.
1 vote
AdminMartin Milesich
(Admin, Tracepot)
responded
What could be easier than a simple back button? If you have something specific in mind we would love to hear it.
-
Categorize traces
It would be great if we could categorize the messages sent to tracepot, and after in the analysis filter them appropiately.
2 votesI like this idea with applying tags to crash reports. I also see it as a quite complex feature. We will try to break it into smaller parts so you can enjoy it as soon as possible.
-
Mark device as a dev device.
What would be really good would be if in the UI you could mark a device that had reported a crash as a dev device and all reports from that device would now be develop mode. That way dev and release would be automatically separated without code modification.
12 votes
- Don't see your idea?