1. 24 Sep, 2015 1 commit
  2. 12 Nov, 2014 1 commit
  3. 11 Mar, 2014 1 commit
    • Nathan Lewis's avatar
      Fix phpunit testing framework (Bug #1288439) · 774a884c
      Nathan Lewis authored
      - uninstall does not remove triggers that are added by
      notification/internal module, causing errors when trying to re-run
      testing (when testing, all database objects are deleted then recreated,
      but the triggers already exist).
      
      - assertType is no longer available and should use assertInternalType
      instead (for int value).
      
      - there is a typo in lib/ddl.php find_key_name function which causes
      problems when creating and removing the test db tables.
      
      - there is a logic problem in lib/ddl.php uninstall_from_xmldb_file.
      array_multisort is being used incorrectly and sometimes causes the
      primary key to be removed before foreign keys which results in a
      database error.
      
      - the function removecolumn in lib/view.php has changed and the test is
      no longer valid.
      
      Change-Id: Ibee48e557912e09cf6533132ba771bfb2c44749f
      Signed-off-by: default avatarNathan Lewis <nathan.lewis@totaralms.com>
      774a884c
  4. 22 Jan, 2014 1 commit
  5. 16 Dec, 2013 1 commit
    • Aaron Wells's avatar
      Override MySQL's check for accidental large queries · 03f4ecd3
      Aaron Wells authored
      Bug 1070046: MySQL has an optional server config option, "MAX_JOIN_SIZE",
      which throws an error if you try to run a SQL query that MySQL's strategizer
      thinks will require it to evaluate more than MAX_JOIN_SIZE rows. This is
      intended to prevent the user from accidentally running giant queries that
      will never finish, but some Mahara queries (which are large but will finish)
      can trip it. Adding SQL_BIG_SELECTS=1 tels it that our queries are *not*
      accidentally large.
      
      Change-Id: I6db4699ea765d3213d13eb93b8de098914db24e0
      03f4ecd3
  6. 14 Oct, 2013 1 commit
  7. 02 Sep, 2013 1 commit
    • Aaron Wells's avatar
      Prevent non-helpful sql_mode error when trying to connect to a UTF16 DB · 034fe443
      Aaron Wells authored
      Bug 1184450. I don't know why this works but it does. When attempting to
      connect to a UTF16 MySQL DB, if you first set the connection's character set
      to UTF8 and then try to set the SQL_MODE to POSTGRES, it errors out on trying
      to set the SQL_MODE. But if you try to set the SQL_MODE first, and *then* set
      the character set to UTF8, it works fine.
      
      Change-Id: I3528a92662708c081b15a111c625f0559fbd1c04
      034fe443
  8. 24 Feb, 2013 1 commit
  9. 17 Aug, 2012 1 commit
  10. 28 Jun, 2012 1 commit
  11. 20 Apr, 2012 1 commit
    • Richard Mansfield's avatar
      Use MySQL database collation for string literals (bug #985608) · ddc69cb0
      Richard Mansfield authored
      In MySQL, the collation for string literals in SQL expressions is
      defined by the connection collation, which can be different from the
      column collations inside the database.  When comparing string literals
      to values selected from the database, this can result in an "Illegal
      mix of collations" error, even if both the connection and the database
      use the same character set.
      
      Mahara already requires the column and connection character sets to be
      utf8, but doesn't care about the collations, so we can fix this with
      the MySQL "SET CHARACTER SET" statement, which sets the connection
      collation to match the database collation.
      
      Change-Id: Ied6fcf7062fae5aa315a43ec9ce80883e6ef5b2e
      Signed-off-by: default avatarRichard Mansfield <richard.mansfield@catalyst.net.nz>
      ddc69cb0
  12. 29 Mar, 2012 1 commit
  13. 28 Mar, 2012 1 commit
    • Richard Mansfield's avatar
      Display a message when plpgsql cannot be created (bug #960631) · c5b26f2c
      Richard Mansfield authored
      The upgrade to 1.5 requires that the plpgsql language is available in
      postgres, but sometimes (e.g. versions of postgres < 8.3), the
      database owner doesn't have permission to create the language, and the
      admin will have to do it manually.
      
      During the attempt to issue the CREATE LANGUAGE command, an sql
      exception can be thrown when the db user has insufficient privileges,
      so a generic 'nonrecoverable error occured' message is displayed
      instead of the useful message instructing the admin to create plpgsql.
      Catching the sql exception fixes this problem.
      
      Change-Id: I176bdd1eee2247426ceedc6f165156d33eefbb42
      Signed-off-by: default avatarRichard Mansfield <richard.mansfield@catalyst.net.nz>
      c5b26f2c
  14. 10 Feb, 2012 2 commits
  15. 10 Jan, 2012 1 commit
    • Richard Mansfield's avatar
      Expire users when they've been inactive for too long (bug #890929) · 81f26254
      Richard Mansfield authored
      The "Default account inactivity time" setting allows the admin to
      specify a time period after which users who have not used the site
      will be unable to login, but this is not currently enforced.
      
      This change modifies the inactivity cron job to set the expiry date to
      the current date for any user who has been inactive for longer than
      the 'defaultaccountinactiveexpire' period.  It also now considers the
      lastaccess and ctime fields as well as the lastlogin field.
      
      This allows the admin to reactivate inactive users by resetting their
      expiry dates in account settings.
      
      The active column on the user table is currently only used to decide
      whether users should be displayed in search results, and users are set
      to inactive whenever they are deleted, suspended, or expire.
      
      Change-Id: Ieaf7a0b36865af726fc2526895146373efbb2741
      Signed-off-by: default avatarRichard Mansfield <richard.mansfield@catalyst.net.nz>
      81f26254
  16. 15 Nov, 2011 1 commit
  17. 24 Aug, 2011 2 commits
  18. 13 May, 2011 1 commit
  19. 23 Feb, 2011 1 commit
  20. 01 Oct, 2010 1 commit
  21. 14 Jan, 2010 1 commit
  22. 01 Dec, 2009 1 commit
  23. 22 Oct, 2009 1 commit
  24. 03 Sep, 2009 1 commit
  25. 21 Apr, 2009 1 commit
  26. 14 Apr, 2009 1 commit
  27. 22 Jan, 2009 1 commit
  28. 15 Jan, 2009 1 commit
  29. 05 Jan, 2009 1 commit
  30. 13 Oct, 2008 2 commits
  31. 30 Sep, 2008 1 commit
  32. 21 Sep, 2008 1 commit
  33. 15 Sep, 2008 1 commit
    • Penny Leach's avatar
      More work on profile views and three new blocktypes... · 8465aa3f
      Penny Leach authored
      More work on profile views and three new blocktypes (myfriends/mygroups/myviews) to emulate current profile page TODO: - write wall blocktype - change install default profile view hook to add blocks - upgrade path (xmldb & migration) - blocktype and category and singleblockperview implementation
      
          - TESTING
      8465aa3f
  34. 18 Jun, 2008 1 commit
  35. 18 Mar, 2008 1 commit
    • Nigel McNie's avatar
      Make db_format_timestamp return null for any value that is 'empty'. · d6596676
      Nigel McNie authored
      Otherwise, $db->BindTimestamp() will return the string 'null' for 0 and '0', which no code in Mahara is expecting.
      
      Noticed as part of the previous commit, where $user->lastlogin defaulted to 0 (which was incorrect), and which db_format_timestamp was converting to 'null'.
      d6596676
  36. 20 Feb, 2008 1 commit
    • Nigel McNie's avatar
      Work around a bug in insert_record, where the table columns were cached for a... · e1c17aea
      Nigel McNie authored
      Work around a bug in insert_record, where the table columns were cached for a table the first time the table was inserted into, making it impossible to do inserts into the table in the same request if the table is changed.
      
      Added a global variable, $INSERTRECORD_NOCACHE, that can be set in order to force re-looking up the table columns.
      
      Use this feature to fix the installation of the forum interaction activity type "new post" when upgrading.
      e1c17aea
  37. 16 Feb, 2008 1 commit