View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0008134||mantisbt||preferences||public||2007-07-09 05:50||2011-08-29 07:05|
|Summary||0008134: it's not possible to delete own attachments|
If a user upload a wrong File and he want to fix the
IMHO it should always possible to delete own attachments
It would be very nice if you can add that feature.
|Tags||No tags attached.|
I had a look at the code and it seems that you are correct. When the decision is made about whether a user can view, download, or delete an attachment, the report of the issues, rather than the submitter of the attachment is used.
This should be fixed.
The problem is that the author of the attachment is not stored in the DB, so there is no way to implement that kind of check.
Moreover I think that the "delete" operation, which is a undoable, should be really avoided and eventually permitted only to a user with an high level access (MANAGER or something like that)
I propose to implement the "is_obsolete" flag as suggested in 0007835, so that users can mark the attachments as obsolete and be done with it.
I think the DB should extended and store the author of the attachment too
I believe that the admin should be able to configure the system so that users can delete their own attachments or not, what is what we are doing now but we have a bug in the logic.
I agree with "opi" that there are scenarios where it makes sense to allow the users to delete their own attachments.
I also think it would be useful to capture the name of the attachment submitter and display it next to the attachment. We can also use the same information to implement the access check correctly.
Hence, I believe that we should extend the schema to store the submitter.
I've added this field as user_id. All will be posted in patch for bug 7835
Victor, this calls for a decision about what to do on upgrades.
If we don't try to assign correct user_id to attachments (we could infer from history) we will have a bunch of attachments with user_id = 0.
IMHO, this can be acceptable and allowing only users above can_delete_threshold to delete attachments with user_id = 0 we basically have the current behavior.
I was going to say the same. Same situation (user_id=0) will appear during user deletion. All his files will get user_id=0 so they will be >abandomed<.
We can get the author of attachments based on mantis_history_table... just do a lookup from newest to oldest entries to determine who currently owns a file attached to a bug.
But Victor is ultimately correct in saying that user ID = 0 (or -and this is important- an ID that no longer exists) should be handled correctly. If an owner of an attachment is removed from the Mantis DB, the attachment owner should just be reverted to blank/no-one, thus requiring a user who meets the existing attachment delete threshold.
It will cause heavy querys if do a lookup from history_table to determines attachment's owner?
Why can we not move all data of a deleted user to admin and/or another user in the system.
Isn't this fixed through duplicate bug:12553?
Seems to be the case, thanks for reporting.
Seems to be the case, thanks for reporting.
|2007-07-09 05:50||opi||New Issue|
|2007-07-11 00:30||vboctor||Note Added: 0014921|
|2007-07-11 00:30||vboctor||Status||new => confirmed|
|2007-07-11 00:31||vboctor||Target Version||=> 1.1.0|
|2007-07-11 06:38||giallu||Relationship added||related to 0007835|
|2007-07-11 06:45||giallu||Note Added: 0014925|
|2007-07-11 07:06||opi||Note Added: 0014927|
|2007-07-11 10:53||vboctor||Note Added: 0014930|
|2007-10-21 20:29||vboctor||Target Version||1.1.0 => 1.2.0|
|2008-02-27 12:30||smig1o||Note Added: 0017208|
|2008-02-27 19:24||giallu||Note Added: 0017211|
|2008-02-28 03:10||smig1o||Note Added: 0017213|
|2008-03-14 01:51||vboctor||Note Added: 0017337|
|2008-07-12 18:19||giallu||Target Version||=> 1.2.0|
|2009-05-04 14:27||siebrand||Target Version||1.2.2 => 1.x.x|
|2009-10-26 07:30||dhx||Note Added: 0023328|
|2010-03-08 21:49||XanaduNWH||Note Added: 0024677|
|2010-03-09 21:48||cas||Note Added: 0024689|
|2011-06-17 13:35||Renegade||Note Added: 0029036|
|2011-06-19 05:26||rombert||Note Added: 0029039|
|2011-06-19 05:26||rombert||Relationship added||duplicate of 0012553|
|2011-06-19 05:26||rombert||Note Added: 0029040|
|2011-06-19 05:26||rombert||Status||confirmed => resolved|
|2011-06-19 05:26||rombert||Resolution||open => duplicate|
|2011-06-19 05:26||rombert||Description Updated||View Revisions|
|2011-08-05 02:50||atrol||Target Version||1.3.0-beta.1 =>|
|2011-08-05 02:50||atrol||Description Updated||View Revisions|
|2011-08-29 07:05||atrol||Status||resolved => closed|