Bring credential delete in line with new GDPR interpretation

[taylordowns2000]

When a user requests to deletes a credential:

• project_credentials are deleted (audit trail event)
• any jobs using that credential are set_null (audit trail event)
• runs with that credential_id DO NOTHING and should block the deletion of the credential until they are removed.

Full deletion planning doc here.

[taylordowns2000]

@elias-ba , could #1072 be related to this? (if so, maybe the way to solve that bug is to implement this ticket?)

[taylordowns2000]

@elias-ba , i've just had a look through the delete rules from the planning doc

1. For legal reasons, we have to prioritize PROJECT DATA above USER DATA			
2. 	So if the OWNER of a project wants to delete project data		
3. 		And the SUPERUSER (the person in charge of the whole installation) allows it
4. 		THEN IT GETS PURGED. (after N days, based on the installation setting. or never, if set to 0 for legal reasons.)			
5. 	But if the OWNER of a USER RECORD (i.e., a user) wants to erase their own user record and all their related activity		
6. 		THEY MAY NOT BE ABLE TO, UNTIL.....	
7. 			ANY ASSOCIATED PROJECT DATA (invocation_reason, run.credential_id)
8. 		SCHEDULED DELETION DATE PASSES	
9. 			The delete for that USER fails, and we try again tomorrow.
10. 		LATER	
11. 			Maybe the runs have expired and been cleaned
12. 			Maybe the superuser has deleted that activity
13. 			Maybe the project and all assocaited activity has been deleted.
14. 			And if so, then the delete succeeds.
15. 			If not.... we try again tomorrow.
16. 		WHILE IT IS CAUGHT IN LIMBO...
17. 			Logins are not allowed

So I think your current testing is all good. If the super says yes, this project can be deleted then all associated activity gets cascaded.

[elias-ba]

@elias-ba , i've just had a look through the delete rules from the planning doc

1. For legal reasons, we have to prioritize PROJECT DATA above USER DATA			
2. 	So if the OWNER of a project wants to delete project data		
3. 		And the SUPERUSER (the person in charge of the whole installation) allows it
4. 		THEN IT GETS PURGED. (after N days, based on the installation setting. or never, if set to 0 for legal reasons.)			
5. 	But if the OWNER of a USER RECORD (i.e., a user) wants to erase their own user record and all their related activity		
6. 		THEY MAY NOT BE ABLE TO, UNTIL.....	
7. 			ANY ASSOCIATED PROJECT DATA (invocation_reason, run.credential_id)
8. 		SCHEDULED DELETION DATE PASSES	
9. 			The delete for that USER fails, and we try again tomorrow.
10. 		LATER	
11. 			Maybe the runs have expired and been cleaned
12. 			Maybe the superuser has deleted that activity
13. 			Maybe the project and all assocaited activity has been deleted.
14. 			And if so, then the delete succeeds.
15. 			If not.... we try again tomorrow.
16. 		WHILE IT IS CAUGHT IN LIMBO...
17. 			Logins are not allowed

So I think your current testing is all good. If the super says yes, this project can be deleted then all associated activity gets cascaded.

Awesome @taylordowns2000 thanks for the clarity.