Updating terms of service with data retention policy (SCP-5792)

[bistline]

BACKGROUND & CHANGES

This updates our terms of service to include language regarding a data retention policy. These new terms only apply to studies in the default billing project, and they have been reviewed & approved by both legal & compliance. The new terms in short:

• There is now a soft cap of 200GB per study
• Private studies can only be kept for up to 1 year, after which they must convert to public or be subject to removal
• Data embargoes have a maximum length of 2 years from creation

When users sign in next, they will be prompted to re-accept the terms of service. There will be a small notification at the top of the screen stating that terms have updated since the last version, and instruct users to scroll down to the bottom in order to review all new terms. Example notification:

Also, the embargo field (i.e. Data release date in the UI) now has a validation in place to prevent dates more that two years after study creation date for public studies. This is enforced both client- and server-side.

Note: there is no enforcement currently for either the private study age or the storage cap. Further downstream work will be required to identify these studies (outlined in SCP-5910).

MANUAL TESTING

1. Boot as normal and sign in
2. Confirm you are redirected to the terms of service page, and that you see the above notification
3. Accept the terms and confirm normal usage is allowed
4. Go to any public study you own and load the settings tab
5. Confirm the date picker for Data release date does not allow a date after two years from study creation
6. Manually enter a date past the validation limit and confirm you see a similar error when saving:
   

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 70.16%. Comparing base (b6847a4) to head (fb8566f).
Report is 34 commits behind head on development.

Additional details and impacted files

@@             Coverage Diff              @@
##           development    #2195   +/-   ##
============================================
  Coverage        70.16%   70.16%           
============================================
  Files              332      332           
  Lines            28197    28252   +55     
  Branches          2422     2377   -45     
============================================
+ Hits             19785    19824   +39     
- Misses            8265     8281   +16     
  Partials           147      147           

Files with missing lines	Coverage Δ
app/controllers/application_controller.rb	69.42% <100.00%> (ø)
app/controllers/profiles_controller.rb	53.00% <100.00%> (+0.47%)	⬆️
app/models/study.rb	81.66% <100.00%> (+0.08%)	⬆️
app/models/tos_acceptance.rb	100.00% <100.00%> (ø)

... and 10 files with indirect coverage changes

[jlchang]

Functional review - manual tests perform as described

Question: Will/should/can there be a way to override the two year-from-creation-date validation? I don't think we have a lot of people creating studies and iterating on analysis with collaborators, but those are the situations where I might expect that, by the time their work is ready for publication, it might already be past the two-year-from-creation-date limit.... If there's an easy way to create an exception (I suppose we could change temporarily change their study creation date and then change it back after the embargo has ended so results in the study_breakdwon spreadsheet aren't wrong forever) it'd be good to have a solution handy so we don't accidentally penalize study owners to take advantage of our "full publication life cycle support" features.

[bistline]

Functional review - manual tests perform as described

Question: Will/should/can there be a way to override the two year-from-creation-date validation? I don't think we have a lot of people creating studies and iterating on analysis with collaborators, but those are the situations where I might expect that, by the time their work is ready for publication, it might already be past the two-year-from-creation-date limit.... If there's an easy way to create an exception (I suppose we could change temporarily change their study creation date and then change it back after the embargo has ended so results in the study_breakdwon spreadsheet aren't wrong forever) it'd be good to have a solution handy so we don't accidentally penalize study owners to take advantage of our "full publication life cycle support" features.

We can do it manually in the database with study.update_attributes(embargo: <date>) or study.save(validate: false), however the user wouldn't be able to update anything about the study (description, view options, etc) while the invalid embargo is in effect. Given that we've had several users write in about wanting to download data that was embargoed for an exceptionally long period of time, I'm more inclined to side with them than with study owners preventing downloads for 5+ years. If we run across a study owner with a valid use case for this, then I'm happy to revisit it and put in a workaround for them.