1. 20 Jun, 2014 1 commit
  2. 19 Jun, 2014 2 commits
  3. 17 Jun, 2014 1 commit
    • Jim Brandt's avatar
      Override BeforeWipeout and unmerge users before shredding · 9a8b2e84
      Jim Brandt authored
      If a user record has other users merged into it and they are
      not unmerged before shredding, the merged users are left in
      a state where they can't be loaded because they still point
      to another user (EffectiveId), but that id is no longer in the
      DB.
      9a8b2e84
  4. 10 Jun, 2014 3 commits
  5. 19 May, 2014 2 commits
  6. 27 Mar, 2014 1 commit
  7. 10 Feb, 2014 3 commits
    • Alex Vandiver's avatar
      Bump version to 12_03 · 556a6cf4
      Alex Vandiver authored
      556a6cf4
    • Alex Vandiver's avatar
      Clean up whitespace · c7257227
      Alex Vandiver authored
      c7257227
    • Alex Vandiver's avatar
      Keep the Disabled bit synchronized between merged users · ce06ab88
      Alex Vandiver authored
      Disabling a user did not disable all of the users merged into them.
      This caused users disabled users to apparently still appear via the web
      UI in user searches, as their merged-in (non-disabled) users often still
      matched the search.
      
      Explicitly propagate Disabled updates on users down into their merged-in
      equivalents.  Note that changes to sub-users do not propagate upward;
      loading them takes explicit effort, changing them could be more
      surpising action-at-a-distance, and introduces difficulties with dealing
      with cycles.
      ce06ab88
  8. 06 Feb, 2014 3 commits
  9. 27 Jan, 2014 1 commit
  10. 08 Jan, 2014 1 commit
  11. 24 Sep, 2013 1 commit
  12. 10 Sep, 2013 2 commits
  13. 05 Sep, 2013 1 commit
    • Ruslan Zakirov's avatar
      don't override _RecordCount · 9a7fa566
      Ruslan Zakirov authored
      This caused not merged users at the end of the collection
      to be skipped.
      
      _RecordCount is used in SB's Next to stop the iterator.
      If we change return value, but don't change storage then
      iterator stops earlier.
      9a7fa566
  14. 02 Aug, 2013 1 commit
  15. 17 Jul, 2013 2 commits
  16. 26 Jun, 2013 1 commit
  17. 10 Jun, 2013 2 commits
  18. 07 May, 2013 1 commit
    • Thomas Sibley's avatar
      Always lookup effective ids on RT::User · 20fbf53c
      Thomas Sibley authored
      This allows merged users to be properly picked up when loaded via an
      RT::CurrentUser object, such as during login.
      
      An equivalent core change, on 4.0/currentuser-attributes, is also
      necessary to prevent inconsistency.
      20fbf53c
  19. 25 Mar, 2013 1 commit
    • Alex Vandiver's avatar
      Fix "Merge User" box during user creation · c1a2128a
      Alex Vandiver authored
      c7467a91 missed the one case in which users do not have an attribute --
      namely, when the user object does not exist yet.  During user creation,
      do not present the "Merge User" box at all, as merging would not work.
      c1a2128a
  20. 22 Mar, 2013 2 commits
  21. 12 Mar, 2013 1 commit
  22. 27 Feb, 2013 3 commits
    • Alex Vandiver's avatar
      Ensure that $canonical_self, when inspected, still has unmerged data · b13c4340
      Alex Vandiver authored
      $canonical_self->SetComments() calls a $self->Load( $self->id ) during
      the process of updating the Comments.  Because this now loads the data
      of the user we are merged into, the information recorded on $merged was
      always contentless -- namely, it always showed the the user had been
      merged into itself.
      
      Swap the order of the ->SetComments calls, to ensure that
      $canonical_self is still the user being merged in when it is inspected
      to record data on $merge.
      b13c4340
    • Alex Vandiver's avatar
      Explicitly checking EffectiveId is also unneeded in CanonicalizeEmailAddress · 9f9da780
      Alex Vandiver authored
      As CanonicalizeEmailAddress uses ->LoadByCols to look up the email
      address, and we override LoadByCols to chase EffectiveId after a
      successful LoadByCols call, looking up EffectiveId again is unnecessary.
      
      The recursive call is kept, on the possibility that
      CanonicalizeEmailAddressMatch will match the _new_, canonicalized form.
      This preserves the previous behavior.
      9f9da780
    • Alex Vandiver's avatar
      Explicitly canonicalizing both $merged and $canonical_self is not required · 569bd681
      Alex Vandiver authored
      As the path to get both user objects uses ->Load, which calls
      ->LoadByCols, which we have overridden, we already have the most
      canonical form.  Checking it for EffectiveId is unnecessary and
      wasteful.
      569bd681
  23. 26 Feb, 2013 1 commit
  24. 25 Feb, 2013 3 commits