Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Author can "delete" any article file from the do_revision view #1617

Open
mauromsl opened this issue Jun 9, 2020 · 5 comments · May be fixed by #2255 or #4366
Open

Author can "delete" any article file from the do_revision view #1617

mauromsl opened this issue Jun 9, 2020 · 5 comments · May be fixed by #2255 or #4366
Assignees
Labels
bug Something's not working good first issue An issue that can be addressed by anyone working in the project for the first time. size S Small

Comments

@mauromsl
Copy link
Member

mauromsl commented Jun 9, 2020

Describe the bug
From the do_revision view, authors can delete previously uploaded files. The files themselves are not deleted, but rather unlinked from the article object.
There are no permissions checked against the file before it gets "deleted" so the author could tweak the posted file_id and potentially "delete" any file in the article

Janeway version
v1.3.8

To Reproduce
Steps to reproduce the behavior:

  1. Get an article to the review stage and request revisions for it
  2. As an author, access the revision request
  3. Tweak the file_id to any file id link to the article which the author shouldn't have access to (e.g. a review file)
  4. File gets "deleted"

Expected behavior
There should be form validation, in this view, ensuring the author can only "delete" their own files
Bonus points: Rename file.delete_file to something that actually describes the function behaviour.

Screenshots
If applicable, add screenshots to help explain your problem.
image

@mauromsl mauromsl added bug Something's not working good first issue An issue that can be addressed by anyone working in the project for the first time. labels Jun 9, 2020
@ajrbyers ajrbyers added this to the 1.3.9 - YAR milestone Jul 13, 2020
@ajrbyers ajrbyers added the size S Small label Sep 9, 2020
@ajrbyers ajrbyers removed this from the 1.6 - YAR milestone Jun 15, 2021
ajrbyers added a commit that referenced this issue Jun 15, 2021
@StephDriver StephDriver self-assigned this Dec 19, 2023
@StephDriver
Copy link
Contributor

Reviewing this as I was about to implement it, I wonder what the use-case is for an author to be able to delete (even when meaning to disassociate) a file from the article.

  1. if they have uploaded an incorrect file, then they will want to actually delete it, not leave it somewhere in the system unassociated with this article. This functionality does not currently exist, and this issue doesn't suggest it be added.

  2. therefore, if the file is not incorrect, but a part of the history, why would the author need to disassociate it? Surely it should stay associated with the article, unless an editor wishes otherwise?

Could the original issue be resolved by simply removing the delete button from the author's view of the page, so that they can't disassociate any of the files?

@ajrbyers
Copy link
Member

I think the main issue here is that they can do it to any file, not just the ones they have access to.

@StephDriver
Copy link
Contributor

But should they be able to disassociate any file in the first place?

What reason would they have to be able to do that to any file?

@ajrbyers
Copy link
Member

The most obvious example to me would be if a figure file had been removed from the MS they'd want to remove the record in Janeway.

@ajrbyers
Copy link
Member

ajrbyers commented Sep 6, 2024

Note from pair session: The draft PR (#4366) appears to be working. To test it:

Create a revision request
Attempt to delete a non-presented file
Also check that presented files can still be deleted and downloaded as this was also changed

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something's not working good first issue An issue that can be addressed by anyone working in the project for the first time. size S Small
Projects
None yet
3 participants