No notification email when adding an attachment to a ticket

[webkontakt@…]

If you just add an attachment to a ticket and change nothing else, no notification emails are sent, even if the CC-Field is filled.

Btw., it's very hard to change anything else (e.g. adding a comment) when adding an attachment, so noone does. Therefore notification is necessary there.

[Markus Tacker <m@…>]

It should also appear on the timeline.

[Christian Boos]

Related to #1498.

[trac@…]

patch for notification only. against r2659

[trac@…]

Added attachment for a patch against r2659 that takes care of only the email notification portion of this ticket. Currently does nothing for adding the attachment detail to the timeline.

[trac@…]

This patch actually has contents in the email. Sorry about that…

[trac@…]

full functionality requested. adds remark on timeline

[trac@…]

The new patch contains both the email notification for attachments and will add the line "attachment changed" to the timeline when the ticket_show_details configuration option is set (see TracIni).

[Matthew Good]

Please don't mark a ticket as fixed unless the patch has been committed.

[Christian Boos]

I have now a few days off the net and, among other things, I'll test the patch (the timeline part, Emmanuel, can you take care of the evaluating the notification part?)

[Emmanuel Blot]

Sure, I'll do that by the end of this week

[Emmanuel Blot]

#2897 has been marked as a (partial) duplicate of this ticket.

[mjlucas@…]

What is the status of the defect? I have applied the patch.3 to my version of 0.9.3 for testing. The notification section (attachment.py) works as specified and seems to send the correct information to the user (Will be doing testing over the next few days)

However the modifications to web_ui.py seem to cause all sorts of problems. I don't know if it is because of changes landed after this patch was written or what but the timeline gets screwed up with tickets appearing as done on 1/1/1970 (ie. no timestamp) and the firelds appear to be out of place. I haven't looked at what exactly is returned by the SQL statement however if there is a newer patch could someone please post it online.

[Christian Boos]

This ticket will require some general changes on the way the attachment changes interfere with the main resource changes.

See also #1278, which is about a related issue, but for wiki pages.

[Alec Thomas]

r3400 adds attachment timeline events for Wiki pages and tickets.

[sid]

#2725 is similar (Ticket changetime is not updated with an attachment) and has a patch.

[Stefan Reinauer <stepan@…>]

Hm, bug juggling. I came from #4075 because trac is not attaching ticket attachments to email notifications. This is a critical issue and people are urging me to drop trac for LinuxBIOS again (www.linuxbios.org) because of this.

Unfortunately above patches are a year old and don't apply to our version of trac (0.10) nor do they work if applied manually (server error).

This bug has been there since 0.8.4. Will it ever be fixed?

[Emmanuel Blot]

Come on, be serious, this bug does not prevent from using Trac.

If you want it to be fixed quicker, patches are welcome. As you can see, it is scheduled for 0.11.

[stepan@…]

I am pretty serious about this one. The common sense seems to be "we dont use browsers because email clients are more concise". While shaking your head might be an appropriate reaction, I still want to keep using trac for this project.

If I manage to come up with a viable solution, I will of course drop a patch to this ticket.

Anyways, thanks for the quick life sign ;-)

[Emmanuel Blot]

See also #4281.

[anonymous]

Is the internal structure of Trac so inflexible that this can not be implemented easily? Someone complained in 0.10 and got put off until 0.11. Now it's 0.12. Why not set it to 2.0 now.

[Christian Boos]

Ever wondered how Trac manages to go forward? Look at the timeline.

If it's 0.12, it's for a good reason, or rather 3:

• nobody provided a patch that could accelerate the process to get this feature in
• there is a bunch of other notification related changes that will hopefully happen in 0.12, so it's natural to group it there
• there's already too many things scheduled for 0.11 and most likely 2/3 of the still opened 181 tickets (as of this writing) for 0.11 will go to 0.12, if not later.

[Christian Boos]

#5721 was closed as duplicate. I've added its reporter to the CC: list.

[sid]

Update previous submissions to be in line with changes in trunk

[sid]

I attached an untested patch that does the same thing as the previous patch (minus the timeline work). It should conform to the changes that have happened in trunk since. Any feedback from people willing to test this would be appreciated (and greatly help its chances of getting merged to trunk sooner).

[anton]

It would be nice if this would work in the 0.11 version.

I set up a trac to communicate with some developers of another company for a project.

I set up mail notification too.

Actually this issue is a problem, because this trac is only for one project between our companies.

Since in both companies the peoples are working on more than one project, its better to be notified by mail than to log in every day (perhaps in other issue / bug systems for different projects) to look in the timeline what did change (even if nothing changed).

[Christian Boos]

sid, thanks for the patch, I did notice it but apparently forgot to test it.

I'll take care of adding that in time for 0.11, after the context-refact merge.

[Christian Boos]

Sorry, changed my mind. This has to be redone in a more generic way in 0.12, as it's somewhat a bit unclean to hard-code ticket notifications that way, now that the attachment module is really fully generic.

For those desperately in the need for the feature in the meantime, there's the patch…

[niels.reedijk@…]

