1. 05 May, 2010 1 commit
  2. 04 May, 2010 1 commit
  3. 03 May, 2010 1 commit
  4. 28 Apr, 2010 1 commit
  5. 27 Apr, 2010 1 commit
  6. 29 Mar, 2010 2 commits
  7. 24 Mar, 2010 1 commit
  8. 23 Mar, 2010 1 commit
  9. 03 Nov, 2009 1 commit
  10. 27 Oct, 2009 1 commit
  11. 26 Oct, 2009 1 commit
  12. 14 Oct, 2009 1 commit
  13. 08 Oct, 2009 1 commit
  14. 15 Sep, 2009 1 commit
  15. 17 Aug, 2009 1 commit
  16. 31 Jul, 2009 3 commits
    • Nigel McNie's avatar
      [UPSTREAM] Simplify notify_user so it's easier to see when we need to update the activity table. · 714e9791
      Nigel McNie authored
      This gets rid of the PluginNotificationInternal::update_notification method,
      which was way overkill for what it actually needs to be. We only actually need
      to update the notification if it needs to be marked as read or its URL needs to
      change.
      714e9791
    • Nigel McNie's avatar
      [UPSTREAM] Remove $this->internalid completely, replace with a local variable. · 185d4f6a
      Nigel McNie authored
      Noticed as part of the previous commit. This variable doesn't need to exist on
      the object, we can just pass it around where needed.
      185d4f6a
    • Nigel McNie's avatar
      [UPSTREAM] Prevent internal notifications being 'stolen' from users in rare circumstances. · a2b2fcb8
      Nigel McNie authored
      This was happening because a variable ($userdata->internalid) was being used
      for two purposes - one to hold the ID of the notification as put into the
      notification table, and also to see if the notification needed to be updated
      after having been inserted for any reason (either the notification was sent by
      another method successfully so it needed to be marked as read, or the URL set
      in the table needed to change post-insert).
      
      The particular method this bug is in is called repeatedly in a loop, once for
      each user who is getting a notification. Unfortunately, $userdata->internalid
      comes from converting the object to a stdclass, and the previous internalid is
      set on the class too. So if the notification didn't need to be marked as read
      or have its url changed (e.g. it's a forum post notification going straight to
      the activity log), then it would still be updated - this would have been
      harmless, but the update would ovewrite the user who owned the notification.
      
      Will make a few more patches to make the code more consise and limit the chance
      of more damage. This problem took me hours to debug...
      a2b2fcb8
  17. 02 Jul, 2009 2 commits
  18. 25 Jun, 2009 1 commit
  19. 23 Mar, 2009 1 commit
  20. 19 Mar, 2009 1 commit
  21. 29 Dec, 2008 3 commits
  22. 22 Dec, 2008 1 commit
  23. 10 Dec, 2008 1 commit
  24. 15 Sep, 2008 1 commit
  25. 10 Sep, 2008 1 commit
  26. 03 Jul, 2008 1 commit
  27. 19 Mar, 2008 1 commit
  28. 14 Mar, 2008 1 commit
  29. 16 Feb, 2008 2 commits
  30. 12 Feb, 2008 1 commit
  31. 05 Feb, 2008 1 commit
  32. 29 Jan, 2008 1 commit
  33. 28 Jan, 2008 1 commit