No this is literally just a column that gets added to the CSV because it exists in the /assets/[type]
page. See the checkboxes in the left column of all asset lists? That gets included in the CSV export, simply because both are generated from the same Views configuration.
I see, @mstenta, thanks for explaining thatā¦ But that leaves unanswered the question of how best to roll-back a bulk update that somehow goes wrong. Any suggestion(s) about how to do this?
A bulk-DELETE cannot be rolled back. When records are deleted in farmOS they are gone forever. (Weāve talked about making it impossible to outright delete records, and instead just āmark them as deletedā for this exact reason.)
The only easy way to ārollbackā is to restore from a database snapshot. Farmier hosting doesnāt offer a push-button way of doing this (yet).
Ideally, you would have a local instance of farmOS that you are testing against, to avoid accidents on your production database. With great power (API + Python scripts) comes great potential for destruction!
Wouldnāt that be nice? Haha unfortunately there isnāt an easy way. And as @mstenta said, once they are deleted, you cannot undo that.
That said, once upon a time I did add a little feature to one of my import scripts to āundoā. But it is severely limited. It only works when you are creating new entities, not modifying or deleting. Basically I just saved the ID of every record I created and at the end of the script it would prompt if I wanted to āundoā. Then it would go through and delete all of those records. This was really just a time saver for development, not something I would recommend in production.
+1 - start with a small set of test data, ideally using a debugger to walk through isolated parts of your script during development, and then finally test with your full set of data before sending it to the production database