Is this supposed to work? The patch does not apply cleanly to the current trunk, and if I manually merge it, all modules importing Attachment fail. Could I be doing something wrong, or is it the patch?

[shepting@…]

Has anyone been able to provide a working patch for 0.11 yet? My company would be interested in using this in a production setting, but just as niels.reedijk noted there are unrecoverable errors when applying this patch.

[Christian Boos]

There's some discussion on trac-dev about a possible re-implementation of notifications (​googlegroups:trac-dev:251bb1e6129dd095). In the meantime you might try the ​TracHacks:AnnouncerPlugin.

OTOH, adapting the patch to work with 0.11 or trunk shouldn't be hard, I'll give it a try later today.

[Remy Blank]

It seems that the notification revamp will not happen in 0.12.

[peshing@…]

hello,

is there, a working patch for trac 0.11. I tryed to make it wotk but I cannot import the Ticket model in attachment.py and that is why the patch is not working…, but I am new to python aniway so please help

[quintin@…]

How's about someone just takes one of the patches and apply it to trunk? Many people are waiting for this change to happen.

Make the timeline integration a second ticket? It's a small job to apply one of the patches to trunk. Those who know how to do it themselves do so, but many people just download and use as-is.

[Emmanuel Blot]

New patch proposal for current trunk (0.13dev)

[Emmanuel Blot]

Fix up some issues with the previous patch, all unit/functional tests now pass Ok.

[Christian Boos]

Just tested it and it works fine.

Nit-picking, currently the comment in the mail is simply:

Add attachment "<filename>"

I'd prefer something like:

Attachment "<filename>" added.

(the attachment description)

[Christian Boos]

Also send attachment's description in the body of the notificatio n mail. Applies on top of attachment_0.13dev.2.patch​.

[Emmanuel Blot]

New patch for latest development version (1.0.1dev), including cboos fixes.

[Gasol Wu <gasolwu@…>]

I have written small plugin called ​AttachmentNotifyPlugin, based on patches of this thread. For someone waiting for 7 years.

[Ryan J Ollos]

Tentatively scheduling for 1.0.3, or possibly 1.1.3.

[Ryan J Ollos]

attachment:attachment_1.0.1dev.patch​ was rebased on 1.0-stable in log:rjollos.git:t2259-notification-email-when-adding-attachment-to-ticket. The attachment notification is functioning correctly in the limited amount of testing that I've done. I plan to further review the patch.

Shouldn't these class attributes be instance attributes instead?: tags/trac-1.0.1/trac/ticket/notification.py@:136-138#L132​. They are modified within an instance method: tags/trac-1.0.1/trac/ticket/notification.py@:162-164#L132​.

[Ryan J Ollos]

Replying to rjollos:

Shouldn't these class attributes be instance attributes instead?: tags/trac-1.0.1/trac/ticket/notification.py@:136-138#L132​. They are modified within an instance method: tags/trac-1.0.1/trac/ticket/notification.py@:162-164#L132​.

Change committed to 1.0-stable in [13372] and merged to trunk in [13373].

[Ryan J Ollos]

Refactoring in [13374,13376], merged to trunk in [13375,13377].

[Ryan J Ollos]

Some refinements:

• Wrapped length of attachment added / attachment deleted and attachment description texts.
• Translation deactivation only encloses necessary code.
• Added try/except around notify_attachment.
• notify method is mostly unmodified.

Proposed changes in log:rjollos.git:t2259-notification-email-when-adding-attachment-to-ticket.1.

[Ryan J Ollos]

Replying to Gasol Wu <gasolwu@…>:

I have written small plugin called ​AttachmentNotifyPlugin, based on patches of this thread. For someone waiting for 7 years.

Thank you for providing an interim solution. I've added a note to the ​th:AttachmentNotifyPlugin to indicate that it won't be needed for Trac ≥ 1.0.3.

[Jun Omae]

Proposed changes in log:rjollos.git:t2259-notification-email-when-adding-attachment-to-ticket.1.

Quick testing, seems like good. But I think _translation_deactivated is wrong when an exception is raised while executing yield. In the case, the statements after yield wouldn't be executed.

from __future__ import with_statement
from contextlib import contextmanager

@contextmanager
def fn():
    print 'pre'
    yield
    print 'post'

def raising():
    raise ValueError

def main():
    print 'start'
    try:
        with fn():
            raising()
    except ValueError:
        print 'caught'
    print 'end'

main()

$ python2.5 /tmp/test.py
start
pre
caught
end

[Ryan J Ollos]

Replying to jomae:

Proposed changes in log:rjollos.git:t2259-notification-email-when-adding-attachment-to-ticket.1.

Quick testing, seems like good. But I think _translation_deactivated is wrong when an exception is raised while executing yield. In the case, the statements after yield wouldn't be executed.

Thanks, I'll modify the context manager:

from __future__ import with_statement
from contextlib import contextmanager

@contextmanager
def fn():
    print 'pre'
    try:
        yield
    finally:
        print 'post'

def raising():
    raise ValueError

def main():
    print 'start'
    try:
        with fn():
            raising()
    except ValueError:
        print 'caught'
    print 'end'

