Report run time errors to business and tech team

[josiahseaman]

• [ ] Render django stack trace page to email
• [ ] Email Address: adsm.support@newline.us
• [ ] Give credentials to Missy

[BryanHurst]

This is to prevent the error pages from being displayed to the user.

[BryanHurst]

Thoughts on the email: is there an ADSM domain that we could make an adsm.support@ email address for? If not, maybe we should set one up and have it point to the github pages?

[missyschoenbaum]

How do we point it at the github pages?

[josiahseaman]

What would make me happiest is if this were actually a NAVADMC repo and every error pushed a new file. That way I can check out the repo and do file operations on it. Pull it into a database and filter through error messages to do forensics.

[missyschoenbaum]

An alternative it to send it to our group mailbox, which is vs.ceah@aphis.usda.gov. It would help if we can force ADSM into the subject. Also, I need to know when we would start getting messages to this email box.

[BryanHurst]

I just realized that this is not a good solution.

To be able to send an email, you need an SMTP server. This would work on the Cloud version as we can privately store SMTP credentials on the server, or even install our own like Postfix.

However, in the desktop environment, we would have to deploy SMTP credentials on the Github server and all the installations. This is just asking for somebody to grab the password and start using the account for spam.

[missyschoenbaum]

Just as a reference point, the old application will send you to either a bug reporting list, or to the general website. Up until we have a support agreement, we don't have a website, or a bug reporting list that we would want to expose to the public.

So, is our option to post static text directing them to email the aphis address request that the subject line start with "ADSM"?

[BryanHurst]

We might be able to launch Outlook (or what ever other email program the user uses) with the To: and Subject: fields already filled in.

I'm not certain if we can do this from within our custom browser, but it wouldn't take but a few minutes to test out.

[BryanHurst]

Another option, which can also be used on the Cloud version, is for Newline to make a bug tracker server that all the clients will POST to.

@josiahseaman it would be a simple Django project with probably one object model to accept stack traces when they are posted to the server. We can limit clients to 10 posts a day and each post only 1KB in size.

Having the bug reports tracked in a database could allow us to do better filtering and metrics in the future for bug prioritization.

[josiahseaman]

Other options we discussed and rejected:

• Sending an email:
  • packaging an SMTP client could be hijacked for spam distribution
• Pushing files to github.com
  • We'd need to distribute a private key which could be used to block all other users
  • People could upload large, unwanted files, illegal content

Creating a simple server allows us to specify rules as to what content will be accepted. It's the most secure solution.

[boomtown15]

Could we just point to our Github project and allow the user to create an issue if they encounter a problem? If possible, we could create a link with parameters to automatically set a label for any issues created from the application, which would help us triage the application specific issues. We should also be logging any errors and possibly allow the user to export and attach the log(s) to the issue, so we have as much information as possible to diagnose. I don't know if this has already been discussed or not.

[casesp]

I think creating an issue could be a great help, especially making use of the features of Github, which would notify us all of the new issue. The one caveat that I would add, however, is that the user should not be expected to be familiar with Github, and most likely would not be familiar, thus an automated method to create the issue would be best.

[boomtown15]

Good point. We could try to use the API to create an issue programmatically and have the fallback be a link to create an issue to Github if that was too difficult to implement in the time required.

[BryanHurst]

One thing to keep in mind about Github (and our Git Lab deployment) is that you cannot delete issues. Having an automated system start posting issues (which would also open up to other people posting willy nilly) has a rather large spam potential that could then not be properly cleared out.

[casesp]

Yep, that could be bad. If the program creates the issues, however, rather than the user, per se, perhaps we could mitigate for spam issues.

[BryanHurst]

Since the source code is distributed with the application, a user could easy take the credentials the program uses to post issues and manually post what ever they wanted. Which is what prompted this in the first place. We didn't want to put credentials for an email server in the source.

[boomtown15]

All valid points. The main goal of this is to show friendly error pages. Secondarily, it would be nice to somehow track issues. Maybe the best approach for the time being is to automatically log these internally in the application, so we can periodically review them for trends. Thoughts?

What if we provided an additional document with the builds that has steps for requesting help or submitting an issue? This would eliminate it being a part of the global build, but still give users a way to have a voice.

[boomtown15]

I've updated this to remove the HTML friendly error page which has been moved to #623

[BryanHurst]

If error reporting is still a desired feature, probably the best two options are:

1. Open the User's email client with the "to:" and "subject" fields already filled out.
2. Create an error reporting server similar to the NPU server that accepts error posts and can do spam filtering.

[missyschoenbaum]

I think there is not going to be an option for the future. Calling this good.