Skip to content

GitLab

Switch branch/tag
  1. 24 Jun, 2014 1 commit
  3. 19 Jun, 2014 1 commit
  5. 15 Jun, 2014 1 commit
  7. 13 Jun, 2014 1 commit
  9. 08 Jun, 2014 1 commit
  11. 05 Jun, 2014 3 commits
  13. 12 May, 2014 1 commit
  15. 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
  17. 30 Apr, 2014 1 commit
  19. 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
  21. 14 Apr, 2014 1 commit
  23. 07 Apr, 2014 1 commit
  25. 02 Apr, 2014 1 commit
  27. 30 Mar, 2014 1 commit
  29. 27 Mar, 2014 1 commit
  31. 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
  33. 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
  35. 24 Mar, 2014 1 commit
  37. 06 Mar, 2014 1 commit
  39. 27 Feb, 2014 1 commit
  41. 25 Feb, 2014 1 commit
  43. 24 Feb, 2014 1 commit
  45. 23 Feb, 2014 2 commits
  47. 12 Feb, 2014 2 commits
  49. 11 Feb, 2014 1 commit
  51. 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
  53. 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
  55. 07 Jan, 2014 2 commits
  57. 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
  59. 22 Dec, 2013 1 commit
  61. 17 Dec, 2013 2 commits
  63. 26 Nov, 2013 1 commit
  65. 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