[ENG-8186] Storage allocation for draft registrations

[ihorsokhanexoft]

SHOULD BE MERGED AFTER ENG-8048 WHICH CONTAINS ADDONS FIX THAT IMPACTS DISK USAGE CALCULATIONS IN ARCHIVER

Purpose

Admins should be able to configure storage limits for individual draft registrations

Changes

Updated draft registration admin page, added one field to DraftRegistration model, take into account draft registration storage limits when archive registration
Updated an email template to insert draft registration storage limit

Notes:

1. MAX_ARCHIVE_SIZE can be removed from defaults.py on envs when it's deployed
2. User tags are still used to provide users an unlimited storage

Ticket

https://openscience.atlassian.net/browse/ENG-8186?atlOrigin=eyJpIjoiYzM0ODM1ZWRhOWMzNGY0OGFiNzZkMWM2M2FkN2JmOTQiLCJwIjoiaiJ9

[brianjgeiger]

A little more involved than I was expecting, but it looks like it should work. One question: does the draft registration inherit the custom storage allocation value from the node that it's being registered from? If not, it probably should.

[ihorsokhanexoft]

A little more involved than I was expecting, but it looks like it should work. One question: does the draft registration inherit the custom storage allocation value from the node that it's being registered from? If not, it probably should.

Actually it's just two new fields in DraftRegistration and updating archiver logic to use these fields or default limits. More like refactoring of tests/admin functionality + new tests + fixing email templates to use new limits than actual implementation (still in discussion with Mark)

Regarding inheritance, no, it doesn't inherit limits from its node. It has been 5 GB for all registrations all this time regardless of custom storage limits of their node, so maybe we missed it in the ticket requirements. Should we do that now or it's better to ask product team about it?

[brianjgeiger]

Regarding inheritance, no, it doesn't inherit limits from its node. It has been 5 GB for all registrations all this time regardless of custom storage limits of their node, so maybe we missed it in the ticket requirements. Should we do that now or it's better to ask product team about it?

Since we're using the same fields that the node uses, rather than having a completely different setup for draft registrations, I personally think it makes sense to inherit the custom storage limits from the node. Please check with Product to see if they agree.

[ihorsokhanexoft]

Regarding inheritance, no, it doesn't inherit limits from its node. It has been 5 GB for all registrations all this time regardless of custom storage limits of their node, so maybe we missed it in the ticket requirements. Should we do that now or it's better to ask product team about it?

Since we're using the same fields that the node uses, rather than having a completely different setup for draft registrations, I personally think it makes sense to inherit the custom storage limits from the node. Please check with Product to see if they agree.

Got the answer: No. We plan to separate projects and registrations in the near future. It's best if we prepare for that.

[ihorsokhanexoft]

Got new requirements from product team. Draft registration should have only one limit that is applied regardless of the draft registration privacy

[brianjgeiger]

Overall, looks good. Just one question about an edge case.

[ihorsokhanexoft]

Admins can't set negative storage limits for draft registrations and nodes

Also I noticed another bug. If admins enter float limits (for nodes/draft registrations), admin templates display only the integer part of limits but these limits are saved correctly. Should I create a ticket in JIRA for it or spend some time on editing templates?