Question

Public case submission seems like it's been marooned by the robustness of the email functionality. The usual life cycle for someone using this is:

1. Start using it.
2. Start getting spam.
3. Stop using it.

Maybe there's a 2.5 step in there where they contact Fog Creek and ask why they're getting spam. Worse yet, there's not a great understanding that selecting "Yes" from the allow public submissions dropdown will allow outside parties to create cases in their FogBugz installation. (I know, it's documented, but users don't read.)

Here's a list of what I think could be done to make this feature something people use on purpose:

• Customizable email response templates
• Show or do not show "Your Cases" section according to global setting
• Shut down public case view after 100 incorrect ticket values, to prevent brute-force attacks
• One-click hide for email addresses to address privacy concerns
• True integration with and potential to limit the form to community users
  • Ability to set permissions such that community users from a given group/client/company can see case status for all cases from their group/client/company
• CAPTCHAs to prevent spamming the form
• Clearer notation that a given case has been submitted via the public web form (rather than Bug posted to website)

Case FC1859902

Edit: I'm making this status-fixed because we have gone a long way to improving this feature with the recently released (7.3.2) community user features. Here's some highlights:

• A few small security features on the form that should drastically reduce bot traffic.
• Ability to restrict the submissions to community users.
• Ability for community users to see their own cases.
• Customizable email response templates.

Answer 1

We've filed a feature request to support this. Vote this question up to voice your support for this feature.

Answer 2

We (Evernote) use a FogBugz server for both internal bug tracking and external support. We support a wide variety of products and configurations, so use a web form to initiate support case. This collects detailed information about the user's product, version, etc. It also grabs the user agent for the case, which provides information about browser and OS version.

This saves a huge amount of time for both our support staff and users compared to raw email, since we don't need to waste time with a round-trip email asking for all of that information (which is frequently not provided correctly on the first attempt).

When a case is created in this manner, FogBugz sends a one-line email to the correspondent that says something like: Your inquiry has been received and can be tracked at the following URL: https://ourbugserver/fogbugz/default.asp?8872_asdfhafd

We need to change the content of this email since it causes a lot of complaints from users who are upset that a raw URL gives access to their email address, etc. (We try to explain that the part at the end provides security, but they correctly point out that this URL may sit in the browser cache on shared computers, etc.). We also want to communicate a little more follow-up information in this email.

In FogBugz 6, we manually worked around this by editing fogbugz/Website/res/en-US/lang.php to replace this line: $GLOBALS['fb_public_notification_message'] = 'Your inquiry..." When we edited this string and restarted the server, the outbound emails would change accordingly.

In FB 7, the process of sending a reasonable reply is even uglier, since we need to edit an undocumented source file and rebuild the *.dlls

This should be configurable in the same manner as other outbound email replies.

Answer 3

individual public case submittion, customer-side case tracking and editing requires a full-fledged (public) user administration and permission feature set along with it.

Community user would be either 1) anonymous - would only see "public" cases as possible already (projects with public case submittion enabled and community user in a respective group) 2) registered - and see all cases that are specific to their organisation and may or may not be publicly visible to others.

So here is what I would find necessary along with providing case views and lists for community useres, to assure integrity of customer-specific DIY case entry and retrieval (in order of suggested priority):

• Administrator feature to determine period of case retention and actual deletion (say i.e. 2 years, older then that purge from database!); or staged first removal of file attachments and after 3 years entire case events (only keep case record and removal date time stamp)

• Allow community users for some privacy options - (while mandatory registering with proper Name and Company) but allow using a self-chosen alias for login and display discussion posts

• FBOD Support for LDAP to maintain existing website user registration from corporate websites or pre-existing web portals

• User account duplicate merge feature for admins - so as to allow to merge all cases from seperate correspondent(s) emails under one account (i.e. multiple prior user (self-registrations)

• a customer / community user property to either populate (or self-input) with a company name or a match code (from crm system) to align accounts with website / crm systems.

-