show_email_addresses in notification emails

[sebastian@…]

When show_email_addresses = true is set in the trac.ini, notification mails should no longer obfuscate the email addresses.

Currently this setting works to remove obfuscation in the website, not not in notification emails.

[Christian Boos]

Simon?

[Thijs Triemstra <lists@…>]

Where does this obfuscation happen in notification emails? Do you mean this?

To: undisclosed-recipients:;

[osimons]

Just had a look at latest email template, and I'm not sure either where that happens. It is supposed to obfuscate in the body - fields like reporter, owner, change author and so on (fields that typically contain emails). Seems a few

Since the same email goes out to anyone, at some stage I added a call to always obfuscate all fields. Right, that was #6532.

Should see if I can tweak this slightly so that disabling the feature completely also disables it in notification.

[osimons]

Patch to not obfuscate when obfuscation is disabled in config.

[osimons]

I've added attachment:t7862-no_obfuscate_notify_unless_enabled-012-r10929.diff​ and would like to include that now for 0.12.3 too.

[Christian Boos]

LGTM, and all tests pass. Go for the last one ;-)

[osimons]

Committed in [10931] and merged to trunk in [10932].

[Christian Boos]

Replying to osimons:

… merged to trunk in [10932].

Surprisingly, that one caused test failures, while [10931] is OK. Ah, 'tself.obfuscate_emailrac'… ok, glitch fixed in [10939].

But the really funny thing is that the failure on trunk with Python 2.7.2 shows up as:

ERROR: test_props_format_obfuscated_email_disabled (trac.ticket.tests.notification.NotificationTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "c:\Trac\repos\trunk\trac\ticket\tests\notification.py", line 797, in test_props_format_obfuscated_email_disabled
    self._validate_props_format(formatted, ticket)
  File "c:\Trac\repos\trunk\trac\ticket\tests\notification.py", line 1046, in _validate_props_format
    self.assertEqual(expected, '\n'.join(lines))
  File "C:\Dev\Python272\lib\unittest\case.py", line 509, in assertEqual
    assertion_func(first, second, msg=msg)
  File "C:\Dev\Python272\lib\unittest\case.py", line 500, in _baseAssertEqual
    standardMsg = '%s != %s' % (safe_repr(first), safe_repr(second))
TypeError: <lambda>() takes exactly 2 arguments (1 given)

… and I first saw it while I was testing my own implementation of safe_repr (r10940) ;-)

[osimons]

Replying to cboos:

Replying to osimons:

… merged to trunk in [10932].

Surprisingly, that one caused test failures, while [10931] is OK. Ah, 'tself.obfuscate_emailrac'… ok, glitch fixed in [10939].

Ooops… A bit of manual merge was needed, but seems my copy & paste skills were not up to expected standard this time. Sorry ;-)

But the really funny thing is that the failure on trunk with Python 2.7.2 shows up as:

ERROR: test_props_format_obfuscated_email_disabled 
TypeError: <lambda>() takes exactly 2 arguments (1 given)

… and I first saw it while I was testing my own implementation of safe_repr (r10940) ;-)

My test was added just to trip you up ;-) However, this time I'm sure my copy & paste job was OK, so it isn't the test itself - right?. You are onto this through your own changes?

[Christian Boos]

Replying to osimons:

But the really funny thing is that the failure on trunk with Python 2.7.2 shows up as:

ERROR: test_props_format_obfuscated_email_disabled 
TypeError: <lambda>() takes exactly 2 arguments (1 given)

… and I first saw it while I was testing my own implementation of safe_repr (r10940) ;-)

My test was added just to trip you up ;-) However, this time I'm sure my copy & paste job was OK, so it isn't the test itself - right?. You are onto this through your own changes?

I first saw it on a state like r10940, and I was a bit startled by seeing the safe_repr in the traceback, given that r10940 is about adding safe_repr. However this had nothing to do with r10940, as when you run the tests on r10932, you get the same error and traceback (with Python 2.7.2 at least, not with Python 2.5.4 for example, where you get a "normal" failure). I didn't bother investigate further however, but this might indeed be a symptom of a bug in the refactored unittest of Python 2.7 (we already hit a few bugs in the past there).

[Christian Boos]

Replying to cboos:

ERROR: test_props_format_obfuscated_email_disabled 
TypeError: <lambda>() takes exactly 2 arguments (1 given)

Fixed in r11218.