Moodle Community Sites

Consider giving jira-developers and/or contrib-developers the Delete own attachments capability

Details

  • Type: Improvement Improvement
  • Status: Resolved Resolved
  • Priority: Major Major
  • Resolution: Fixed
  • Component/s: tracker.moodle.org
  • Labels:
    None
  1. notreal.patch
    22/Jul/09 3:50 PM
    0.0 kB
    Dan Poltawski
  2. notreal.patch
    22/Jul/09 3:49 PM
    0.0 kB
    Dan Poltawski

Activity

Hide
Tim Hunt added a comment -

Added some relevant watchers. I don't know if this is a good idea or not. It's just a thought.

Show
Tim Hunt added a comment - Added some relevant watchers. I don't know if this is a good idea or not. It's just a thought.
Hide
Jordan Tomkinson added a comment -

I dont see why people shouldn't be able to delete own attachments
I have found the relevant Jira settings for this, will wait for enough +1's before I change

Show
Jordan Tomkinson added a comment - I dont see why people shouldn't be able to delete own attachments I have found the relevant Jira settings for this, will wait for enough +1's before I change
Hide
Anthony Borrow added a comment -

Jordan - I forget, if a user deletes the file is it really deleted or could an admin still go back and see it? I know that generally speaking, the constructivist pedagogy does not encourage deleting. One usage scenario where it would be helpful is when a user accidentally uploads something with security information. It would be faster for them to delete their own. However, if a user upload a helpful screen shot that someone was referencing in a forum post then what happens when they delete it. It sort of breaks that discussion. I would give it a -0.5. In other words, I would be slightly against it. What a user can currently do is over write the file. I believe only admins see the history but again I have not played with these details in a while. Peace - Anthony

Show
Anthony Borrow added a comment - Jordan - I forget, if a user deletes the file is it really deleted or could an admin still go back and see it? I know that generally speaking, the constructivist pedagogy does not encourage deleting. One usage scenario where it would be helpful is when a user accidentally uploads something with security information. It would be faster for them to delete their own. However, if a user upload a helpful screen shot that someone was referencing in a forum post then what happens when they delete it. It sort of breaks that discussion. I would give it a -0.5. In other words, I would be slightly against it. What a user can currently do is over write the file. I believe only admins see the history but again I have not played with these details in a while. Peace - Anthony
Hide
Helen Foster added a comment -

I'm in agreement with Anthony that it's better not to allow deletion of attachments. Non-admins are not allowed to delete forum posts (after the deadline), wiki pages etc. History can sometimes be useful.

Show
Helen Foster added a comment - I'm in agreement with Anthony that it's better not to allow deletion of attachments. Non-admins are not allowed to delete forum posts (after the deadline), wiki pages etc. History can sometimes be useful.
Hide
Tim Hunt added a comment -

Anthony/Helen, I don't know if either of you read the developer chat discussion that preceded me filing this feature request. http://moodle.org/mod/cvsadmin/view.php?conversationid=2805#c123849

The situation where it would be very helpful to let people delete their own attachments is when a developer is uploading a patch - or more to the point when they have already uploaded one patch, and then need to upload a revised version. Rinse and repeat a few times, and you end up with a bug with half a dozen patches and it is just a pain to work out which one(s) are still relevant. In this case it would be much better to let developers manage their own patches.

After I had filed this bug, this thing came up in a discussion with Dan http://moodle.org/mod/cvsadmin/view.php?conversationid=2806#c124196 - and I ended up deleting some useless attachments for him.

I had not thought of the use case of people uploading private information then wanting to delete it. That is a good one. however, I am not proposing to let all users do this, just people in the developers group.

I think the benefits of keeping the attachment lists cleaner so we can focus on what is relevant far out-way the tiny risk that people will use this to cause problems be deleting stuff they uploaded themselves.

Show
Tim Hunt added a comment - Anthony/Helen, I don't know if either of you read the developer chat discussion that preceded me filing this feature request. http://moodle.org/mod/cvsadmin/view.php?conversationid=2805#c123849 The situation where it would be very helpful to let people delete their own attachments is when a developer is uploading a patch - or more to the point when they have already uploaded one patch, and then need to upload a revised version. Rinse and repeat a few times, and you end up with a bug with half a dozen patches and it is just a pain to work out which one(s) are still relevant. In this case it would be much better to let developers manage their own patches. After I had filed this bug, this thing came up in a discussion with Dan http://moodle.org/mod/cvsadmin/view.php?conversationid=2806#c124196 - and I ended up deleting some useless attachments for him. I had not thought of the use case of people uploading private information then wanting to delete it. That is a good one. however, I am not proposing to let all users do this, just people in the developers group. I think the benefits of keeping the attachment lists cleaner so we can focus on what is relevant far out-way the tiny risk that people will use this to cause problems be deleting stuff they uploaded themselves.
Hide
Dan Poltawski added a comment -

Additionally we don't really have a problem with 'jira developers' closing or reopening bugs which shouldn't be reopened (although I know that history is stored).

Excuse the noise while I test uploading 2 patches of the same name..

