1. 03 Sep, 2014 3 commits
    • Alex Vandiver's avatar
      Standardize on the stricter Encode::encode("UTF-8", ...) everywhere · 1d18663b
      Alex Vandiver authored
      This is not only for code consistency, but also for consistency of
      output.  Encode::encode_utf8(...) is equivalent to
      Encode::encode("utf8",...) which is the non-"strict" form of UTF-8.
      Strict UTF-8 encoding differs in that (from `perldoc Encode`):
          ...its range is much narrower (0 ..  0x10_FFFF to cover only 21 bits
          instead of 32 or 64 bits) and some sequences are not allowed, like
          those used in surrogate pairs, the 31 non-character code points
          0xFDD0 .. 0xFDEF, the last two code points in any plane (0xXX_FFFE
          and 0xXX_FFFF), all non-shortest encodings, etc.
      RT deals with interchange with databases, email, and other systems.  In
      dealing with encodings, it should ensure that it does not produce byte
      sequences that are invalid according to official Unicode standards.
    • Alex Vandiver's avatar
      Ensure all MIME::Entity headers are UTF-8 encoded bytes · 41d084f1
      Alex Vandiver authored
      Placing wide characters into MIME::Entity objects can lead to
      double-encoding, as discovered most recently in d469cacc.  Explicitly
      decode all headers as UTF-8 when retrieving them with ->get(), and
      encode them as UTF-8 before updating them with ->set() or ->replace().
      This also applies to headers passed to ->build().  The only exceptions
      to this are fixed strings in the source (which, in the absence of "use
      utf8", are always bytes).
      While the majority of these headers will never have wide characters in
      them, always decoding and encoding ensures the proper disipline to
      guarantee that strings with the "UTF8" flag do not get placed in a
      header, which can cause double-encoding.
    • Alex Vandiver's avatar
      Ensure all MIME::Entity bodies are UTF-8 encoded bytes · 6d9bd63c
      Alex Vandiver authored
      Placing wide characters into MIME::Entity objects can lead to
      double-encoding.  Always treat them as byte stores, encoding as UTF-8
      and noting their character set.
      In the case of Approvals/index.html, there was no need for an explicit
      MIME::Entity object; ->Correspond creates one as needed from a "Content"
  2. 18 Aug, 2014 1 commit
  3. 07 Jul, 2014 1 commit
  4. 16 Apr, 2014 1 commit
  5. 24 Mar, 2014 2 commits
  6. 19 Feb, 2014 1 commit
  7. 06 Jan, 2014 2 commits
  8. 02 Jan, 2014 1 commit
    • Alex Vandiver's avatar
      Don't die if HTML → text conversion throws an error · 254e8da9
      Alex Vandiver authored
      HTML::FormatText::WithLinks::AndTables may contain errors which make it
      incapable of rendering the HTML to text.  In the context of templates,
      this led to the outgoing mail being dropped on the floor if the
      conversion failed.  It also showed as errors in the REST interface and
      RSS feed, in attempting to downsample an HTML-only message to plain text
      to display therein.
      Expliticly wrap the conversion with an eval to trap fatal errors in the
      HTML::FormatText::WithLinks::AndTables module; in such cases, the method
      returns undef.  In the context of template generation, the presence of
      such a return value is to omit the text/plain part entirely, as email
      clients may be able to generate it even if we are unable to.
      It is expected that the new tests may begin to fail if
      HTML::FormatText::WithLinks::AndTables resolves its bug surrounding
      nested tables.  Unfortunately, marking them TODO is difficult because
      they intermix passing and failing tests in mail_ok.
  9. 03 Sep, 2013 7 commits
  10. 24 Aug, 2013 1 commit
  11. 30 Jul, 2013 2 commits
  12. 24 May, 2013 2 commits
  13. 09 May, 2013 2 commits
  14. 06 May, 2013 1 commit
  15. 01 May, 2013 1 commit
  16. 27 Mar, 2013 2 commits
  17. 07 Jan, 2013 1 commit
  18. 27 Dec, 2012 3 commits
  19. 19 Dec, 2012 1 commit
    • Thomas Sibley's avatar
      Normalize forward recipients before sending and adjust tests to match reality · c92e6162
      Thomas Sibley authored
      None of the usual parsing and normalization of email recipients was done
      when forwarding tickets or transactions.  Use RT::EmailParser's
      ParseEmailAddress method to convert to Email::Address objects
      (effectively a split), then reformat and join back together.  This
      ensures domain-less usernames are supported in forwards just like
      elsewhere.  Importantly, this change also ensures the transaction
      recording the forward action has a Data column which is guaranteed
      The forwarding tests previously tested a domain-less user in the same
      field as a full email address, which is not supported by RT's email
      parsing and would likely never work as expected with a real MTA.  Switch
      to testing domain-less users are parsed correctly when in their own
      recipient field.
      These bugs were uncovered by RT::Transaction's new parsing of $txn->Data
      for generating history descriptions.
  20. 17 Dec, 2012 2 commits
  21. 04 Dec, 2012 1 commit
  22. 09 Nov, 2012 1 commit
    • Tim Cutts's avatar
      Re-read Subject from Message after ExtractTicketId · 22099a1b
      Tim Cutts authored
      Since 4.0.7, ExtractTicketId can be overridden, as in
      RT::Extension::RepliesToResolved.  The override might change the Subject
      of the message (as the above extension does).
      Keep the original subject for error messages, but if ExtractTicketId has
      changed the subject, use that for the new ticket creation.
  23. 05 Nov, 2012 1 commit