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.
  2. 06 Jun, 2014 1 commit
    • Kevin Falcone's avatar
      Don't attempt to parse IP/Date(Time) CFs if value is NULL · 9e7f3841
      Kevin Falcone authored
      We pass NULL into the Date/IP parsing logic *before* we get to the check
      which says "Oh, are you saying CF.{foo} IS NULL?  Then just left join to
      OCFV and be done with it".  This causes warnings and errors in the logs
      from trying to parse NULL as a Date or IP.  We did the right thing and
      executed the LEFT JOIN anyway, but it caused a lot of noise.
  3. 05 Jun, 2014 1 commit
  4. 15 May, 2014 1 commit
  5. 06 Jan, 2014 2 commits
  6. 26 Aug, 2013 1 commit
    • Alex Vandiver's avatar
      Avoid warnings and build better queries on CF limits with role rights · a4c8bfa4
      Alex Vandiver authored
      It is possible to create limits on custom fields which you don't have
      global rights on, only role rights (via a queue, for instance).  Due to
      the lack of context object when loading CFs in a search context (as
      there is no clear queue/ticket to use), a simple ->Load returns an
      object which the current user has no rights on.  This causes warnings
      when attempting to inspect properties of the CF to determine how to
      build the query.
      As $cf never escapes beyond _LimitCustomField and _CustomFieldJoin, and
      is only used to better be able to build optimal queries, simply load as
      the system user.  This does not impact the results returned, but merely
      allows more optimal queries to be generated.
      The other possibility would be to switch to calling ->__Value() for all
      accesses, to skip access control.  However, this is complicated by calls
      to non-column methods such as ->SingleValue; as such, loading as the
      system user was deemed a cleaner solution.
  7. 20 Aug, 2013 2 commits
  8. 11 Jul, 2013 2 commits
    • Thomas Sibley's avatar
      Refactor _CustomFieldLimit to use a LookupType in %FIELD_METADATA · 692a7a42
      Thomas Sibley authored
      Potential new search clauses, such as searching transaction CFs, want to
      match all the different ways that ticket CFs can.  It makes sense to
      just wrap the limits in a LookupType change (especially since
      _CustomFieldLimit happens to be recursive for IP and Date searches).
    • Thomas Sibley's avatar
      Refactor _CustomFieldJoin to take a LookupType · 8af657b4
      Thomas Sibley authored
      … so that we can join to the correct table if not Tickets.  An
      extensible registration system is introduced to determine how to join
      CFs to applied objects.  The join used depends on the tuple of
      (collection class, lookup type).  For example, consider that both
      (RT::Ticket, RT::Queue-RT::Ticket) and (RT::Queue, RT::Queue) require no
      additional join (so they return "main").
      This lets _CustomFieldJoin handle joining for transaction CFs or other
      CFs which may want to be searched.
  9. 03 Jul, 2013 1 commit
  10. 02 Jul, 2013 1 commit
  11. 01 Jul, 2013 1 commit
  12. 29 Jun, 2013 2 commits
  13. 27 Jun, 2013 1 commit
  14. 18 Jun, 2013 1 commit
    • Alex Vandiver's avatar
      CF key and CF to order by must be passed as two different values · 63ca3d85
      Alex Vandiver authored
      0f6ee87b refactored CF ordering into _OrderByCF; in doing so, the new
      _OrderByCF function was written to take a set of ordering information
      and a custom field.  However, in cases where the CF could not be
      uniquely determined, what it was _passed_ was "$queue.$field".  This was
      in turn used internally to JOIN against CustomFields.Name, and found no
      results.  Because the JOIN was not a LEFT JOIN, this caused no rows to
      be returned.
      Like _CustomFieldJoin itself, the CF key must be passed separately from
      the customfield name or object.  Undo the slightly overzealous
      refactoring to force callers to use their additional information to
      separate out different CF keys.
  15. 13 Jun, 2013 1 commit
  16. 04 Jun, 2013 2 commits
  17. 03 Jun, 2013 1 commit
  18. 01 Jun, 2013 1 commit
  19. 28 May, 2013 2 commits
  20. 24 May, 2013 5 commits
    • Alex Vandiver's avatar
      Force group names to be case-insensitive · b8019b40
      Alex Vandiver authored
    • Ruslan Zakirov's avatar
      warn on case sensitive searches · c3c06440
      Ruslan Zakirov authored
      Because of historical reasons, RT's searches were marked as case
      sensitive in RT::SearchBuilder::Limit, although callers often expected
      them to be case insensitive.
      Mixing case sensitive and case insensitive searches by the same column
      causes problems on Pg and Oracle -- especially as the case-sensitivity
      of the search and any indexes may cause them to not be used.
      This adds code to catch, for specific columns, cases where CASESENSITIVE
      is not explicitly specified, and throws a warning.
    • Ruslan Zakirov's avatar
      deprecate Principal.ObjectId · f70178f2
      Ruslan Zakirov authored
      ObjectId is always equal to id and we mix usage in many
      places and almost don't use ObjectId.
    • Ruslan Zakirov's avatar
      deprecate Groups.Type column · 71fcde32
      Ruslan Zakirov authored
      Groups records were using either Name or Type, actually only
      user defined groups were using Name.
      We deprecate Type in favor of Name, but keep it in DB for 4.2
      and remove in 4.4. Attempts to read Type, set Type, search by
      Type throw deprecation warning, but still work. Also, Type and
      Name are kept equal.
    • Ruslan Zakirov's avatar
      call SUPER method later and in one place · ac284f23
      Ruslan Zakirov authored
      would allow us to inject %ARGS checking after
      existing sanity checks
  21. 10 May, 2013 6 commits
    • Alex Vandiver's avatar
    • Alex Vandiver's avatar
      Save possibly multiple calls to $cf->Type · fe2640c7
      Alex Vandiver authored
    • Alex Vandiver's avatar
      Improve !=, and note the limitations of NOT LIKE, with multi-value LargeContent · 26bbd612
      Alex Vandiver authored
      When attempting to perform a != or NOT LIKE search on a multi-value CF,
      with a value longer than 255 characters, the search limits the LEFT JOIN
      based on the opposite condition.  However, it assumed the Content column
      unless explicitly instructed; this means that, when checking against a
      long string, it would return false positives.
      For the case of !=, we can determine which of Content or LargeContent to
      examine ahead of time.  Unfortunately, for NOT LIKE, we would be forced
      to use a more complex limit to search both:
         Content LIKE '%value%' OR
         ((Content = '' OR Content IS NULL) AND LargeContent LIKE '%value%')
      ...and such a limit cannot be added to a LEFTJOIN clause using the
      current DBIx::SearchBuilder.
    • Alex Vandiver's avatar
      Improve != and NOT LIKE searching in combination with LargeContent · 8ee88206
      Alex Vandiver authored
      When attempting to perform a NOT LIKE (or != with a long value) on a
      single-value CF, the search is limited by:
        Content NOT LIKE '%value%' OR
        ((Content = '' OR Content IS NULL) AND LargeContent NOT LIKE '%value%')
      However, it must also be open to the possibility that the ticket did not
      contain a value for that CF, which is a valid method of having
      not-that-value.  It thus also added the possibility for lack-of-value by
      further limiting by:
         OR Content IS NULL
      Unfortunately, as Content is nearly definitionally NULL for rows with
      LargeContent, this results in a false positives where LargeContent
      matches '%value%' and thus the ticket should not match.
      The limitation of "or the ticket could fail to have a value for the CF"
      is better stated by checking that OCFV.id IS NULL, rather than
      OCFV.Content IS NULL; switch to this to avoid the false positive.  Note
      that $column cannot be defined at this point, as it has previously been
      checked for truth, and return'd already in such cases, so the removing
      the reference to $column is intentional.
    • Alex Vandiver's avatar
      Improve != searching in combination with LargeContent · eca2558b
      Alex Vandiver authored
      When attempting to perform a != on a single-value CF, with a value
      longer than 255 characters, the search is limited by:
        ((Content = '' OR Content IS NULL) AND LargeContent != '...')
      The limitation «Content != '...' OR » was intentionally omitted, based
      on the proposition that a value longer than 255 characters cannot relate
      to the Content field.  However, _any_ value in the Content field
      necessarily implies a custom field value which does not match the long
      string (because it is too short), meaning that the ticket should be
      contained in the resultset.
    • Alex Vandiver's avatar
      Merge two parallel content search branches · 0011c4ec
      Alex Vandiver authored
      The only occasion upon which Content should not be searched is if the
      search is an equality search and the value we are matching is certainly
      larger than would fit into Content.  Similarly, skip looking at
      LargeContent iff the value is short and it is an equality.
  22. 02 May, 2013 4 commits