Skip to content
Snippets Groups Projects
  1. Feb 28, 2014
  2. Feb 27, 2014
  3. Feb 26, 2014
  4. Feb 25, 2014
  5. Feb 22, 2014
    • Jared Hancock's avatar
      1fbec0a0
    • Jared Hancock's avatar
      file: Fix saving backend char · e84030f4
      Jared Hancock authored
      Because the file type normally defaults to the system default (for fetched
      emails at least), the backend char was not saved, because the file type char
      was left at the system default. Therefore, if a file is saved to a backend
      other than the default (in the database), the data will likely be saved to
      the backend, but the file metadata will reflect the incorrect backend.
      
      The only reason the file type char was not defaulted in the
      AttachmentFile::save() method was for the migration process from osTicet 1.6
      to osTicket 1.7. This is mitigated by passing `false` specifically from the
      migration task.
      
      Since otherwise the file type char is now set, the backend char is now saved
      with the file metadata.
      e84030f4
  6. Feb 21, 2014
  7. Feb 20, 2014
  8. Feb 19, 2014
  9. Feb 18, 2014
    • Jared Hancock's avatar
      Careful transcoding attachments with a charset · 9a5bdb72
      Jared Hancock authored
      If a non-text attachment specifies a charset in the content-type header,
      don't transcode the content before saving it to the database. This can
      corrupt attachments which have a header like the following:
      
      Content-Type: application/pdf; charset=UTF-8
      
      Since a PDF contains binary data, coercing it to UTF-8 encoding will drop
      characters not valid in UTF-8 and will corrupt the attachment data.
      9a5bdb72
    • Jared Hancock's avatar
      tnef: Strip null bytes from attachment filenames · 2e106265
      Jared Hancock authored
      Also support the TransportName in the properties list and prefer it over the
      attachment-level attribute, as it is Unicode encoded.
      2e106265
Loading