Revise delete permissions

[nagem]

Changes/things made clear in this PR:

Note: all permissions mentioned are those set at the project level

Project deletion:

• users with admin can delete the project even if it has data (original or not)
• other users cannot delete a project (even if it is empty)

Session/Acquisition deletion:

• users with rw can delete a session or acquisition if it is empty or only contains data uploaded by a job or user (not necessarily themselves)
• users with admin can delete a session or acquisition in any situation
• if an acquisition's file was used as input for an analysis, the acquisition cannot be delete by anyone without deleting the analysis first

Individual File deletion:

• users with rw can delete a file if it was uploaded by any user or a job
• users with admin can delete a file in any situation

A new query param is offered on container DELETE endpoints: check=true/false

• If a client would like to check user permissions before performing an action, they can pass the query param check=true (default false) to only preform a perm check - returning the expected 403/404 failure if the action would not be allowed or 200 with no response body if the action would be allowed

List of permission failure variants:

If the container has "original data" (data not uploaded by a user or job), the API will respond with 'original_data_present' in the reason key:

DELETE api/container_name/container_id?check=true
{
  "status_code": 403,
  "message": "user not authorized to perform a DELETE operation on the container.",
  "reason": "original_data_present",
  "request_id": "fdbe14e5-1520003841"
}

If deleting this container would cause an analysis' input file to be removed without removing the analysis, the API will respond with 'analysis_conflict' in the reason key:

DELETE api/container_name/container_id?check=true

{
  "status_code": 403,
  "message": "Cannot delete acquisition 5a908946123ade00147d00cb referenced by analyses ['5a996cf3cea75600b4f7fba3']",
  "reason": "analysis_conflict",
  "request_id": "8650511c-1520004700"
}

All other permission conflicts (403) will have '{'reason': 'permission_denied'} or will be a different error (404/400, etc)

Tests will be added after above proposal is agreed upon.

[nagem]

@gsfr will you make sure the above proposal is what you were expecting?

[nagem]

Attn: @ryansanford

[gsfr]

LGTM.

[codecov-io]

Codecov Report

Merging #1085 into master will increase coverage by 0.01%. The diff coverage is 94.02%.

@@            Coverage Diff             @@
##           master    #1085      +/-   ##
==========================================
+ Coverage    90.8%   90.82%   +0.01%     
==========================================
  Files          50       50              
  Lines        7029     7092      +63     
==========================================
+ Hits         6383     6441      +58     
- Misses        646      651       +5

[nagem]

I've actually been moving theDELETE responses to a 200 with no response body if the action succeeded and a proper error response if it didn't. The modified is a relic probably caused by it's storage situation - the container was "modified". I'll make the change in the response 👍.

[nagem]

I take that back, we have some clients that do check the modified count and I would prefer for this to not be a breaking change.