New visual state for "purged-but-not-deleted" history items for scratch storage

[natefoo]

Now that we're using "scratch storage" on usegalaxy.org, people are going to start regularly having history items deleted and purged that they did not delete themselves. This is likely to cause some confusion as a dataset that is there one day may be gone the next. A long time ago, the cleanup scripts used to not mark HDAs deleted when purging them so they'd still appear in the history as the user had left them. This was changed to make HDAs follow the same logical progression as all other objects in the DB: first mark deleted, then mark purged.

I propose that we revert to the old behavior (with an above-the-fold purged indicator on history items), although we can add a new column to differentiate between user-deleted and admin-deleted if we want to retain the logical ordering of deleted -> purged.

We could also add an additional annotation to the object store config that indicates how many days data are kept in that particular backend, which would allow for additional visual indication that a history item's days are numbered. Currently the only place you specify this in a non-descriptive way is as an argument to the pgcleanup script, so there's no direct way for Galaxy to know this.

[nsoranzo]

I like the idea of using the object store config, in particular we could display an "expiry date" for each dataset. With that information shown, it's not that important for a user to know if an expired and purged dataset was deleted by them or by an admin script.

[mvdbeek]

From backend meeting, track who and why a dataset was deleted or purged. Purged but not deleted seems ok to use as a visual indicator. yes to formally track cleanup time on object store config.

[natefoo]

Purged but not deleted seems ok to use as a visual indicator.

Was this discussed from a technical level (i.e. what columns we should use)?