Welcome to the FogBugz Knowledge Exchange

Question

1

I'm a new FogBugz user planning to use FogBugz for customer support and new sales inquiries. I'm currently trying to figure out the best way to get these inquiries into FogBugz.

I understand it would be easy to set up a public email address, and in fact I have set up support@ and sales@ emails for people who choose to do that. But I'd also like to use forms on the site since there's certain information I'd really like to collect.

It seems like it should be easy enough to create a form that POSTs to the FogBugz API. I can do that if I use a user's API token. But of course I don't want to do that since that token could be used by someone technical to read all cases its owner has access to.

I tried creating a community user who can add but not view cases, but apparently community users don't have API access.

Then I figured I could create a normal user who only has access to one project (i.e., the inbox) and then automatically move cases to another project as soon as new cases are created in the inbox, but the workflow functionality doesn't seem robust enough for this.

I understand there's a public form for new cases, but I don't want to redirect my users here. I could also POST to a separate file on my server that passes this information on to FogBugz (thereby hiding the token), but this is more work than I want to do.

So to conclude: is there an obvious way to do this that I'm missing, or do I have to do some more programming (which I don't want to do) or find another application (again, not ideal)?

Thank you!

flag	asked Dec 13 2010 at 4:30 David 13●2

db · Accepted Answer · 2010-12-13 16:30:07Z UTC

2

We have a feature known as "BugzScout" that aims to solve exactly this problem.

You can read about the BugzScout feature here.

answered Dec 13 2010 at 16:30

db♦♦
11.5k●7●13

	After some investigation, I'm not sure this will work as I'd like. The issue is making sure I'm showing visitors a nice message after submitting the form. The documentation you link to suggests that ScoutDefaultMessage can include HTML, which would allow me to create a pretty message and send the user back via Javascript. But HTML is escaped in the message I see after submitting the form. I was then planning to submit the form via Ajax, but that creates major headaches in some browsers with cross-domain requests. Getting around those will require more work than just using the XML API. – David Dec 14 2010 at 5:45
	Hi David, that's definitely a bug. I've filed a case to look into it, but in the meantime, my suggestion would be to have your own simple form handler that essentially proxies the BugzScout submission to FogBugz. This way you have complete control over the response sent back to your customers (you could even redirect them to a static page if you wanted to), and avoids the cross-domain hassle. – db♦ Dec 14 2010 at 15:16
	Of course, if you're going to have your own custom form handler anyway, you could definitely switch to using the XML API via your form handler which would give you even greater control over how the submitted data made its way into FogBugz. And, like you mention, you could keep the API token in the form handler to hide it from the person submitting the bug. I realize these scenarios are exactly what you were trying to avoid, but until we resolve the html-encoding issue, these might be our only real options. – db♦ Dec 14 2010 at 15:19
	No worries, I'll just write a form handler and use the XML API. The actual coding work shouldn't be an issue--the major problem is actually that I'm using a Rails app on Heroku, so I can't just throw a PHP script on a server somewhere. But in the end this is actually probably for the best. Thanks for your help! – David Dec 15 2010 at 0:12

Roman · Answer 2 · 2010-12-13 15:13:17Z UTC

Using a backend CGI script to the form processing

The way I would do this would be to create an html form that has all the fields you want to capture but does not have the actual Fogbugz token. This form would then be posted to a cgi script on the web server which takes care of forwarding the request (doing the actual post) to the Fogbugz server. It would be this cgi script that has the embedded fb token and wouldn't be seen by the user reporting a case. After reporting the case the user could just be redirected to a "Thanks for reporting" page.

I guess this would require some more programming (the cgi processing script) but of the options I can think of it's the one that requires less coding.

POST a new case from a public form

2 Answers

Using a backend CGI script to the form processing