|
13
|
|
|
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 BugEvent 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.
|
|
|
|
12
|
|
|
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 BugEvent 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 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.
Note on MySQL:
The queries above work in MS SQL Server. MySQL will complain, however about selecting from a table that you are updating. You will need to use this technique to change them.
See also deleting old attachments and deleting email-attachments.
|
|
|
|
11
|
|
|
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);
For all versions of FogBugz:
DELETE FROM BugView WHERE ixBug = 1234;
DELETE FROM BugEvent 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 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.
Note on MySQL:
The queries above work in MS SQL Server. MySQL will complain, however about selecting from a table that you are updating. You will need to use this technique to change them.
See also deleting old attachments and deleting email-attachments.
|
|
|
|
10
|
|
|
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);
For all versions of FogBugz:
DELETE FROM BugView WHERE ixBug = 1234;
DELETE FROM BugEvent 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 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.
|
|
|
|
9
|
|
|
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);
For all versions of FogBugz:
DELETE FROM BugView WHERE ixBug = 1234;
DELETE FROM BugEvent 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 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.
|
|
|
|
8
|
|
edited Apr 1 2011 at 20:40
|
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);
For all versions of FogBugz:
DELETE FROM BugView WHERE ixBug = 1234;
DELETE FROM BugEvent 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 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.
|
|
|
|
7
|
|
edited Apr 1 2011 at 18:31
|
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);
For all versions of FogBugz:
DELETE FROM BugView WHERE ixBug = 1234;
DELETE FROM BugEvent 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 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.
|
|
|
|
6
|
|
edited Feb 23 2011 at 23:08
|
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);
For all versions of FogBugz:
DELETE FROM BugView WHERE ixBug = 1234;
DELETE FROM BugEvent 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 Bug WHERE ixBug = 1234;
|
|
|
|
5
|
|
edited Nov 22 2010 at 17:43
|
There FogBugz is always built around the case event editing plug-inidea of capturing and tracking everything about your project. To that end, if you just need to alleviate confusionwe've made some design decisions that might seem odd at first, but actually end up making a lot of sense. Here is the current state It's sort of play like looking for permanent case deletionthe "off" button on your iPod. The reasons we haven't heretofore provided case deletion are severalFor an iPod, paused is the same as off.What it boiled down to was that a decent segment A closed case is, for the purposes of our customers require full auditabilityissue tracking, so preserving case history was essential to themthe same as deleted. Enabling deletions would shut us off from a segment of potential customersIt no longer shows up in filters, and was it's not a dealbreaker very oftenassigned to anyone. In It can be found only by filtering for closed cases where or by searching for text in it was, we could always recommend a workaround (direct deletion)specifically. So, in short, there was not much incentive We've found that once people get used to enable deletion through the interface. Early versions idea of Gmail didn't offer deletion, just archiving, closing a case and users rebelled. They wanted moving on, it never comes up again, the same way you get used to be able not having to manually switch off your iPod. Most often, the cases that people are looking to delete are the email. Google said ones with the title "foo" or "test" that archiving and deleting they put in when they were basically the same thing. Eventually, Google relented. Eventually, Fog Creek will do deletionsstarting off with FogBugz. There is no interface for deleting casesare two options here. If you run FogBugz on your own serverFirst, you can go in the database close and delete them directly, but it is not recommended or supported. Here is a post on removing problematic infoignore the case. We recommend simply closing cases with a noteOther bugs will be filed, or as and soon those cases will be a duplicate of the correct versiondistant memory. You can move them to a special project you can create just for sequestering dataOr, say "Deleted data" or "Sensitive data" and set the permissions so only admins you can view it. That way install the Case Event Edit plug-in, which will allow you to repurpose those old cases won't for new uses. For customers where there might be readable by other users a security or even come up privacy issue (such as a credit card number erroneously stored in searches. We plan to deliver a sequestration plug-in at some point. We case), we recommend running FogBugz on your own server where you have also done some scary experiments with using plug-ins to leverage full control over the spam deletion feature to remove casesdatabase and can excise data as necessary.
|
|
|
|
4
|
|
edited Jun 11 2010 at 17:27
|
There is always the case event editing plug-in, if you just need to alleviate confusion.
Here is the current state of play for permanent case deletion.
The reasons we haven't heretofore provided case deletion are several. What it boiled down to was that a decent segment of our customers require full auditability, so preserving case history was essential to them. Enabling deletions would shut us off from a segment of potential customers, and was not a dealbreaker very often. In cases where it was, we could always recommend a workaround (direct deletion). So, in short, there was not much incentive to enable deletion through the interface.
Early versions of Gmail didn't offer deletion, just archiving, and users rebelled. They wanted to be able to delete the email. Google said that archiving and deleting were basically the same thing. Eventually, Google relented. Eventually, Fog Creek will do deletions.
There is no interface for deleting cases. If you run FogBugz on your own server, you can go in the database and delete them directly, but it is not recommended or supported. Here is a post on removing problematic info.
We recommend simply closing cases with a note, or as a duplicate of the correct version. You can move them to a special project you can create just for sequestering data, say "Deleted data" or "Sensitive data" and set the permissions so only admins can view it. That way the cases won't be readable by other users or even come up in searches. We plan to deliver a sequestration plug-in at some point.
We have also done some scary experiments with using plug-ins to leverage the spam deletion feature to remove cases.
If you just want to be able to indicate that the information is no longer valid, there is the scratch-out plug-in.
If you truly need to remove information, then removing directly from the database is the only way.
Here's how to do that:
DELETE FROM Attachment
WHERE ixBugEvent IN (SELECT ixBugEvent FROM BugEvent WHERE ixBug = 1234);
DELETE FROM BugView WHERE ixBug = 1234;
DELETE FROM BugEvent 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 Bug WHERE ixBug = 1234;
|
|
|
|
3
|
|
edited May 4 2010 at 19:37
|
Here is the current state of play for permanent case deletion.
The reasons we haven't heretofore provided case deletion are several. What it boiled down to was that a decent segment of our customers require full auditability, so preserving case history was essential to them. Enabling deletions would shut us off from a segment of potential customers, and was not a dealbreaker very often. In cases where it was, we could always recommend a workaround (direct deletion). So, in short, there was not much incentive to enable deletion through the interface.
Early versions of Gmail didn't offer deletion, just archiving, and users rebelled. They wanted to be able to delete the email. Google said that archiving and deleting were basically the same thing. Eventually, Google relented. Eventually, Fog Creek will do deletions.
There is no interface for deleting cases. If you run FogBugz on your own server, you can go in the database and delete them directly, but it is not recommended or supported. Here is a post on removing problematic info.
We recommend simply closing cases with a note, or as a duplicate of the correct version. You can move them to a special project you can create just for sequestering data, say "Deleted data" or "Sensitive data" and set the permissions so only admins can view it. That way the cases won't be readable by other users or even come up in searches. We plan to deliver a sequestration plug-in at some point.
We have also done some scary experiments with using plug-ins to leverage the spam deletion feature to remove cases.
If you just want to be able to indicate that the information is no longer valid, there is the scratch-out plug-in.
If you truly need to remove information, then removing directly from the database is the only way.
Here's how to do that:
DELETE FROM Attachment
WHERE ixBugEvent IN (SELECT ixBugEvent FROM BugEvent WHERE ixBug = 1234);
DELETE FROM BugView WHERE ixBug = 1234;
DELETE FROM BugEvent 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 Bug WHERE ixBug = 1234;
|
|
|
|
2
|
|
edited Feb 5 2010 at 19:51
|
Here is the current state of play for permanent case deletion.
The reasons we haven't heretofore provided case deletion are several. I will go into What it boiled down to was that a decent segment of our customers require full auditability, so preserving case history was essential to themin . Enabling deletions would shut us off from a later edit segment of this questionpotential customers, and was not a dealbreaker very often. In cases where it was, we could always recommend a workaround (direct deletion). So, in short, there was not much incentive to enable deletion through the interface.
Early versions of Gmail didn't offer deletion, just archiving, and users rebelled. They wanted to be able to delete the email. Google said that archiving and deleting were basically the same thing. Eventually, Google relented. Eventually, Fog Creek will do deletions.
There is no interface for deleting cases. If you run FogBugz on your own server, you can go in the database and delete them directly, but it is not recommended or supported. Here is a post on removing problematic info.
We recommend simply closing cases with a note, or as a duplicate of the correct version. You can move them to a special project you can create just for sequestering data, say "Deleted data" or "Sensitive data" and set the permissions so only admins can view it. That way the cases won't be readable by other users or even come up in searches. We plan to deliver a sequestration plug-in at some point.
We have also done some scary experiments with using plug-ins to leverage the spam deletion feature to remove cases.
If you just want to be able to indicate that the information is no longer valid, there is the scratch-out plug-in.
If you truly need to remove information, then removing directly from the database is the only way.
|
|
|
|
1
|
|
answered Sep 10 2009 at 17:03
|
Here is the current state of play for permanent case deletion.
The reasons we haven't heretofore provided case deletion are several. I will go into them in a later edit of this question.
There is no interface for deleting cases. If you run FogBugz on your own server, you can go in the database and delete them directly, but it is not recommended or supported. Here is a post on removing problematic info.
We recommend simply closing cases with a note, or as a duplicate of the correct version. You can move them to a special project you can create just for sequestering data, say "Deleted data" or "Sensitive data" and set the permissions so only admins can view it. That way the cases won't be readable by other users or even come up in searches. We plan to deliver a sequestration plug-in at some point.
We have also done some scary experiments with using plug-ins to leverage the spam deletion feature to remove cases.
If you just want to be able to indicate that the information is no longer valid, there is the scratch-out plug-in.
If you truly need to remove information, then removing directly from the database is the only way.
|
|
|