Extensible Attachments

[Pedro Algarvio, aka, s0undt3ch <ufs@…>]

After a talk with alect on #trac he sugested that this ticket was created.

The Problem:

I'm developing a plugin(​WikiTemplates) that will need to support attachments, and, by looking at trac's code, the AttachmentModule​ only supports wiki and ticket attachments, it doesn't support any other type of attachment.

Possible Solutions:

1. Create a copy of the attachment.py​ with the necessary changes, ie, deal with attachments under a different handler, and probalably under a diferent table;
2. Subclass the classes on attachment.py​ to add a new attachment type. But this raises a problem. Since it's subclassed, in order to use ​WikiTemplates attachments, the one that trac provides must be disabled in order for them to work.
   And what if another user creates some other plugin that needs attachment support and takes the same road I do? Both plugins can't be used at the same time.
   Which brings us to the ticket summary and the next solution;
3. Modify attachment.py​ so that it's extensible. This way, anyone wanting to use attachments on their plugins would have to for example register their type, and trac would create the necessary dir(s) under /path/to/trac/env/attachments, add the new type to the match_request(), and probably also pass the permissions needed to handle this new type of attachment.

[Christian Boos]

3. is the way to go, of course.

[Christian Boos]

I did some work on this. First, some cleanups for the attachment code, in r3303:3304. Then, on top of that, there's attachment:milestone_attachments_r3304.patch​, which adds attachments for Milestones.

That's quite useful if you have an original written "specification" to start with, before you break that down into tickets; you can know attach that spec directly to the milestone).

The problem with the implementation, as one can see in the patch, is mainly with the way the permissions are handled. This clearly needs to be pluggable in some way (Alec?).

Another cumbersome thing is the way to define the parent displayed name in _parent_to_hdf. Here, the TracObject.display_name idea would certainly be adequate.

[Christian Boos]

Add the possibility to have attachments for the Milestone

[Alec Thomas]

How about this patch? Adds the following interface:

class IAttachmentPointProvider(Interface):
    def get_attachment_points():
        """Provide details on file attachment points provided by this
        component.  Returns an iterable of tuples in the form `(type,
        description, title, (view_perm, write_perm, delete_perm))`.
        `description` and `title` will be used as the formatting string for the
        attachment point identifier."""

Here's the ticket implementation:

    def get_attachment_points(self):
        yield ('ticket', 'Ticket #%s', '#%s',
               ('TICKET_VIEW', 'TICKET_APPEND', 'TICKET_ADMIN'))

[Alec Thomas]

Attachment interface API

[Pedro Algarvio, aka, s0undt3ch <ufs@…>]

Why not for release 0.10.1?

[Matthew Good]

Replying to Pedro Algarvio, aka, s0undt3ch <ufs@ufsoft.org>:

Why not for release 0.10.1?

Because 0.10.1 will be a bugfix release so it should not contain any API changes.

[Christian Boos]

#2947 was closed as duplicate.

[Christian Boos]

As the permission handling is being refactoring in the security branch (see PermissionPolicy), the permissions for attachments are going to be more flexible, which was the main difficulty related to this ticket (see also ​googlegroups:trac-dev:e827b2a40111dbf9).

[Pedro Algarvio, aka, s0undt3ch <ufs@…>]

This is good news. I see no problem or step back by the implementation proposed.

[Christian Boos]

Implemented in r5570.

[Alec Thomas]

r5570 makes it easier to add per-realm attachment permissions to trunk, while this ticket is about generalising attachment permissions, which r5570 does not do.

[Christian Boos]

You're right I closed this ticket a little be too early, there still one piece missing.

[Christian Boos]

First round of enhancements committed as r5580.

[Christian Boos]

As we concluded on #trac, this is good enough for now.

Further enhancements would be at the level of the IPermissionRequestor, which should be enhanced so that an advanced admin module for fine grained permission would be able to see to what kind of resource a given action could apply.

[Christian Boos]

Plugin developers should also have a look at ILegacyAttachmentDelegate.