Custom Query (332 matches)
Results (193 - 195 of 332)
Ticket | Resolution | Summary | Owner | Reporter |
---|---|---|---|---|
#203 | fixed | [PATCH]: Allow restricting ticket updates to ticket participants | bas | kris@… |
Description |
USE CASE: I use email2trac to integrate an internal instance of Trac with traditional user support ticketing via email. This is great, because it keeps both internal and external issues under the same roof. Users simply send in their support requests via e-mail and email2trac + Trac notifications handle the rest while keeping Trac itself restricted. [ Parenthetically, by use of tags and an outgoing filter in the MTA, external tickets can also have internal comments allowing us to define which updates are to be sent out externally. This would of course be better to implement in the Trac layer, but it does the job. ] PROBLEM: With ticket_update on, email2trac allows any ticket to be updated by just changing the ticket number in the Subject. While great for an open Trac, it opens a security hole when Trac is used for private ticketing. Example:
PATCHED BEHAVIOR: by turning on ticket_update_restricted_to_participants, a ticket update is allowed only if 1) the updater is the reporter, 2) the updater is in the CC or 3) the updater matches a Trac username (i.e. is staff). If the update is denied, a new ticket will be generated instead as to not loose the issue (NOTE: the current trunk will drop any e-mail that has a ticket number which does not match a ticket; this patch also fixes that as a side-effect). Index: email2trac.py.in =================================================================== --- email2trac.py.in (revision 375) +++ email2trac.py.in (working copy) @@ -197,6 +197,11 @@ else: self.TICKET_UPDATE = 0 + if parameters.has_key('ticket_update_restricted_to_participants'): + self.TICKET_UPDATE_RESTRICTED_TO_PARTICIPANTS = int(parameters['ticket_update_restricted_to_participants']) + else: + self.TICKET_UPDATE_RESTRICTED_TO_PARTICIPANTS = 0 + if parameters.has_key('ticket_update_by_subject'): self.TICKET_UPDATE_BY_SUBJECT = int(parameters['ticket_update_by_subject']) else: @@ -762,6 +767,42 @@ self.id = None return False + + if self.TICKET_UPDATE_RESTRICTED_TO_PARTICIPANTS: + + # Is the updater the reporter? + # Since all Trac users are allowed to update, it does + # not matter if any of our fields contain usernames + # instead of emails. + # + if tkt['reporter'] and self.email_addr.lower() == tkt['reporter'].lower(): + if self.DEBUG: + print 'Restricted update: ALLOW, %s is the ticket reporter' %(self.email_addr) + + # Is the updater in the CC? + elif tkt['cc'] and self.email_addr.lower() in tkt['cc'].lower().replace(' ', '').split(','): # assuming space is fragile, hence replace() + if self.DEBUG: + print 'Restricted update: ALLOW, %s is in the CC' %(self.email_addr) + + else: + tkt_allow_update = False + + # Is the update a Trac user? + for username, name, email in self.env.get_known_users(): + if email and email.lower() == self.email_addr.lower(): + tkt_allow_update = True + if self.DEBUG: + print 'Restricted update: ALLOW, %s matches username %s' %(self.email_addr, username) + break + + # No luck? Fail the update. + if not tkt_allow_update: + if self.DEBUG: + print 'Restricted update: DENIED, %s does not match a username nor is it the reporter or in the CC' %(self.email_addr) + self.id = None + return False + + # How many changes has this ticket cnum = len(tkt.get_changelog()) @@ -1486,7 +1527,11 @@ # if result.group('reply') and self.TICKET_UPDATE: self.system = 'ticket' - self.ticket_update(m, result.group('reply'), spam_msg) + result = self.ticket_update(m, result.group('reply'), spam_msg) + + # If the ticket was not found, create a new one instead of loosing it + if not result: + self.new_ticket(m, subject, spam_msg) # New ticket + fields # Looking forward to seeing whether you think this is something that should go into the release. The patch itself is rather verbose due to the debugging. FWIW this was also my first foray into Python, apologies if the patch is not very Pythonic. :) Thanks a lot for your efforts, keep up the great work!
|
|||
#205 | fixed | email2trac chokes on non-ascii (utf8) characters in workflow | bas | eirik.schwenke@… |
Description |
We had an initial ticket status of "forespørsel", and that caused email2trac to fail with the error(s): email2trac: Traceback (most recent call last): email2trac: File "/usr/bin/email2trac", line 2133, in <module> tktparser.parse(sys .stdin) email2trac: File "/usr/bin/email2trac", line 1531, in parse self.new_ticket(m, sub ject, spam_msg) email2trac: File "/usr/bin/email2trac", line 967, in new_ticket self.set_ticket_fi elds(tkt) email2trac: File "/usr/bin/email2trac", line 876, in set_ticket_fields print 'trac .ini name %s = %s' %(name, value) email2trac: UnicodeEncodeError: 'ascii' codec can't encode character u'\xf8' in position 27: ordinal not in range(128) It would appear some more care is needed to support unicode in all strings in email2trac. I had a brief look at the script, but couldn't easily see if it would be safe and sound to simply wrap all missing strings with a .encode('utf-8') or not. For now the workaround has been to limit ourselves to ascii-characters in ticket-status names -- but that is obviously not a good solution (it's looks a bit strange in Norwegian, in eg. Japanese it would be hopeless). |
|||
#206 | fixed | email2trac bombs when attachment contains umlaut characters | bas | karsten.rohrbach@… |
Description |
From bounce message produced by postfix MTA: TD: saving email to /tmp/tmpKadtCi.email2trac TD: writing body to /tmp/tmpsgE73w.email2trac TD: part1: Content-Type: application/octet-stream Traceback (most recent call last): File "/usr/bin/email2trac", line 2151, in <module> tktparser.save_email_for_debug(m, True) File "/usr/bin/email2trac", line 575, in save_email_for_debug self.debug_attachments(message_parts) File "/usr/bin/email2trac", line 519, in debug_attachments print 'TD: part%d: filename: %s' % (n, filename) UnicodeEncodeError: 'ascii' codec can't encode character u'\xc4' in position 33: ordinal not in range(128) The filename causing this behaviour is AUFTRAGSBESTÄTIGUNGS-FORMULAR_115886.PDF, containing a German umlaut. Deployed Version of email2trac is 1.4.3 |