Managing obliteration

[TBiker]

Hi Folks,

Currently using VAULT 3.0.7.

Our engineers would really like to be able to mark a set of files for obliteration, not simply deletion (like you could do with SOS Collab). We are finding that a huge number of files get mistakenly added to VAULT over time, then they are deleted, contributing to a massive list of files to obliterate. There is no way we can afford to go through the obliteration list in the VAULT Admin tools to effectively know which item should be permanently removed and which should be kept so we can recover history. Please add this feature.

Terry

[lbauer]

You'd like users to be able to obliterate directly from the Vault GUI Client?

I'll log this as a feature request.

[mlippert]

Linda,
While Terry is requesting that they be able to obliterate directly from the GUI client, I think that is only because the current obliterate interface is incredibly bad.

I actually like that obliterate is only available in the Admin Tool. However because the iterface to obliterate is to present one long list of EVERY deleted item in the selected repository, it is an incredibly difficult and tedious task to locate the items that should be obliterated.

In general, if something needs to be obliterated, it was probably recently deleted. Waiting for the list of all deleted items to be populated is annoying, and then searching that huge list for the couple of things that you want to obliterate is also annoying (this doesn't even mention --until now-- that obliterate frequently fails because the operation times out).

I just wanted to mention all this because I suspect that Terry wouldn't be requesting that they be able to obliterate from the GUI client if the obliterate interface in the Admin tool were better.

Mike

[ian_sg]

Mike,

Thanks for that feedback. Obliterate will continue to be improved for the 4.0 release, and this type of information is very useful.

[TBiker]

Hi All,

It's been a while since I posted the original item that started this thread. After reading Mike's comments, I think that improving the obliterate user interface (and its response time) would solve my issue. What is the plan to improve this? The last posting mentions 4.0... when is that release planned? I'm about to commit many hours upgrading (finally) to the new 3.1 database format. Should I wait later?

Terry

[lbauer]

We're currently working on Vault 4.0, which is due out sometime next year. And yes, we're looking at ways to improve obliterate.

[TBiker]

After thinking about your comments and discussing this issue more with users of VAULT, it is not reasonable to visit an "obliteration user interface" (no matter how good) to perform permanent deletion of files later in time. The user generally knows if they wish to permanently remove a file when they delete a file (either because they accidentally added it to VAULT or they know its time to remove forever). The user is the only real person who knows this, not the administrator manipulating some obliteration mechanism later in time. Imagine the thousands of files the administrator would need to distinguish between (those that should stay because they form a legitimate part of a history that needs to be preserved, and those files that need to be removed). Its just not workable. The SOS idea you had earlier was much more appropriate... having a check box in the delete dialog that indicates the file should be permanently deleted so the user can do the right thing... at the right time. My obliteration list in VAULT is now impossible to manage (not to mention, impossibly slow to even bring up under the VAULT Admin Tool!).

Help!

Help now!

Terry

[GregM]

I disagree. When we were using VSS, no regular users had destroy permission. It required a special action to log in as an administrator to do such a thing. There's too much potential for things to go wrong accidentally. Throwing away history is too important to have in the normal interface.

Just because it's in a different place doesn't mean that it has to be "later in time". You're absolutely right, though, that in general it is only right at the point of deletion that one knows whether something should be destroyed or not. So, when a user needs to destroy something permanently, they delete it, and then tell their administrator that the thing that they just deleted should be obliterated as well. The administrator verifies that it really is safe to obliterate, and obliterates it. Other than that, don't touch anything in obliterate.

[TBiker]

If we can trust developers/users to branch, pin, merge, label, etc. --- all functions which require a decent understanding of what's going on, then I believe we can trust them to know the difference between destroying something forever and deleting something for the purpose of preserving version history. You mention that the "destroy" feature needed Administrator priviledge in VSS. I distinctly remember having the destroy check-box in SOS Collab whenever I deleted a file (as part of the confirmation dialog) --- without any special permission.

Typically, administrators are nothing more than the poor user who was elected to take care of things with some of their precious free time. Having them receive emails with lists of files from users who want things obliterated to process later through the Admin Tool is an unrealistic expectation and no different than having the user who made the request do it themselves at the time the file was deleted. Administrators cannot know the right decision of obliteration vs. keeping each and every file in the database. Our databases are > 20 GBytes, with thousands of directories and tens of thousands of files.

[GregM]

None of those actions destroy history. I also never said that they were stupid, just that accidents happen, and people make mistakes. Mistakes with any of the other functions can be fixed. Destroying history can only be fixed by going back to a backup copy of the database, which means that anything else that happened since the last backup is lost. It also requires that the mistake be noticed right away.

Making obliterate a separate action in a different location with different permission required makes it much less likely that accidents will happen. Having it just be a checkbox in the delete dialog makes it FAR too easy to destroy history.

As far as VSS allowing it, there are four categories of things that users are allowed to do in VSS: Read, Change, Add, and Destroy. The only account which had "Destroy" permission when we were running VSS was the admin account (by our choice). Thus, checking that box in SOS would simply inform the user that they didn't have permission to do that.

I've been that administrator for most of the last 10 years, with VSS, SOS, and now Vault, and I absolutely do not want the Vault client to be able to destroy history.

[Don Thimsen]

Thought I'd throw in a few thoughts...

If SG put a permanent delete in the user interface, the next thing that would happen is that I'd get tons of complaints about performance. I heard that SG might improve obliterate in 4.0, but it will never be anything like we've see with VSS.

I don't particularly mind having to use the Admin interface to do obliterates. Having said that, I would like some improvements.

How about allowing the user to make a permanent delete "request" that causes the admin to get notified via email about the request. Essentially, a different level of email notifcation that vault already has. For the installations that don't want or use the current email facility, allow them to turn it on for "permanent deletes only".

It might also be nice to give the person requesting the permanent delete to give some kind of explanation as to why they want to delete a folder that contains 500 files... (ie. let them supply a comment field on the email notfication).

On the actual Obliterate dialog, I'd also like to see a grid layout that includes the number of versions that are being deleted for each file, and who made the permanent delete request. Anything with only one version doesn't bother me at all. If the user wants it back, just re-add the file.
Something with lots of history will usually lead to a few questions... I also tend trust some users much more than others...

Thanks,
Don

[mlippert]

I don't have anything to add, I just want to make my agreement with Don's comments (and with Greg's) known.

Mike

[lbauer]

Good feedback, from all of you. I'll add your suggestions to our "Improve Obliterate" task.

From my perspective in Tech Support, I'd rather we err on the side of preserving data, rather than make it easy to destroy data. That being said, we know Obliterate is frustrating for some of our users and we are working to improve its performance.

[msauper]

What I would like is a change to the vault admin client. I'd like to have a checkbox for each item in the deleted list. What the checkbox would mean is "Schedule file for obliteration". Basically, the vault server would obliterate files in the background during its "idle" period (whatever that means .

Best regards,

Metro.

[lbauer]

Thanks for the suggestion. I'll add it to the Obliterate "wish list."