[patch] Add more control over attachments for the average user

[cboos@…]

Currently, the average user can simply add attachments, and has no further control over the files that he has previously attached.

I would suggest that a user should be able to:

• delete a file attached by himself (Note: this would imply that an anonymous user could delete files added by another anonymous user)
• replace a file attached by himself by a newer version, simply by keeping a new Replace existing file checkbox checked, on the attachment form

Of course, the users with the TICKET_ADMIN and WIKI_DELETE would still be able to remove any attachment in the appropriate module.

See the attachment:attachment_del_replace.1077.diff for the suggested implementation.

In addition to the above changes, the patch also contains a small enhancement to the display of an attachment (as I have now the attachment information available, I show it in a way similar to the file revision information).

[cboos@…]

Suggested implementation for #948 (diff to [1077])

[cboos@…]

Oops, there's a spurious print debug statement in the patch... If only I could replace that attachment with a fixed one :)

[jonas]

Looks interesting, no time to include it in Trac 0.8 though...

[anonymous]

You might want to follow the example of Bugzilla here: attachments can obsolete other attachments, but they cannot be deleted.

[anonymous]

I would suggest that the user be able to do what the trac project administrator determines that the user can do. This would probably mean that the trac program would need to implement a range of permissions for giving finer grained control of file attachment permissions to the trac administrator. For instance the trac administrator may determine that a user can delete all file attachments, or the user may just be able to delete his own file attachments. Point is that it should be up to the administrator to determine the permissions and not the program. I think that well thought out file attachment permissions will make the system much more robust. Just my opinion.

[cboos]

The original idea was (re-)implemented in [1874], but only for the replace part. That way, attachments can't be deleted if the user has not this specific permission.

[ziga]

Maybe it's just me, but I think this doesn't work. I still have multiple attacments listed when I check the checkbox! I replaced .cs and compiled .py files. What else is there to do?

[dserodio@…]

Why is this fixed? AFAIK, there's still no way to delete an attachment, and I do have TRAC_ADMIN permission.

[cboos]

Don't you see the Delete Attachment button at the bottom of the attachment page?

[dserodio@…]

Oh, now I see. I was looking for it on the Wiki page, besides the attachment, not in the attachment page itself.

Thanks. Now I went to the FAQ to add it and saw that it's already there.

/me hides in shame

[Max]

I second the opinion of anonymous, to wit:

\\\\\\\\\\\\\\\

I would suggest that the user be able to do what the trac project administrator determines that the user can do. This would probably mean that the trac program would need to implement a range of permissions for giving finer grained control of file attachment permissions to the trac administrator. For instance the trac administrator may determine that a user can delete all file attachments, or the user may just be able to delete his own file attachments. Point is that it should be up to the administrator to determine the permissions and not the program. I think that well thought out file attachment permissions will make the system much more robust. Just my opinion.

\\\\\\\\\\\\\\\\\

I do not want to grant all of my dev users the WIKI_DELETE permission that would allow them to delete all attachments (and other wiki elements); it's too powerful. Nor do I want them coming to me or one of the other admins if they replace their attachment with a newer version and then want to get rid of the deprecated attachment from the attachment list. It is an occasional nuisance, true; but why should the development team be beholden to me for so trivial an alteration as removing an attachment that they themselves added, if I think them trustworthy enough not to sabotage their own wiki entries by deleting all their attachments in a fit of pique?

Could this not be solved by adding the appropriate code and adding the permission type WIKI_ATTACHMENT_DELETE?

[mbertier@…]

I definitely agree with Max. We should also have a TICKET_DELETE_ATTACHMENT permission.

[sid <sid.wiesner@…>]

#2384 was marked as a duplicate of this ticket.

[sid <sid.wiesner@…>]

Removing the 0.9 milestone -- it has been closed and it doesn't make sense to have an open ticket in it still.

[cboos]

Related to the PermissionPolicy topic.

[Noah Kantrowitz (coderanger) <coderanger@…>]

You can also check out the SelfDelete plugin.

[athomas]

TracDev/SecurityBranch merged in r5514. The requirements from this ticket could now be implemented within the trac.perm.IPermissionPolicy interface: when a check for TICKET_ADMIN on a ticket attachment is passed to a policy implementation it could check the creator of the ticket is the same as the current user and deny/allow accordingly. Similarly for Wiki attachments and WIKI_DELETE.

A sample plugin implementing authz based access control is included as an example.

Ideally though, each "realm" of objects in Trac would define its own set of permissions and a policy would be able to act on that. eg. attachments might have CREATE, DELETE, REPLACE, each of which could be allowed/denied by the policy.