Whoever wrote the pop-up tooltips in the SSC for the artifact DELETE and PURGE button needs to realize that the details fall into a framework known only to the developers of the product. A user of the product needs to know the difference between the two buttons, but none of the described properties in the tooltips match against each other between the two buttons.
Thanks, but this text seems similar to what I see in the tooltips of the 18.20 SSC.
Just providing details does not explain the difference. It's as if someone asked a question, "what's the difference between apples and oranges?" and received an answer, "well, apples have thin skin and oranges have a soft core". The answer looks internally (locally) consistent but does not always address the purpose of the question. The person asking it maybe interested in an attribute (dimension) to which both objects relate. For example, "how thick are their skins?" or "how soft are their cores" or "how do these two measure in taste?" or "do they have pits?". So what I would expect as a good answer reads "Apples have thin tight skin but oranges have thick peeling skin" or "Apples often taste more sour than oranges but it depends on the person, apples and oranges".
Reading the generalized answer, "undo upload" vs. "recover space" sends me into a thrill of rage. Obviously, undoing upload recovers space and vice versa. Removing "any trace" of the artifact purges it, n'est-ce pas? This also removes "cross-references". Giving directions to the user where explanation (description) is expected is just a blatant abuse of style. Saying that SOME purged artifacts cannot be deleted after the purge operation just adds confusion. Is this a reference to an internal limitation?
Then let's turn the question around, what are you looking to do? What are you wanting to accomplish? This will allow us to recommend which would be better in your situation.
As a user/admin of Fortify SSC I have little regard for artifact history.
On the other hand, I want SSC to take care of the disk space. For example, instead of introducing the DELETE/PURGE dichotomy, get rid of both and present a radio button in the Administration section,
(*) Automatically purge the oldest artifacts when free disk space reduces to 5% of the entire volume.
( ) Turn SSC into a read-only mode once the free disk space reduces to 5%.
On a related note, consider the backup/recovery needs with SSC. In my SSC usage scenario, we publish new static scans automatically from build machines as part of continuous integration. In this usage, I would prefer backing up just the manual entry work (issue suppression and comments) to backing up the entire database that takes half-hour and tens of gigabytes. This could look as easy as a pair of buttons in the Administration section and a pair of calls in the API,
[Save issue suppressions in all project versions]
[Load and merge issue suppressions with all project versions]
Now that I shifted concerns from artifacts to suppressions, why not consider a desperate need for automatic propagation of issue suppressions across versions of a project? This could look as simple as a checkbox in the Administration section,
[x] Automatically propagate issue suppressions
If the issues are identified via a hash of the non-blank source code lines surrounding the data flow, the above propagation could stretch as far as other project names.
I have a different use case but also need to better understand what a purge leaves behind in the DB (vs a delete which should remove all traces of the artifact).
I have 8 years of artifacts and have to implement a data retention program so I need to start deleting artifacts that fall outside of the retention window. I've been testing this and after SSC chews on the delete request for a couple of days it throws an error. The result is that I may have to fallback to purge for this.
I can see that some tables have records related to the purged artifact are updated but I don't know what else I have to go in to cleanup post-purge to completely remove the artifact. Where else should I look?
The issue here isn't space reclamation but removal of all traces of the artifact.