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.
      1d18663b
    • 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.
      41d084f1
    • 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"
      argument.
      6d9bd63c
  2. 25 Jul, 2014 1 commit
  3. 03 Jun, 2014 1 commit
    • Kevin Falcone's avatar
      Let you Quick Create in Queues that don't define the new status · d1f38786
      Kevin Falcone authored
      Since we don't offer Status in the Quick Create widget, we should just
      let Create pick the on_create default from the Queue's lifecycle.
      
      While in here, update RT::Ticket::Create to have less lying around what
      to pass for Status (valid statuses haven't listed been in
      RT::Queue in 4.0 or 4.2).
      
      We started using the default from the Queue's Lifecycle in b206b50a,
      which is the same commit where we stopped hardcoding 'new' in
      RT::Ticket::Create.
      
      Found in RTIR user since 3 of the 4 RTIR queues don't allow tickets
      with the new status.
      d1f38786
  4. 27 May, 2014 2 commits
    • Alex Vandiver's avatar
      Switch existing code to using LookupType with LoadByName, to be explicit · 487df4d9
      Alex Vandiver authored
      To set an example for future code, transition away from the 'Queue'
      argument, in preference to LookupType and ObjectId.  This helps clarify
      the type of custom field that is expected to be returned.
      Simultaneously, switch to using IncludeGlobal where the code would
      benefit from such.
      487df4d9
    • Alex Vandiver's avatar
      Document but deprecate the old names for LoadByName · 2b181e47
      Alex Vandiver authored
      While it is tempting to officially deprecate these, they are in use in
      core RT and in extensions, and introducing new deprecations during a
      stable series is unwise.  Suffice to document them as deprecated, and
      migrate exsting uses away from the, though not produce deprecation
      warnings.
      2b181e47
  5. 15 May, 2014 1 commit
  6. 24 Apr, 2014 2 commits
  7. 23 Apr, 2014 1 commit
  8. 16 Apr, 2014 1 commit
  9. 11 Feb, 2014 1 commit
  10. 04 Feb, 2014 1 commit
    • Alex Vandiver's avatar
      Skip custom fields that do not apply to the ticket/transaction · e092e23a
      Alex Vandiver authored
      RT::Interface::Web::CreateTicket munges the query parameters to pass
      Customfield-42 to RT::Ticket::Create, as of be3529af.  An important
      change made in this commit is that previously, transaction custom fields
      were passed through with their keys unmodified -- that is, as
      Object-RT::Transaction--Customfield-42.
      
      After be3529af, the information about if the CF was a Ticket or
      Transaction custom field has been lost by the time the CFs are being
      iterated.  This led to attempting to add values for Transaction CFs on
      Ticket objects, and vice versa -- and thus warnings in the UI of "Custom
      field 42 does not apply to this object" for every applied transaction
      CF.
      
      Only attempt to add CF values to objects if they are of the correct
      class.
      e092e23a
  11. 07 Jan, 2014 1 commit
  12. 06 Jan, 2014 2 commits
  13. 31 Dec, 2013 2 commits
  14. 21 Nov, 2013 1 commit
  15. 03 Sep, 2013 1 commit
    • Ruslan Zakirov's avatar
      Process Sign/Encrypt values later on update · 528e0fae
      Ruslan Zakirov authored
      A value for Sign or Encrypt of undef is an indication of "do whatever
      the queue's options say."  d3341b78 resolved a bug of inserting array
      references into X-RT-Sign, but in doing so lost the possibility to pass
      undef into ProcessUpdateMessage, and have the queue default kick in.  In
      practice, this is only relevant if the signing controls were not
      submitted, but customizations may do so.
      528e0fae
  16. 24 Aug, 2013 2 commits
  17. 16 Jul, 2013 1 commit
  18. 02 Jul, 2013 1 commit
  19. 13 Jun, 2013 1 commit
  20. 10 Jun, 2013 1 commit
  21. 24 May, 2013 1 commit
  22. 23 May, 2013 1 commit
  23. 02 May, 2013 1 commit
    • Alex Vandiver's avatar
      Ensure that subjects cannot contain embedded newlines · 03d71ac3
      Alex Vandiver authored
      The default templates embed the ticket's subject in the outgoing Subject
      header -- but have no way to ensure that the subject does not contain
      newlines, which could be used to insert additional headers.
      Programmatically restricting templates from inserting newlines in the
      header section is both difficult and overly limiting, as there are valid
      reasons to do so.
      
      Strip all newlines from Subject headers.  While this does resolves the
      issue for all core RT templates, solving it more generally is
      unfortunately not feasable.
      03d71ac3
  24. 01 May, 2013 1 commit
    • Alex Vandiver's avatar
      Preserve original case of defined statuses · 3af6cb05
      Alex Vandiver authored
      When normalizing lifecycle configurations, use the original case that
      they were written in for display.  This allows code which depended on
      the apparent casing of $ticket->Status to still continue to function,
      even while the back-end status is stored in lower-case.
      
      For simplicity of look-up, keys of the lifecycle are stored in
      lower-case, while lists of statuses are stored in their canonical case.
      3af6cb05
  25. 30 Apr, 2013 1 commit
    • Alex Vandiver's avatar
      Canonicalize on lower-case for statuses, which are now case-insensitive · 798505e6
      Alex Vandiver authored
      Prior to the merge of lifecycles (in 2ad74ba2), statuses were fully
      case-sensitive.  This meant that attempts to set the status to 'OPEN'
      would fail, as the case did not match the supported 'open' status.
      Lifecycles made checks for _validation_ of statuses case-insensitive,
      but did not spread that property to many other parts of the system --
      including rights, transitions, and searching.
      
      Canonicalize all statuses to lower-case in the database, and make the
      remaining entry points into the API lower-case as well.  This also
      requires checking that all statuses described in lifecycles are
      correctly in lower-case.  While using perl 5.16's "fc" operator would be
      more correct in this case, this is not possible on all versions of Perl
      that RT currently runs on.
      798505e6
  26. 18 Apr, 2013 1 commit
    • Jim Brandt's avatar
      Change _CurrentUserHasRightToSetOwner to public CurrentUserCanSetOwner · ace3dda2
      Jim Brandt authored
      Make public and rename to CurrentUserCanSetOwner to make it
      consistent with other CurrentUserCan method names.
      
      Meld _IsProposedOwnerChangeValid into CurrentUserCanSetOwner to
      handle all of the logic in one place and provide a single
      response from CurrentUserCanSetOwner. This simplifies SetOwner
      and makes CurrentUserCanSetOwner suitable for calling to test
      for owner change permissions in the context of the current
      ticket.
      ace3dda2
  27. 17 Apr, 2013 1 commit
    • Alex Vandiver's avatar
      Force internal RT values for ticket Type to lower-case · 15a18f9f
      Alex Vandiver authored
      The three values for Type that RT uses internally are 'ticket',
      'approval', or 'reminder'; for the most part, these are not exposed to
      the user.  The exception to this is when generating approvals, as the
      CreateTickets action requires the user to specify the Type of the ticket
      created.  Improper casing on the "approval" type is a common, and
      frustrating, mistake.
      
      Be liberal in what case RT accepts for its core types, but consistently
      use lower-case in those values when they are stored.  As external
      systems may rely on case-sensitivity of non-core values for Type,
      preserve the case sensitivity of those values.
      15a18f9f
  28. 05 Apr, 2013 1 commit
    • Jim Brandt's avatar
      Add a ReassignTicket right to allow owner changes on owned tickets · 12c1c7ac
      Jim Brandt authored
      Users have frequently requested the ability to change the owner on
      a ticket that already has an owner. Previously RT required you to own
      a ticket to change the owner, so you had to steal a ticket owned by
      someone else, then set the owner. The new ReassignTicket right allows
      users to change owner directly (reassign tickets).
      12c1c7ac
  29. 02 Apr, 2013 1 commit
    • Ruslan Zakirov's avatar
      add IsMerged boolean column to reflect id != EffectiveId · 58e115db
      Ruslan Zakirov authored
      Most of queries on Tickets has id == EffectiveId condition
      that is required to skip merged tickets. Usually percentage
      of merged tickets is very low, so this condition is true.
      However, DBs like Pg and Oracle estimate number of returned
      records very wrong. Each column is very distinct and statisticly
      speaking chance that one record has the same value in id and
      EffectiveId is low, but this is only true when correlation
      is not accounted and it's not accounted in mentioned DBs.
      
      We add IsMerged column with "boolean" type that reflects
      id != EffectiveId. It fixes estimations of DB optimizers.
      Query execution plans get better.
      
      Instead of adding the column we could use NULLs in EffectiveId
      for records where now id = EffectiveId, but this means ORed
      conditions in JOIN clause for rare queries. Tests show that
      such solution result in terrible perfomance degradation on
      mysql in these rare situations.
      58e115db
  30. 15 Mar, 2013 1 commit
    • Ruslan Zakirov's avatar
      don't record transactions for Time* fields on merge · e9a2f200
      Ruslan Zakirov authored
      1) merge shouldn't generate any transactions except merge
      2) recording Time* change transaction mess numbers in history.
         As target ticket gets all transactions from both sides then
         history is already correct. Yes, numbers in the history are
         strange, for example you can have two txns saying time worked
         was changed from 0 to X and from 0 to Y, but the difference
         is what's important and is correct.
      e9a2f200
  31. 12 Mar, 2013 2 commits
  32. 24 Jan, 2013 1 commit
    • Thomas Sibley's avatar
      Check the return value of RT::URI->FromURI instead of ->Resolver · 4f107820
      Thomas Sibley authored
      FromURI always sets a resolver, even on failure.  Error checking which
      only looks at ->Resolver is broken and checking ->Scheme on top of that
      is just patching over the bug and relying on the internals of
      RT::URI::base.  FromURI returns a useful success or failure value; just
      use that.
      4f107820