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.

[cboos]

3. is the way to go, of course.

[cboos]

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.

[cboos]

Add the possibility to have attachments for the Milestone

[athomas]

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'))

[athomas]

Attachment interface API

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

Why not for release 0.10.1?

[mgood]

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.

[cboos]

#2947 was closed as duplicate.

[cboos]

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.

[cboos]

Implemented in r5570.

[athomas]

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.

[cboos]

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

[cboos]

First round of enhancements committed as r5580.

[cboos]

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.

[cboos]

Plugin developers should also have a look at ILegacyAttachmentDelegate.