1. 24 Jun, 2014 1 commit
  2. 19 Jun, 2014 1 commit
  3. 15 Jun, 2014 1 commit
  4. 13 Jun, 2014 1 commit
  5. 08 Jun, 2014 1 commit
  6. 05 Jun, 2014 3 commits
  7. 12 May, 2014 1 commit
  8. 09 May, 2014 1 commit
    • Yuliya Bozhko's avatar
      Some artefact refactoring (Bug #1298646) · 3ba72d71
      Yuliya Bozhko authored and Robert Lyon's avatar Robert Lyon committed
      
      
      Fixes in this patch:
      
      - Moved artefact.php to artefacts directory to separate it from pages.
      - Fixed reference to a wrong 'artefactonlyviewableinview' string.
      - Removed add_to_render_path() and its calls which have no purpose at all.
      - Removed 'artefact_parent_cache' table.
      - Removed cron jobs related to 'artefact_parent_cache' from DB.
      - Added 'path' column in 'artefact' table to easier calculate hierarchy.
      - Added ArtefactTest.php for artefacts unit tests
      
      Change-Id: Ia14cd85b94c32a950354446ee3565bd2964c625c
      Signed-off-by: default avatarYuliya Bozhko <yuliya.bozhko@totaralms.com>
      3ba72d71
  9. 30 Apr, 2014 1 commit
  10. 16 Apr, 2014 1 commit
    • Nathan Lewis's avatar
      Improvements to notification system (Bug #1299993) · 63e0484d
      Nathan Lewis authored
      
      
      - Each activity type can specify a default notification method. They default
        to 'email' to remain backwards compatible.
      - Each activity type can specify if it is allowed to be set to 'none'. Defaults
        to 'allowed' for backwards compatibility.
      - Removed 'required' from notification settings - it didn't make sense, and the
        change above deals with this in a better way.
      - The site wide defaults for each activity type can be edited in
        Site options -> Notification settings. These are applied to new users or
        whenever a user does not have the appropriate usr_activity_preference records.
      - Removed 'Default notification method' as it's functionality is now covered by
        the change above.
      - There is a separate help next to each activity type to explain what messages
        will be affected by the setting.
      
      Change-Id: I131cdeefbeaa8e43688aefd9d770fc8cb9bceea8
      Signed-off-by: default avatarNathan Lewis <nathan.lewis@totaralms.com>
      63e0484d
  11. 14 Apr, 2014 1 commit
  12. 07 Apr, 2014 1 commit
  13. 02 Apr, 2014 1 commit
  14. 30 Mar, 2014 1 commit
  15. 27 Mar, 2014 1 commit
  16. 26 Mar, 2014 2 commits
    • Robert Lyon's avatar
      Increment the artefact internal version number (Bug #892684) · 24e8700e
      Robert Lyon authored
      Commit b5c9e316
      
       incremented the
      artefact.internal DB version, but not the human-readable version.
      
      Have bumped the version to 1.2.0. Also removed the section of lib/db/upgrade.php
      that tells it to upgrade the artefact.internal plugin, because that'll happen
      automatically.
      
      Change-Id: Ie4ac77db99bc9ab5dc2901810a1283158ad4735d
      Signed-off-by: Robert Lyon's avatarRobert Lyon <robertl@catalyst.net.nz>
      Signed-off-by: Aaron Wells's avatarAaron Wells <aaronw@catalyst.net.nz>
      24e8700e
    • Tobias Zeuch's avatar
      New watchlistnotification Plugin (Bug 1041228) · 6fe99d5f
      Tobias Zeuch authored and Robert Lyon's avatar Robert Lyon committed
      
      
      Introducing a new plugin watchlistnotification that responds to the
      events saveartefact, blockinstancecommit and deleteblockinstance. It
      stores the changed view and the blockinstance in a table watchlist_queue
      and checks via cron if there were any changes on a view and if for that
      view the last change has happened some time ago (the minutes are stored
      in config under watchlistnotification_delay, the default is 20min).
      
      If so, a message is generated that informs the watchlist recipient about
      which view and which block-instances on this view have been touched
      (added or changed).
      
      As there is no way to disable the built-in/old watchlist-notification-
      system, this is disabled in the mahara-core code, that is,
      artefact/lib.php and lib/view.php
      
      Change-Id: I039c5285cdd1b09ed9eb38a647e0c1510c3cabb9
      Signed-off-by: default avatarTobias Zeuch <tobias.zeuch@kit.edu>
      6fe99d5f
  17. 25 Mar, 2014 1 commit
    • Aaron Wells's avatar
      Prevent new users from taking spammy actions · 7b08f438
      Aaron Wells authored
      Bug 1252101
      
      1. New users get 2 "new user points" on their user record
      
      2. While they have these, they're on probation and can't post
      links in public places, or make public pages.
      
      3. "new user points" are decreased each time a non-probationary
      user responds to a forum post by the user
      
      4. Admins & Staff are automatically non-probationary
      
      Change-Id: Ibccd2e330945f66b07aac062c4f51b67a0c0dba2
      7b08f438
  18. 24 Mar, 2014 1 commit
  19. 06 Mar, 2014 1 commit
  20. 27 Feb, 2014 1 commit
  21. 25 Feb, 2014 1 commit
  22. 24 Feb, 2014 1 commit
  23. 23 Feb, 2014 2 commits
  24. 12 Feb, 2014 2 commits
  25. 11 Feb, 2014 1 commit
  26. 24 Jan, 2014 1 commit
    • Robert Lyon's avatar
      Allow site_content to be institution specific (bug #1254299) · d268d11b
      Robert Lyon authored
      
      
      Changes include:
      - added an institution column to the site_content table
      - added an 'Edit site pages' page under Admin -> Institutions
      that is accessibe by institution admins
      - added an 'institution' option to the edit site pages form - this is
      a hidden field if user can edit only one institution.
      
      On upgrade it updates the site_content table to give current data the
      institution on 'mahara' (incl. local site pages) and for each
      institution it replicates the data already in the db for the default site (excl.
      local site pages) so that every site has their own versions, which can
      be adjusted as one sees fit.
      
      On creation of new institution it creates the rows in site_content
      table but with the default strings (like what you see when you first
      install a mahara) but sets the sitepages column in institution table
      to default (mahara). On deletion of institution it removes the rows in
      site_content.
      
      A user on login sees the institution site page based on what
      institution theme they see.
      
      On logout the 'lastinstitution' cookie is set allowing for them to see
      institution specific site pages.
      
      The 'No institution' (mahara) site pages can only be edited through
      Configure site -> Edit site pages.
      
      Also allow for an institution site page to be viewed if 'institution'
      variable is passed to it eg terms.php?institution=testing allowing for
      another way to access info when logged out.
      
      Change-Id: I2ed30b63c15bf676d83eb2231f48c4ca23ce8b53
      Signed-off-by: Robert Lyon's avatarRobert Lyon <robertl@catalyst.net.nz>
      d268d11b
  27. 08 Jan, 2014 1 commit
    • Aaron Wells's avatar
      Introducing the institution_config table · 5be3b920
      Aaron Wells authored
      Bug 1264429: This patch creates the table, refactors the get_institution_config() method,
      the Institution class, and the institution editing page, to use the new table.
      
      Henceforth columns should only be added to the main "institution" table if they represent
      a required setting (like name and displayname), or they need to be accessed frequently by
      direct SQL queries.
      
      Change-Id: I4564240d2c55ec2b6ec90868290a61cf4321460a
      5be3b920
  28. 07 Jan, 2014 2 commits
  29. 24 Dec, 2013 1 commit
    • Aaron Wells's avatar
      Bug 1262932: Let upgrade proceed even if schema drift can't be corrected · 2df7d4ea
      Aaron Wells authored
      In 1.8.1 we added some code to correct schema drift in Mahara sites that
      were originally installed with 1.2.0 or earlier. But, these schema
      corrections can fail if the tables contain data that violates the 
      constraints we're trying to add.
      
      This update changes that failure from a fatal error, to a warning.
      
      Change-Id: I51989b276642b8d1b7b55813aa33df86f1e52a5c
      2df7d4ea
  30. 22 Dec, 2013 1 commit
  31. 17 Dec, 2013 2 commits
  32. 26 Nov, 2013 1 commit
  33. 23 Oct, 2013 1 commit
    • Aaron Wells's avatar
      Remove "TYPE=INNODB" (incompatible with MySQL 5) · 05a25eab
      Aaron Wells authored
      Bug 1243525: Also, since it was only used in the pre-1.1 upgrade section, it's no
      longer necessary to define this at the top of upgrade.php at all
      
      Change-Id: I907467f2ffd80844fe7f3f35eeb92a51a40ad7dd
      05a25eab