Question

Often, information makes its way into cases that can make them misleading. It's also possible for sensitive information to be inadvertently introduced, either through email or erroneous case edits.

Some FogBugz users also want to be able to delete cases just as a clean-up measure.

Is it possible to delete cases or to delete entries within cases (a.k.a. bug events)?

See Also:

• Deleting old cases
• Deleting old email attachments
• Deleting old attachments

Case FC1209083

Answer 1

We have logged this as a feature request. Please vote up the question above to show your support for adding this feature.

---

FogBugz is built around the idea of capturing and tracking everything about your project. To that end, we've made some design decisions that might seem odd at first, but actually end up making a lot of sense. It's sort of like looking for the "off" button on your iPod. For an iPod, paused is the same as off.

A closed case is, for the purposes of issue tracking, the same as deleted. It no longer shows up in filters, it's not assigned to anyone. It can be found only by filtering for closed cases or by searching for text in it specifically. We've found that once people get used to the idea of just closing a case and moving on, it never comes up again, the same way you get used to not having to manually switch off your iPod.

Most often, the cases that people are looking to delete are the ones with the title "foo" or "test" that they put in when they were starting off with FogBugz. There are two options here. First, you can close and ignore the case. Other bugs will be filed, and soon those cases will be a distant memory. Or, you can install the Case Event Edit plug-in, which will allow you to repurpose those old cases for new uses.

For customers where there might be a security or privacy issue (such as a credit card number erroneously stored in a case), we recommend running FogBugz on your own server where you have full control over the database and can excise data as necessary.

If you truly need to remove information, then removing directly from the database is the only way.

Here's how to do that:

In FogBugz 7 and earlier:

DELETE FROM Attachment 
  WHERE ixBugEvent IN
    (SELECT ixBugEvent FROM BugEvent WHERE ixBug = 1234);

In FogBugz 8 and later:

DELETE FROM Attachment
  WHERE ixAttachment IN
    (SELECT AttachmentReference.ixAttachment
    FROM AttachmentReference
    INNER JOIN BugEvent
      ON AttachmentReference.ixBugEvent = BugEvent.ixBugEvent
    WHERE ixBug = 1234);

DELETE FROM AttachmentReference
  WHERE ixAttachmentReference IN
    (SELECT AttachmentReference.ixAttachmentReference
    FROM AttachmentReference
    INNER JOIN BugEvent
        ON AttachmentReference.ixBugEvent = BugEvent.ixBugEvent
    WHERE ixBug = 1234);

If you're using MySQL, the AttachmentReference query needs to be changed to this:

DELETE FROM AttachmentReference
  WHERE ixAttachmentReference IN
  (SELECT x.ixAttachmentReference
   FROM (SELECT * FROM AttachmentReference) as x
   INNER JOIN BugEvent
     ON x.ixBugEvent = BugEvent.ixBugEvent
   WHERE ixBug = 1234);

For all versions of FogBugz:

DELETE FROM BugView WHERE ixBug = 1234;
DELETE FROM BugRelation WHERE ixBugTo = 1234;
DELETE FROM BugRelation WHERE ixBugFrom = 1234;
DELETE FROM Scout WHERE ixBug = 1234;
DELETE FROM TagAssociation WHERE ixBug = 1234;
DELETE FROM Duplicates WHERE ixBugDupe = 1234;
DELETE FROM Duplicates WHERE ixBugDupeOf = 1234;
DELETE FROM TitleWord WHERE ixBug = 1234;
DELETE FROM CVS WHERE ixBug = 1234;
DELETE FROM TimeInterval WHERE ixBug = 1234;
DELETE FROM Subscriptions WHERE ixBug = 1234;
DELETE FROM BugEvent WHERE ixBug = 1234;
DELETE FROM Bug WHERE ixBug = 1234;

If you want to delete all cases in a given project or group of projects, it's easy enough to put WHERE ixBug IN (SELECT ixBug FROM Bug WHERE ixProject IN (2,3,4)) instead of WHERE ixBug = 1234.

See also deleting old attachments and deleting email-attachments.

Answer 2

I have made another Project named "trashcan". Only administrators are able to move it to this project. Cases are not actually deleted, but are also not visible in the real project anymore.

Answer 3

For "On Demand", will Fog Creek permanently delete cases on request?

Answer 4

I usually mark cases as spam and they are deleted later. After doing this I reset spam autosort. I don't get spam on my mailbox, and I don't use autosort feature for categorizing incoming emails, that's why I can do it safely.

Some cases are not deleted (e.g., if I created a case myself). In this case sometimes there is another workaround: send email from case that I want to be deleted to some spam case (i.e. to my cases@domainname.fogbugz.com address with (Case #) in email title).

Another way is to leverage auto-deleting feature for old incoming emails.

I deleted over 50 cases and couldn't delete 7. It is time-consuming, but I like having only data that I want to keep, that's why I did it.

Answer 5

This does'nt help with subcases which still show up in filters, you have to go through each one and remove the parent task.

Not being able to delete is a BAD design decision and should be reconsidered. It just stupid

Answer 6

Comparing a delete feature in a product like fogbugz with the off button on an iPod is a bit silly. An iPod doesn't need an off feature since just as you say, when the iPod isn't in use, for all intents and purposes, it's off. A case however, may have several reasons why it's no longer needed and should be removed; you touch on a few of the reasons yourself even. Agreed, in 9 out of 10, closing a case is likely to be enough (and even recommended!) but for that 10th case there must be a way of adding this feature without sacrificing either the UX or the integrity of the case list.

Case removal could well be an admin feature and even then it doesn't have to be fully deleted: just move it to some sort of trash area and then do garbage collection after some amount of time. I often think of fogbugz as a source controlled to-do list, and in this sense I not only want but need a good way of mucking about with history to have it make any sort of sense. And when (not if) I screw up, there's always a safety net.

In any event, your comparison is actually wrong. The iPod does have an off feature, just press the hold switch until it turns off, for real. This is a rather non-obvious feature, but it's there, just like the suggested case removal feature could be.

Answer 7

We migrated from another system to FogBugz, and we had to run our in-house migration scripts a couple of times. We did put all the tickets of the previous test runs in a "Test" project, and we would like to either delete them, or at least make sure they don't show up in search.

We are takers for any solution to that issue, since it makes the search box a major pain to use as it is right now!

Answer 8

Please, please, please let me delete attachments. We use Fogbugz for support, and customers what to be sure we have deleted the secret attachmemnts once the case is closed.

Answer 9

Is not this MySQL code for deleting AttachmentReference more efficient (at least in MySQL 5.1)?

DELETE ar FROM AttachmentReference ar INNER JOIN BugEvent 
    ON ar.ixBugEvent = BugEvent.ixBugEvent INNER JOIN Bug 
    ON Bug.ixBug = BugEvent.ixBug 
    WHERE Bug.ixBug = 1234

Im just qurious since the mentioned code in the answer for MySQL takes about 4 minutes / case to execute... Or am I missing something?

Also, the Delete Attachment code is also very slow on MySQL. Takes about 2-3 minutes / case... Is there any possibility to get some help to optimize this?

I need to delete a lot of cases and with the current speed of these statements its not going to finish for at least a couple of months ;)

Answer 10

It's great that you've created a work flow based on sound, tested principles. Overall I think it's a great system.

But to tell people that they don't realize that deleting a case may come back to haunt them? I think we're capable of determining whether a case should (or needs to) be deleted, or if it should just be closed.

Answer 11

It should only be possible by an admin!