main()

start
pre
post
caught
end

[Ryan J Ollos]

Replying to jomae:

Quick testing, seems like good. But I think _translation_deactivated is wrong when an exception is raised while executing yield. In the case, the statements after yield wouldn't be executed.

I modified the context manager to handle that scenario in [8ebece33/rjollos.git].

Additional refactoring in [13378], merged in [13379].

[Jun Omae]

Unit tests failing with Python 2.7 and TRAC_TEST_DB_URI=sqlite:test.db. All tests pass with Python 2.5 and 2.6.

self.env.reset_db() in tearDown() raises an OperationalError.

...
======================================================================
ERROR: test_ticket_notify_attachment_enabled_attachment_removed (trac.ticket.tests.notification.AttachmentNotificationTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/run/shm/8ebece33dd566ca3295031f03831ee730e815b31/py27-sqlite-file/trac/ticket/tests/notification.py", line 1277, in tearDown
    self.env.reset_db()
  File "/run/shm/8ebece33dd566ca3295031f03831ee730e815b31/py27-sqlite-file/trac/test.py", line 349, in reset_db
    tables = getattr(m, reset_fn)(self, db_prop)
  File "/run/shm/8ebece33dd566ca3295031f03831ee730e815b31/py27-sqlite-file/trac/test.py", line 184, in reset_sqlite_db
    db("DELETE FROM %s" % table)
  File "/run/shm/8ebece33dd566ca3295031f03831ee730e815b31/py27-sqlite-file/trac/db/util.py", line 128, in execute
    cursor.execute(query, params if params is not None else [])
  File "/run/shm/8ebece33dd566ca3295031f03831ee730e815b31/py27-sqlite-file/trac/db/util.py", line 63, in execute
    r = self.cursor.execute(sql)
  File "/run/shm/8ebece33dd566ca3295031f03831ee730e815b31/py27-sqlite-file/trac/db/sqlite_backend.py", line 80, in execute
    result = PyFormatCursor.execute(self, *args)
  File "/run/shm/8ebece33dd566ca3295031f03831ee730e815b31/py27-sqlite-file/trac/db/sqlite_backend.py", line 58, in execute
    args or [])
  File "/run/shm/8ebece33dd566ca3295031f03831ee730e815b31/py27-sqlite-file/trac/db/sqlite_backend.py", line 50, in _rollback_on_error
    return function(self, *args, **kwargs)
OperationalError: disk I/O error

----------------------------------------------------------------------
Ran 1633 tests in 36.747s

FAILED (errors=4)
make: *** [unit-test] Error 1

I think we should call rmtree after reset_db because rmtree removes the SQLite database file.

trac/ticket/tests/notification.py

@@ -1273 +1273 @@
     def tearDown(self):
         """Signal the notification test suite that a test is over"""
         notifysuite.tear_down()
-        shutil.rmtree(self.env.path)
         self.env.reset_db()
+        shutil.rmtree(self.env.path)
 
     def test_ticket_notify_attachment_enabled_attachment_added(self):
         self.attachment.insert('foo.txt', StringIO(''), 1)

[Ryan J Ollos]

Fixed issue in comment:60 and also fixed change author email not being obfuscated. Committed to 1.0-stable in [13380:13382], merged to trunk in [13383:13385].

[Ryan J Ollos]

I was thinking about whether we really need the option [notification] ticket_notify_attachment. The TicketAttachmentNotifier can already be disabled by disabling the component: trac.ticket.notification.ticketattachmentnotifier = disabled. It is always nice to have one fewer option and we could just document how to disable the component on the TracNotification page. Do that seem straightforward enough, or does anyone see a reason to keep the [notification] option?

trac/ticket/notification.py

@@ -502 +502 @@
 
     implements(IAttachmentChangeListener)
 
-    ticket_notify_attachment = BoolOption('notification',
-                                          'ticket_notify_attachment', True,
-        """Always send notifications on ticket attachment events.""")
-
     # IAttachmentChangeListener methods
 
     def attachment_added(self, attachment):
-        if self.ticket_notify_attachment:
-            self._notify_attachment(attachment, True)
+        self._notify_attachment(attachment, True)
 
     def attachment_deleted(self, attachment):
-        if self.ticket_notify_attachment:
-            self._notify_attachment(attachment, False)
+        self._notify_attachment(attachment, False)
 
     def attachment_reparented(self, attachment, old_parent_realm,
                               old_parent_id):

[Peter Suter]

Replying to rjollos:

I was thinking about whether we really need the option [notification] ticket_notify_attachment. The TicketAttachmentNotifier can already be disabled by disabling the component: trac.ticket.notification.ticketattachmentnotifier = disabled. It is always nice to have one fewer option and we could just document how to disable the component on the TracNotification page. Do that seem straightforward enough, or does anyone see a reason to keep the [notification] option?

I agree, disabling the component seems just as good to me.

[Ryan J Ollos]

Thanks for the review. Edited the documentation in TracNotification@85. Committed to 1.0-stable in [13434], merged to trunk in [13435].