Trac does not validate ids in CC and assign-to fields

[dmorissette]

I have noticed that Trac doesn't validate the user ids set in the CC and Assign-To fields of tickets. For instance, see the "abc" and "def" users CC'd on this ticket.

As a result, we often end up CC'ing or assigning tickets to non-existent users (either due to typos or to mistakes in guessing one's user id)... and never get any feedback from that person since the notification never made it home. This is a serious problem for projects (and a problem that bugzilla didn't have since you could Assign-to or CC only registered users in bugzilla).

I think Trac really needs to validate user ids and report errors as soon as an invalid id is entered. Is this a Trac option that is not enabled on our servers or a bug in Trac?

[warmerdam]

Daniel,

It is normal for Trac to make no attempt to validate values in cc: and Assigned To: fields. The support for osgeo userids in these fields is also a "hacked in" addition here at OSGeo and not normally supported by Trac.

I don't know how to add validation into editing of these fields. I could imagine adding a batch process that would review all Trac tickets and check that Assigned To and CC fields are either apparently email address (they contain an @ sign) or are valid OSGeo userids. Any violations could be emailed to a trac maintainer and the ticket owner for instance.

Alternatively, if there is someone interested in immersing themselves in Trac's code it might be possible to come up with a better solution.

I'll take this ticket for now, but if anyone is interested in solving it "well" please add yourself to the cc list!

[dmorissette]

When I tried researching the issue I didn't find any solution but I came across the following ticket that mentions a regex to validate the contents of those fiels in notification.py: ​http://trac.edgewall.org/ticket/3212

Perhaps something could be added there to lookup LDAP user ids and report errors? I didn't look at that script, but perhaps it already had some validation and that's just been disabled by the local hack?

[strk]

See also #1671 as it is related to the loss of notification.py hacks.

[strk]

For the record, this is still an issue after upgrade to Trac-1.2

[strk]

Maybe the validation could be done as part of the code to match recpients from LDAP (#1863)

[cvvergara]

Testing a CC with an invalid name

[cvvergara]

Testing a CC with a valid ldap name

[cvvergara]

Testing with email

[cvvergara]

Conclusions on validation in CC

Testing a CC with an invalid name, font is normal

Cc: sac added

Testing a CC with a valid ldap name, font is bold

Cc: cvvergara added; sac removed

Testing with email, font is normal

Cc: sac@… added; cvvergara removed

[cvvergara]

Testing reassign to invalid ldap name "sac"

[cvvergara]

Trac checks for the ldap name, and when it does not exist issues a warning

Warning: The change has been saved, but an error occurred while sending notifications: 'list' object has no attribute 'update'

(returning to original owner)

[cvvergara]

Did not get any notification on the CC, when

Owner: changed from warmerdam to sac Owner: changed from sac to warmerdam

testing if this new comment sends a message

[cvvergara]

Testing reassigning to a valid ldap name

[cvvergara]

Returning ticket to original owner

[cvvergara]

Conclusion on validation of reassign to

When a valid ldap name is used:

• The change takes place and the mails are sent.

When a invalid ldap name is used:

• The change takes place
• a warning is generated
  • Warning: The change has been saved, but an error occurred while sending notifications: 'list' object has no attribute 'update'
• The mails are not sent.

When fixing to a vaild ldap name

• The change takes place
• a warning is generated
  • Warning: The change has been saved, but an error occurred while sending notifications: 'list' object has no attribute 'update'
• The mails are not sent.
• On the next change (for example a comment) the mails are sent

[cvvergara]

Closing ticket:

Validation is happening, the behavior of the validation When OK:

• CC: when the ldap name is invalid is with bold font
• Reassign to: change is done and mails are sent

When not OK:

• CC: when the ldap name is invalid is with normal font
  • fix by using a valid ldap name
• Reassign to: change is done and mails are not sent,
  • Warning message appears
  • fix by assigning a valid ldap name, mail of the fix is not sent.
  • subsequent changes on the ticket will send the mails