1. 07 Jan, 2013 2 commits
    • Thomas Sibley's avatar
      Always declare base class before use-ing other RT:: classes · 1d241ebe
      Thomas Sibley authored
      This will help avoid weird, hard to track down load ordering bugs in the
    • Thomas Sibley's avatar
      Setup RT::Record's base classes before use-ing subclasses of itself · e0a20849
      Thomas Sibley authored
      RT::Record was attempting to load and compile subclasses of itself before it
      had declared its own base classes.  This meant those subclasses were missing
      all of the RT::Base and DBIx::SearchBuilder inherited methods at compile-time.
      Since by run-time everything was hunky dory, the ordering bug flew under the
      radar until Role::Basic introduced compile-time method checks on RT::Ticket and
      RT::Queue.  As it happens, those classes get loaded (quite indirectly) when
      RT::User is use-d.
      Module::Install::RTx::Factory ran face first into the bug (during `make
      initdb`) when attempting to require RT::System individually (which loads
      RT::Record as a base class, which loads RT::User, et cetera).
      Normal RT initialization didn't trigger the bug because RT::CurrentUser is
      loaded before RT::System in RT::InitSystemObjects().  RT::CurrentUser loads
      RT::User by way of a base class, which loads RT::Record by way a base class,
      which is able to finish compiling and setting up its parents before RT::User
      finishes loading the dependency chain which eventually invokes Role::Basic.
      The general bug is loading subclasses of yourself before declaring a base
      class, and it appears RT does that in a number of classes.  Another commit
      fixing those is forthcoming.
      The extra "use RT;" line is necessary since we're relying on RT->Config
      at compile-time in the first "use base" line.  If RT.pm is already
      loaded, as in normal system initialization, it'll do no harm; if RT.pm
      isn't loaded already, it'll load it up to avoid a compile error.
  2. 04 Jan, 2013 3 commits
    • Thomas Sibley's avatar
      Refactor ticket Status methods and behaviours into a role · c029f897
      Thomas Sibley authored
      A few error messages have changed slightly, but most behaviour is
      unchanged.  The most notable change is that tickets now record a Status
      transaction when the Status is automatically updated (via lifecycle
      maps) after a queue change.
    • Thomas Sibley's avatar
      RT::Lifecycle->Type accessor · aee2eae4
      Thomas Sibley authored
      Stashes the "effective" type of the lifecycle at the top level of the
      object, including for virtual aggregate lifecycles (i.e. lifecycles
      loaded with no name, only a type).  In cases when a lifecycle is
      requested by name with a type that conflicts with reality, ->Type will
      return the requested type, not the *declared* type of the lifecycle from
      the config.  This ensures ->Type matches the blessed lifecycle class;
      hence the "effective" type.
    • Thomas Sibley's avatar
      Refactor Lifecycle methods and behaviours into roles · 29339864
      Thomas Sibley authored
      The first use of roles in RT!  With support for extensions adding
      lifecycles on arbitrary object types, it's extremely useful to abstract
      the common behaviour patterns into roles that can be consumed by many
      Role::Basic provides a very straightforward implementation without the
      prerequisite of shoehorning all our classes into Moose's view of the
      world.  The most notable missing feature is parameterized roles.
      Instead, roles can require a method in the consuming class which returns
      the value of the "parameter".  This does limit individual role
      application to one-per-class instead of potentially many instances of
      the same parameterized role, but it is a sufficient workaround for now.
  3. 03 Jan, 2013 2 commits
    • Thomas Sibley's avatar
      Rename RT::Queue->Lifecycle to LifecycleObj for consistency · 9b11d2f6
      Thomas Sibley authored
      All other columns which reference other records use ColumnName for the
      database value and ColumnNameObj for the inflated object.  Mimic the
      same methods in RT::Ticket as well to avoid confusion, despite
      RT::Ticket not having a Lifecycle column itself.
      This reverts a small part of e904afe2 which added special handling for
      the Lifecycle column to RT::Record->Update.  With the existence of a
      LifecycleObj method, the previously existing Name handling works
      A usage of $QueueObj->Lifecycle in share/html/Admin/Queues/Modify.html
      is left as-is to fix a bug: the intention was always to use the
      lifecycle name as the current value, but instead an object was passed to
      share/html/Widget/Select:InputOnly.  Mason helpfully coerced the object
      into an array, which by happenstance led to the correct behaviour.
    • Thomas Sibley's avatar
      Set the new status *after* setting the new queue in RT::Ticket->SetQueue · 65ab3617
      Thomas Sibley authored
      This removes the need for an ugly caller() check in ValidateStatus to
      force pass if the callstack contains SetQueue anywhere.  The behaviour
      for Status now matches the other updates which depend on a successful
      queue change first.
  4. 02 Jan, 2013 1 commit
    • Thomas Sibley's avatar
      Avoid "Exiting eval via next" warnings · 705acec3
      Thomas Sibley authored
      These aren't currently triggered by any tests, but occur if objects are
      referred to by Name in the database instead of id and records support a
      corresponding ColumnNameObj method.
  5. 31 Dec, 2012 3 commits
  6. 29 Dec, 2012 1 commit
  7. 28 Dec, 2012 21 commits
  8. 27 Dec, 2012 7 commits