Deleting objects

[stuartcampbell]

Hi, I am probably being stupid, but I couldn't see how to delete an action, or other objects (e.g. samples) ?

Am I missing something obvious ?

[FlorianRhiem]

Hey @stuartcampbell,

you did not miss anything, SampleDB does not allow deletion of objects (e.g. samples, etc) and things tightly related to objects (such as actions, instruments). One of the core purposes of SampleDB is that it serves as a long-term archive for research metadata, so when designing what should and shouldn't be possible, we decided that while it must be possible to fix errors, it should not be possible to completely remove the metadata for a sample, measurement, etc that's been entered into SampleDB before, and that even when an error is fixed it should be possible to see the complete history of what's been entered.

Let's say a researcher performs a measurement, enters it into SampleDB and then realizes a little too late that it is, in-fact, entirely useless and cannot provide useful information even as a failure. In that case, they should explain it in the measurement's comments. If they feel bothered by this entry and perhaps don't want it to come up when they search for measurements later, they can remove their own permissions for it. That way only administrators will have access to the information, and that's the closest to deleting an object SampleDB allows.

[stuartcampbell]

I agree about not letting researchers delete in order to preserve. My comment was more for administrators that made a mistake in creating something that was useless. But maybe this could be handled by an example of how you would delete this from the database directly, as it will (hopefully) be a rare thing that is needed and its only admins who have access to the database who will be doing it.

[FlorianRhiem]

If an administrator created an instrument or action by mistake, my recommendation would be to set it to be hidden from lists, and perhaps use it later on when they actually need a new instrument or action. I'm quite reluctant when it comes to suggesting administrators perform changes directly in the database, due to all the things that could potentially go wrong.