warn about deleting other peoples' tables

[MichaelCoulter]

it would be great to display the team name associated with the tables when you are trying to delete tables. this might help people accidentally delete other peoples' tables. for example, this can be a problem when a set of parameters is used by multiple people.

[dpeg22]

This could look similar to the extended delete method SpikeSorting.

[lfrank]

This would be great, but has to be done by modifying every table to include a custom delete method, and unfortunately the custom delete methods don't get called when deleting downstream tables.

An easier current solution would be for people to make their own tables (e.g. mcoulter_spikesorting) and add their sorts / other entries to those tables, as only the owner and potentially other specific team members can delete tables like this.

[MichaelCoulter]

@khl02007 just reminding you about this issue

[edeno]

@CBroz1 If you have any thoughts about this issue in the future (doesn't have to be now), that would also be great.

[CBroz1]

A couple things come to mind, each with pros and cons...

1. Forking datajoint to inject a custom delete protocol.

• Pro: custom delete behavior with minimal spyglass edits
• Con: huge maintenance overhead with merge conflicts, and end-user custom installs

2. Revising MySQL permissions around prefixes. For example, only admin may declare/delete the prefix for stable pipelines and users may only declare/delete on their username prefix.

• Pro: database security with permission escalation, and making notions of 'finished' vs 'in-flux' tables explicit
• Con: database migration

3. Adding a helper function in utils for a cautious delete that spits out upstream info before confirming a delete

• Pro: Easy to implement
• Con: unenforceable

If I understand the status quo correctly, I would be very much in favor of 2

[edeno]

Given the hassle of database migration, I think we should at least try the third option first and see if it works well enough. It might not be the long term solution, but worth a shot in the short term. @CBroz1 I will assign this issue to you and then at some time in the next month could you try submitting a PR for it?

[CBroz1]

I'll clarify that I'm not certain migrating would be required. Renaming in place might be feasible, but there may be other issues.

Certainly, happy to develop a helper function to this effect

[MichaelCoulter]

thanks chris. it would be great for the cautious delete statement to display the number of rows potentially deleted in each table grouped by "team_name" for the tables that have that key.

[CBroz1]

Looking into this more, it looks like each Session is associated with an experimenter, who can be on one or more teams. I can return all of the teams associated with the individual linked to the data, but that seems cumbersome

@edeno What do I need in order to have permission to delete? Do I need to (a) be the experimenter assoc. w/the session, or (b) be on at least one team with the session experimenter? Is (a) the default, but (b) requires a force flag? Or is (b) the default and delete any requires the extra flag?

I think the best possible implementation of this would require some surgery to link a session not to an individual but a team, but that would take some doing

[CBroz1]

🥳 🎉 Progress #711