Question

We find that we only wish to log cases in Fogbugz when a first line support person has exhausted a list of 'usual fixes'. We would then like to raise a case for a developer to look at.

This involves a lot of copying and pasting so we'd like to use the API (or equivalent) to pre-fill the case with some really useful standard data from our front line web application.

After some initial research, it looks like we have the following options:

1. Enable public submissions and use the API to raise a case via it? Or is the API not an option on public submissions?
2. Log-in once to get a token from the api and use this indefinitely to post case via the API?

I'll add some more information for future searchers for the same answer:

BugzScout Question From Here: http://fogbugz.stackexchange.com/questions/315/submit-cases-from-the-field-bugzscout

Fogbugz BugzScout Documentation: http://www.fogcreek.com/FogBugz/docs/70/topics/customers/BugzScout.html

It seems that bugzscout is what I need. The rationale behind not using a dedicated login is that our first line support will be performed by another company so giving them access to fogbugz is considered too much information for them. Information in fogbugz is often sensitive and describes future development so is not something we would want to share with external partners. Our workflow requires that we pick up things that support cannot answer, resolve them and then add to our support FAQ which is on a public FB wiki page.

Answer 1

This sounds like a legitimate use of the API; I'd have a button somewhere on the front-line support application that can be pressed to create a new FogBugz case from the available info.

If you don't have or wish to have a FogBugz licence for each member of the front-line support staff, you might want to consider having a licence dedicated to the server that uses the API to create FogBugz cases. It is, however, much cleaner to have them submit cases as themselves, so statuses of their cases can be more easily tracked (both by themselves and by management).

What requirement is satisfied by restricting yourself to a single log-in? I wouldn't rely on this myself, but without knowing the rationale, I can't offer any other suggestions.

Answer 2

BugzScout will work as well, if its subset of settable fields is enough to achieve your goal. The trade is that BugzScout doesn't require a login token.

Answer 3

We inject external cases in FB without needing to publish account details by adding a single ashx file to the Fogbugz website directory (FB does not currently interfere in the handling of ashx files, so you don't need to do any web.config fiddling.)

The ashx contains code to take a specially constructed POST request from external applications, and then do an API logon & add based on the result. This allows us to do stuff which scoutsubmit doesn't, like add file attachments (our automated reporting always includes file attachments). We don't have to release login credentials or tokens outside the source code of the ashx file.

Answer 4

We have a dedicated "Customer Service" user in our FogBugz instance which is used only to make XML API calls. If you don't need your service people to be able to log into FogBugz and make edits, but just to raise cases, I would write a script to create the cases with the API. The case event (or a custom field) can be structured to hold key information such as the name of the support person who opened the case.

Storing the logon token in your code for indefinite use is the recommended method, avoiding coding usernames and passwords into your scripts. If the token is compromised, one could not use it to log into the web UI, just use the XML API, and you can invalidate the token by using cmd=logoff with that token.