Review / cleanup package related code around Restrict and Delete
Nobody has claimed this yet.
- Dominant language
- Java
- Stars
- 1.1k
- Forks
- 564
- Avg merge
- 2d 2h
- Merged PRs (30d)
- 29
Description
In #7081, we managed to simplify some of the rendering related to package files. Namely:
- Allow restrict of package files (unless public install) - previously for non public installs, there was a check related to package files / s3 storage, but we decided it was no longer needed
- Allow delete of package files (after publish) - previously delete was only allowed for unpublished files
We need to review other areas of the code to make sure this simplified logic is consistent (e.g. editfiles fragment and/or APIs)
Note: We checked in with @pameyer for whom this logic was originally intended and he was fine with the change (in his case the sbgrid installation is a public install, and he curates all datasets, so can reject draft versions that attempt to delete files from versions when they should not.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by reading the changes in #7081, then inspect the editfiles fragment and the related APIs for restrict and delete handling. Compare their package-file and S3-storage logic with the simplified behavior described here. Done means the relevant paths consistently allow restriction and post-publish deletion where intended.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- aws, java
- Domain
- api, backend
- Issue type
- Refactor
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100