Deleting workitems

This issue keeps coming up in forums and discussion lists. In V1, there isn’t a way exposed to delete workitems. Richard Berg pointed out a workaround that I hadn’t thought of before: Denying permission to everyone for those workitems will achieve same effect as deleting workitems (assuming diskspace is not an issue). An easy way to do it is to create a “Deleted” area path node with Deny access to everyone (TFS Valid users) for Viewing and editing workitems in that node. Now those workitems will not show up in queries and trying to view it will give an error. A large number of workitems can be moved to such node “en masse” by exporting to excel and changing area path.

Another common suggestion given out is to have a “deleted” state for the workitemtypes and moved the workitem to that state. This however means they will show up in queries etc.

Why don’t we have this feature? Steve in our team pointed out that it is because of Sarbanes-Oxley compliance (what is that? here is some info). Basically for auditing purpose we do not want to destroy data. However, if the project itself is deleted, all work item data is deleted – that is the only way for now to delete workitems.

How about deleting fields to remove that data? Seems like it will delete field data, but actually that data is archieved somewhere for auditing purpose even when field gets deleted physically. So if you made a bad comment in a field, there isn’t really an easy way to remove that data, good for those who want data to be auditable, bad for you 🙂

On the other hand, we hear that lots of unnecessary data gets collected because these could be any workitems, and I believe this will be revisited for future. Probably archieving or admin-only delete for specific workitemtypes might be few options.

When users badly need to delete the workitem data, many have come up with sql scripts to basically delete workitems from all workitem related tables, but I would like to point them this post on issues with modifying database directly: – Also, no support is available when such direct database modification is done.

Update on 6/5/2007: We hear customer feedback and we are working on a powertool to enable deleting of work items.

Update on 9/12/2007: We built backend work in Orcas release of VS such that we could release a powertool to support deletion of workitem instances and workitem type itself. So this looks more promising.

Comments (7)

  1. My VSTS Blog says:

    I read a post this morning from Naren where he talks about deleting workitems . As he states this is

  2. runezzo says:

    What on earth does Sarbanes-Oxley compliance have to do with a development tool? I could understand if it was a acounting system… you americans are getting way out of line 🙂 also if you are so keen on following those stu… rules, then you should at least allow european versions the priviledge of deleting work items as we in europe built our societies on trust.

  3. narend says:

    Runezzo, I agree that forcing this compliance on everyone may not be appropriate. We do need to think about allowing deletes for future and this is one of feature requests being discussed for future releases.

  4. Essa é uma outra dúvida muito comum. Frequentemente as pessoas se deparam com uma situação em que precisariam…

  5. Joerg says:

    I just think this is a serious limmitation and not acceptable. I  am as a customer shoudl be able to make my own decission. I dont need a nany – my 2 Cents

  6. Benjy says:

    Well, it looks like you have forgotten to account for one thing, namely, mistakenly created workitems. I recently started experimenting with the MSProject integration and accidentally published all summary tasks into TFS (going via excel as i didnt have the add-in for MSP). Now i cannot delete them!!!

    Anyway, the deleted area looks like a decent workaround for me and a future powertoy would be good.

  7. eidermauricio says:

    ¿If I assign the WI to the delete area the Remaining Work Report will not show them too?