Show
Dan Poltawski added a comment - Additionally we don't really have a problem with 'jira developers' closing or reopening bugs which shouldn't be reopened (although I know that history is stored). Excuse the noise while I test uploading 2 patches of the same name..
Hide
Dan Poltawski added a comment -

Testing patch upload 1

Show
Dan Poltawski added a comment - Testing patch upload 1
Hide
Dan Poltawski added a comment -

Testing patch upload 2 - hoping that this greys out the first one.

Show
Dan Poltawski added a comment - Testing patch upload 2 - hoping that this greys out the first one.
Hide
Dan Poltawski added a comment -

So that test proved that uploading two patches with the same name keeps the most current one 'highlighted', which is a good tip I will have to remember (and add to moodle docs if its not there already) and does eliminate the main reason I voted deletion capability.

Show
Dan Poltawski added a comment - So that test proved that uploading two patches with the same name keeps the most current one 'highlighted', which is a good tip I will have to remember (and add to moodle docs if its not there already) and does eliminate the main reason I voted deletion capability.
Hide
Tim Hunt added a comment -
Show
Tim Hunt added a comment - It does on this page, but not on http://tracker.moodle.org/secure/ManageAttachments.jspa?id=32824
Hide
Jordan Tomkinson added a comment -

What is also quite confusing is the numbering.. I would have thought file 2 was uploaded after file 1, but looking at the upload times this is not the case.

Show
Jordan Tomkinson added a comment - What is also quite confusing is the numbering.. I would have thought file 2 was uploaded after file 1, but looking at the upload times this is not the case.
Hide
Anthony Borrow added a comment -

Thanks Tim for the link to the discussion which I had not seen. If it proves useful I am not opposed to it. I just wanted to mention that deleting is not usually something that we encourage. How does JIRA handle a delete? Is it really deleted or would an admin be able to see the previously uploaded file? This is important when for example I make a mistake and upload the wrong version of something. Usually, as I recall JIRA would remember and give me access to the previous version. So I think we should understand what happens before making any changes. Peace - Anthony

Show
Anthony Borrow added a comment - Thanks Tim for the link to the discussion which I had not seen. If it proves useful I am not opposed to it. I just wanted to mention that deleting is not usually something that we encourage. How does JIRA handle a delete? Is it really deleted or would an admin be able to see the previously uploaded file? This is important when for example I make a mistake and upload the wrong version of something. Usually, as I recall JIRA would remember and give me access to the previous version. So I think we should understand what happens before making any changes. Peace - Anthony
Hide
Jordan Tomkinson added a comment -

Do we have a resolution for this? I would like to close the bug

Show
Jordan Tomkinson added a comment - Do we have a resolution for this? I would like to close the bug
Hide
Helen Foster added a comment -

We've given this issue consideration, and as there hasn't been a huge amount of support for giving developers the delete own attachment capability (only 2 votes) I would recommend we leave things as they are. If a particular issue ends up with lots of attachments, a participant can always request that an admin deletes out-of-date ones.

Show
Helen Foster added a comment - We've given this issue consideration, and as there hasn't been a huge amount of support for giving developers the delete own attachment capability (only 2 votes) I would recommend we leave things as they are. If a particular issue ends up with lots of attachments, a participant can always request that an admin deletes out-of-date ones.
Hide
Tim Hunt added a comment -

Penny wants this too, so reopening because I still think it is a good idea.

Vote, Penny, Vote!

Show
Tim Hunt added a comment - Penny wants this too, so reopening because I still think it is a good idea. Vote, Penny, Vote!
Hide
Helen Foster added a comment -

Penny, if you let me know which attachments you'd like deleted, I'd be happy to help.

Show
Helen Foster added a comment - Penny, if you let me know which attachments you'd like deleted, I'd be happy to help.
Hide
Matt Oquist added a comment -

+1 from me – I was confused by the workings of Jira's file attachments, and I had to bug Penny to find out that I should bug Helen to delete the mess for me. Ew.

The real fix is to improve the file attachment UI (or something along those lines), but in the meantime it would be helpful if people could clean up their own messes.

I do see that it's worthwhile to keep history, but I suspect deletion will be used much more often for appropriate cleanup than for history removal.

Cheers!

Show
Matt Oquist added a comment - +1 from me – I was confused by the workings of Jira's file attachments, and I had to bug Penny to find out that I should bug Helen to delete the mess for me. Ew. The real fix is to improve the file attachment UI (or something along those lines), but in the meantime it would be helpful if people could clean up their own messes. I do see that it's worthwhile to keep history, but I suspect deletion will be used much more often for appropriate cleanup than for history removal. Cheers!
Hide
Martin Dougiamas added a comment -

Yeah +1 from me too. I think devs can be trusted to do the right thing.

Show
Martin Dougiamas added a comment - Yeah +1 from me too. I think devs can be trusted to do the right thing.
Hide
Jordan Tomkinson added a comment -

group jira-developers given permission "Delete own attachment" in all issues
group contrib-developers given permission "Delete own attachment" in CONTRIB issues

Show
Jordan Tomkinson added a comment - group jira-developers given permission "Delete own attachment" in all issues group contrib-developers given permission "Delete own attachment" in CONTRIB issues

Dates

  • Created:
    Updated:
    Resolved: