ericvaandering
commented
10 years ago Comment by wildish on Mon Mar 19 05:55:00 2012
I think one fairly easy way to do this might be to add a new table which maintains an association of 'user or role' -> (site, subscription).
We can then allow people to 'like' or 'unlike' a subscription. When a dataset is to be deleted, the deletion will block if it is still 'liked' by someone.
That someone would have to explicitly unlike the subscription to allow the deletion to proceed.
Several people can like the same subscription, which would mean several people would have to approve its deletion.
We can require that the person who likes the data tags it with one of their roles, instead of their individual identity. This will allow other people with the same role to unlike the subscription and approve the deletion. We would still record which individual tagged the data (and why?).
This still implies quite a lot of work. The schema is easy, but we also need to update the approvals API to act on it, the Data::Subscriptions page to allow liking/un-liking, and the Request::View form and request emails to indicate who/what is holding up a deletion.
N.B. For this to work well, we need Group Managers to be defined in SiteDB, currently there are none. These group managers should then like their own data.
As an added benefit, we can create a small group of people whose sole role is to like custodial RAW subscriptions. They should be physicists, not global admins of PhEDEx, and this should be their only role in PhEDEx.
In fact, I would not allow global admins to override a liked subscription, so they could not delete it without explicit approval. However, I would allow global admins to like data too.
I'd like to hear from *Ops about what they think of this before allocating time for it. What constraints would you impose. E.g. Can anyone like anything (I say yes!)? Only at sites they manage, if they have site roles? Only for data their group owns, if they have group roles? Only allow group managers to like data, or allow site managers too? How do you want to deal with people liking too much data?
Comments welcome...
Original Savannah ticket 92506 reported by None on Tue Mar 13 04:35:45 2012.
Given the policy we have for relval data used by IBs, i.e. not to delete them until the associated releases are deprecated, it's necessary to have the ability to pinpoint data to a certain site so that related files cannot be mistakenly deleted.
Whether the pinpointing is soft (a warning dialog) or hard (actual impossibility to delete) it's not particularly important, what is important is that the operator does not get to delete the data but he / she is forced to ask.
A solution where deleted data is brought back if someone complains does not fulfill the requirements of this feature request, because of the risk of going unnoticed and hence losing the files forever.