Edgewall Software
Modify

Opened 9 years ago

Closed 6 years ago

Last modified 5 years ago

#7862 closed defect (fixed)

show_email_addresses in notification emails

Reported by: sebastian@… Owned by: osimons
Priority: normal Milestone: 0.12.3
Component: notification Version: 0.11.2
Severity: normal Keywords:
Cc: Thijs Triemstra
Release Notes:
API Changes:

Description

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.

Attachments (1)

t7862-no_obfuscate_notify_unless_enabled-012-r10929.diff (4.9 KB ) - added by osimons 6 years ago.
Patch to not obfuscate when obfuscation is disabled in config.

Download all attachments as: .zip

Change History (12)

comment:1 Changed 9 years ago by Christian Boos

Milestone: 0.11.4

Simon?

comment:2 Changed 7 years ago by Thijs Triemstra <lists@…>

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

To: undisclosed-recipients:;

comment:3 Changed 7 years ago by osimons

Owner: changed from Emmanuel Blot to 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.

comment:4 Changed 7 years ago by Thijs Triemstra

Cc: Thijs Triemstra added

Changed 6 years ago by osimons

Patch to not obfuscate when obfuscation is disabled in config.

comment:5 Changed 6 years ago by osimons

Milestone: next-minor-0.12.x0.12.3

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.

comment:6 Changed 6 years ago by Christian Boos

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

comment:7 Changed 6 years ago by osimons

Resolution: fixed
Status: newclosed

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

comment:8 in reply to:  7 ; Changed 6 years ago by 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) ;-)

comment:9 in reply to:  8 ; Changed 6 years ago by 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?

comment:10 in reply to:  9 ; Changed 6 years ago by 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).

comment:11 in reply to:  10 Changed 5 years ago by Christian Boos

Replying to cboos:

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

Fixed in r11218.

Modify Ticket

Change Properties
Set your email in Preferences
Action
as closed The owner will remain osimons.
The resolution will be deleted.
to The owner will be changed from osimons to the specified user.

Add Comment


E-mail address and name can be saved in the Preferences .

 
Note: See TracTickets for help on using tickets.