View Issue Details

IDProjectCategoryView StatusLast Update
0008134mantisbtpreferencespublic2011-08-29 07:05
Reporteropi Assigned To 
PrioritynormalSeverityminorReproducibilityalways
Status closedResolutionduplicate 
Product Version1.0.8 
Summary0008134: it's not possible to delete own attachments
Description

Hi

If a user upload a wrong File and he want to fix the
mistake and delete the file and upload the correct File
it's not possible to delete own attachments because
it seems that you must also the reporter of the Issue
too to delete delete own attachments.
(also if i set $g_allow_delete_own_attachments = ON)

IMHO it should always possible to delete own attachments
if the configuration setting is enabled.

It would be very nice if you can add that feature.
It save a lot of work for the admin because some stupid
users permanent upload wrong files and send then a delete
request to the admin. :-(

Best Regards
Frank (Opi) Weber

TagsNo tags attached.

Relationships

duplicate of 0012553 closeddhx Mantis user can not delete their own attachments 
related to 0007835 new Add "Has patch" flag to improve usefulness of the "Upload File" feature 

Activities

vboctor

vboctor

2007-07-11 00:30

manager   ~0014921

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.

giallu

giallu

2007-07-11 06:45

reporter   ~0014925

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.

opi

opi

2007-07-11 07:06

reporter   ~0014927

I think the DB should extended and store the author of the attachment too
and allow a user to delete his own attachment.
it's also an security issue. If a user Upload a file with sensible Data
by accident (e.g. Passwords) he can't delete the data. the chance that
other users can see the data is reletive low if he immediately delete the wrong file.

vboctor

vboctor

2007-07-11 10:53

manager   ~0014930

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.

smig1o

smig1o

2008-02-27 12:30

reporter   ~0017208

I've added this field as user_id. All will be posted in patch for bug 7835

giallu

giallu

2008-02-27 19:24

reporter   ~0017211

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.

smig1o

smig1o

2008-02-28 03:10

reporter   ~0017213

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<.
Later (stage 2 I guess) I'll add a filter that will seach such abandomed files as well as patches and obsolete ones.

vboctor

vboctor

2008-03-14 01:51

manager   ~0017337

  1. On upgrade we should mark the user id as 0.
  2. In the case where user id is 0, the displayed user id should be user0 or blank.
  3. If a user with id = 5 and user name xyz adds a file, the displayed name should be xyz. If this user is disabled, then we strike through, if the user gets deleted, then user5 is displayed. This behavior is consistent with other places like issue reporter, note reporter. Please double check to make sure we are consistent.
dhx

dhx

2009-10-26 07:30

reporter   ~0023328

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.

XanaduNWH

XanaduNWH

2010-03-08 21:49

reporter   ~0024677

It will cause heavy querys if do a lookup from history_table to determines attachment's owner?

cas

cas

2010-03-09 21:48

reporter   ~0024689

Why can we not move all data of a deleted user to admin and/or another user in the system.
I have created a plugin that allows to transfer such ownership (syncuser).
In that way, we always have an owner, 'user5' makes no sense to me.

Renegade

Renegade

2011-06-17 13:35

reporter   ~0029036

Isn't this fixed through duplicate bug:12553?

rombert

rombert

2011-06-19 05:26

reporter   ~0029039

Seems to be the case, thanks for reporting.

rombert

rombert

2011-06-19 05:26

reporter   ~0029040

Seems to be the case, thanks for reporting.

Issue History

Date Modified Username Field Change
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