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

[Christian Boos]

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 Borgström]

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.

[Christian Boos]

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.

[Christian Boos]

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.

[Christian Boos]

Related to the PermissionPolicy topic.

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

You can also check out the ​SelfDelete plugin.

[Alec Thomas]

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.

[Christian Boos]

I don't see happening that soon, but definitely needed.

[Andrew Schulman <andrex@…>]

It would also be useful if users could edit the file description.

[ivoras@…]

How about versioning attachments (i.e. when an attachments is replaced)? It could be done simply either by adding version prefixes to old files (e.g. 01_myfile.doc, 02_myfile.doc…) or by creating directories with version name containing the old versions (e.g. 01/myfile.doc, 01/myfile.doc).

[anonymous]

As we had the problem that different people are adding and replacing attachments, but cannot be given permission TICKET_ADMIN, I programmed a little plugin for this issue. See ​https://trac-hacks.org/wiki/AttachmentPolicyPlugin

IMHO it is very confusing that Trac says "[…] Replacing other's attachments requires ATTACHMENT_DELETE permission.", but there is no permission ATTACHMENT_DELETE in the admin-permission panel. I also thought that replacing any attachment is the default action when having permission TICKET_APPEND.

[anonymous]

Why is this request still open after 7 years? even with code submitted to enable it? This is an open and honest question, without whine or sarcasm I really would like to understand what the blocking factors are.

To my, user-centric, way of thinking WikiPage#attachment is a special class of WikiPage>SubPage and could be handled the same way. Have ATTACH_CREATE,_MODIFY,_DELETE permissions, and then version the changes as per #comment:26.

[Christian Boos]

As you can imagine, the issue is less trivial than it seems, mainly as the notion of "your own attachments" when you're not logged-in is not well defined. When you're authenticated, what we could do is a bit clearer, though in the coarse grain permission model we don't have a proper way to express a rule saying "you can do that on your own things". This would require a PermissionPolicy, but then not every resource has an owner, and for those who have, you don't have a standardized way to query the owner.

Writing a PermissionPolicy that implements this check for attachments only and for authenticated users would probably be trivial, but not that useful either, as authenticated users usually have more powerful permissions, like ATTACHMENT_DELETE, etc. I can imagine this might still be useful on sites with lots of authenticated users (​TH:AccountManagerPlugin) but then I'm not really concerned personally.

And with that you hit the other reason why this hasn't been fixed in 7 years: Trac is a community based project, meaning that the areas where it progresses are those for which some community members feel motivated enough to provide a good solution, in terms of ideas, code, testing, and documentation.

I realize the investment in time and effort needed to provide a decent solution like the one I outlined above might be perceived as being overkill for the anticipated benefit of the feature or fix, but if you rather see this as a learning experience and a way to contribute your own piece to the edifice, then it might be well worth it ;-)

[framay <franz.mayer@…>]

Well, I haven't read all the comments and requirements in this ticket, but ​AttachmentPolicyPlugin would provide some of the functionality.

[michael@…]

Could we have a cut-down version of this feature in the short term? That is, to grant authenticated users the right to delete their own attachments by default?

I can see that the issue of people who are not logged on is more complex; if it's easy to implement, they might be permitted to delete attachments within an editing session.

Consider as a use case my current situation:

• Modest Wiki skill.
• Authenticated.
• Tried to use an image, but PDF format is not permitted for images.
• Using an image is a two stage process (upload, use) so preview doesn't help
• Couldn't replace the PDF with a JPG and can't delete the PDF, so the page is a mess
• Don't want to ask the bank's sys-admin team for admin rights …

[knavero]

Has there been any updates on this? I'm interested in this permission as well.

[anonymous]

This was already implemented in #12719: The LegacyAttachmentPolicy allows authenticated users to delete their own attachments since Trac 1.3.2.

[Ryan J Ollos]

Replying to anonymous:

This was already implemented in #12719: The LegacyAttachmentPolicy allows authenticated users to delete their own attachments since Trac 1.3.2.

Thanks for noticing. I had already forgotten about the change.