1. 03 Sep, 2014 1 commit
    • 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.
      1d18663b
  2. 02 Jul, 2014 1 commit
  3. 05 Jun, 2014 11 commits
  4. 06 Jan, 2014 2 commits
  5. 17 Dec, 2013 1 commit
    • Alex Vandiver's avatar
      Ensure that all calls to _EncodeLOB pass bytes, not characters · 329458a9
      Alex Vandiver authored
      There are several places that call _EncodeLOB; most are careful to pass
      bytes, not characters:
      
        1. RT::Attachment->Create takes a MIME::Entity; while the transfer
           encoding will have been decoded, ->bodyhandle->as_string does not
           decode bytes into characters.
      
        2. ObjectCustomFieldValues from file uploads; these are always left as
           bytes.
      
        3. ObjectCustomFieldValues from Content which is too long; Content is
           passed as characters.
      
      The one codepath which currently might pass characters, and not bytes,
      is the third possibility.  While the Mason parameter munging in
      RT::Interface::Web ensures that invalid byte sequences (including for
      invalid codepoints, like \x{FDD0}) are replaced using PERLQQ, there are
      no such guards for character strings passed to ->AddCustomFieldValue
      directly via the API.
      
      Ensure that the LargeContent passed to _EncodeLOB, upgraded from
      Content, contains bytes and not characters.
      329458a9
  6. 10 May, 2013 1 commit
    • Alex Vandiver's avatar
      When a value overflows into LargeContent, ensure that Content is null · ac135025
      Alex Vandiver authored
      The ->AddCustomFieldValue codepath attempts to ensure that empty values
      for Content or LargeContent are never passed down the stack for
      insertion.  However, this is foiled if a >255-character value is passed
      through for Value, is only caught at the ObjectCustomFieldValue->Create
      level -- which sets Content to the empty string when upgrading the
      Content to LargeContent, rather than undef.
      
      Ensure that NULLs are properly stored in the Content column when
      LargeContent is used, by setting Content to undef in such cases.  There
      may also exist historical OCFVs which contain '' instead of NULL; update
      them accordingly.
      ac135025
  7. 14 Jan, 2013 1 commit
    • Alex Vandiver's avatar
      Remove hard tab characters wherever possible · 785dc2e3
      Alex Vandiver authored
      For historical reasons, many parts of the RT code intermix hard tabs and
      siace-based indentation.  This commit does not attempt to standardize
      indentation, merely the horrid intermixing of hard tabs and spaces.
      
      A few hard tabs remain in t/mail/mime_encoding.t and t/mail/outlook.t,
      as the tabs are within strings representing test data; they also remain
      in third-party source.
      
      Best viewed with the -w option to `git diff`.
      785dc2e3
  8. 07 Jan, 2013 2 commits
  9. 30 May, 2012 1 commit
    • Alex Vandiver's avatar
      Serializer/Importer: Move Content and LargeContent into RT::Record · 14b0d6b4
      Alex Vandiver authored
      The logic previously resided on both RT::Attachment and
      RT::ObjectCustomFieldValue to ensure that the raw bytes (and not the
      encoding as they exist in the DB) are written to the serialized stream,
      and that they are writen in the correct encoding on the remote end.
      Combine them on RT::Record for greater generality.
      
      This most probably fixes a bug wherein ObjectCustomFieldValue's lack of
      Serialize method caused it to possibly insert _encoded_ information.
      14b0d6b4
  10. 10 Apr, 2012 1 commit
  11. 30 Mar, 2012 1 commit
  12. 03 Jan, 2012 1 commit
  13. 21 Nov, 2011 1 commit
  14. 07 Nov, 2011 2 commits
  15. 09 May, 2011 1 commit
  16. 04 May, 2011 1 commit
  17. 03 Mar, 2011 1 commit
  18. 15 Feb, 2011 3 commits
  19. 28 Dec, 2010 4 commits
  20. 27 Sep, 2010 1 commit
  21. 20 Sep, 2010 1 commit
  22. 19 Sep, 2010 1 commit