1. 17 May, 2015 1 commit
  2. 27 Mar, 2015 1 commit
    • Aaron Wells's avatar
      Bug 1427901: Performance improvements for cron · b4c1755f
      Aaron Wells authored
      - Cron doesn't need to run auth_setup()
      - Don't run cron when site is closed for upgrade
      - Get rid of forcelocalupgrade() option because it's no longer needed
      Change-Id: I1718b13337c50fadc0573d04f5b3d6b20bc842c2
  3. 17 Mar, 2015 1 commit
  4. 03 Mar, 2015 1 commit
    • Nigel Cunningham's avatar
      (Bug1352028) Add a JSON progress bar for bulk operations. · 55a8deb8
      Nigel Cunningham authored
      This patch adds a JSON progress meter (I'll call it that to avoid confusion
      with progress bars) to the bulk uploading of users, groups and group
      memberships and the bulk export and import of users (LEAP), so the user can see
      the progress of the operation and not just the submit button changed to
      'Processing..' and whatever indication their browser gives while waiting for
      The bulk export and import are minor rewrites, replacing the old iframe based
      progress bar and the associated multiple pages and additional template file in
      the case of the bulk export, and the recursive redirect-to-self of the bulk
      To accomplish the display of the progress bar during the operation, we make the
      PHP session be closed (read only) except when changes need to be made. This is
      for the most part a straightforward change in session.php as it's the only
      direct accessor. In other places, we replace direct accessing of the session
      variable ($_SESSION) with use of the session class ($SESSION) so that it can
      reopen the session, make the change and close the session again.
      There is one more aspect to all of this: with previous behaviour, multiple
      requests for the same session would queue, taking the session lock in turn.
      After this patch is applied, they can proceed in parallel, allowing greater
      throughput. There is no additional locking requirement because the issues are
      the same as those already dealt with in allowing multiple PHP threads to
      process requests from different sessions at the same time.
      I have sought to make the progress meter nice and generic, so it can be used in
      the other bulk imports and exports too.
      Paradoxically, these changes don't just make the import seem to be faster, it
      actually is.. at least in the case of users and groups.
      Times for importing 1000 users, groups and memberships, averaged over 3 runs
      each (Wall time, not CPU time - but the relationship is the same).
                      Without Progress     With Progress
      Users                166s               155s
      Groups                85s                78s
      Memberships           20s                19s
      Change-Id: Iec15c57db32c77994edb80c71d65591de51a95e4
      Signed-off-by: default avatarNigel Cunningham <nigelc@catalyst-au.net>
  5. 08 Feb, 2015 1 commit
    • Nigel Cunningham's avatar
      Fix form submission for no-reply email setting (Bug #946880) · 1a83b282
      Nigel Cunningham authored
      After installation or upgrade, if the user clicks on a warning
      about the no-reply email address and they also need to set up
      required fields, the URL for the no-reply email address is
      initially overridden by the required fields form. This patch
      causes us to cleanly drop back out of the required fields form
      code after the required fields form is successfully submitted,
      letting the user then see the no-reply email address form.
      This method of handling things will also work for any other
      time the required fields form hijacks a URL - after the required
      fields are set, the user will get the page they asked for.
      Change-Id: I32aecaf898d02a572a5ab7b5c18bfaefc5607e41
      Signed-off-by: default avatarNigel Cunningham <nigelc@catalyst-au.net>
  6. 05 Feb, 2015 1 commit
  7. 03 Feb, 2015 1 commit
  8. 13 Jan, 2015 1 commit
  9. 29 Dec, 2014 1 commit
  10. 09 Dec, 2014 1 commit
  11. 04 Dec, 2014 1 commit
  12. 20 Nov, 2014 1 commit
    • Robert Lyon's avatar
      Session is not invalidating after password change (Bug #1363873) · f103c650
      Robert Lyon authored
      - Create an account, say User A and logout as admin.
      - In one browser login (this will be the hacker user)
      - In another browser reset pass via forgotten pass link
      What should happen:
      User in browser two should be able to reset pass then navigate about
      as when normally logged in. User in browser one should be forced to
      login again as their user sessionid is not valid anymore.
      Before patch:
      malicious user still has access until $USER->logout_time time expires
      After patch:
      malicious user foreced to re-login straight away on next page load
      Change-Id: I42ad907e5ffa7c128742a159116cf20dc6cd9b8a
      Signed-off-by: Robert Lyon's avatarRobert Lyon <robertl@catalyst.net.nz>
  13. 24 Sep, 2014 1 commit
  14. 21 Aug, 2014 1 commit
  15. 19 Jun, 2014 2 commits
    • Robert Lyon's avatar
      Checking and removing of expired password requests (Bug #1296472) · fc9ee332
      Robert Lyon authored and Aaron Wells's avatar Aaron Wells committed
      Seen as we already have an expiry column in the db we might as well
      use it.
      Change-Id: I4de92289edff40e26c74ff8b9e4a77cf9bd8ccf2
      Signed-off-by: Robert Lyon's avatarRobert Lyon <robertl@catalyst.net.nz>
    • Aaron Wells's avatar
      Drop support for auth plugins using site-config functions for instance config · e53a30c0
      Aaron Wells authored
      Bug 1331863: Now that we've add a default validate_config_options()
      implementation to the base Plugin class, we get a warning when saving
      the config for auth plugins that say yes to has_instance_config() but have
      not implemented the (optional) function validate_instance_config_options.
      This is because of backwards-compatibility code to deal with older
      auth plugins that were using get_config_options(), validate_config_options(),
      and save_config_options(), to handle instance config. We made this change
      in Mahara 1.5 and added a warning message then, that says to update the
      plugin. I think that's a long enough warning period to just go ahead and
      drop support for it.
      From now on, plugins that have instance configs, will have to implement
      get_instance_config_options(), validate_instance_config_options(), and
      save_instance_config_options(). (All the core auth plugins already do.)
      Change-Id: Ia135a96a6d8c36d36708a9b9a66eaef71bc788e9
  16. 16 Jun, 2014 1 commit
  17. 12 Jun, 2014 2 commits
    • Aaron Wells's avatar
      Adjust auth_get_auth_instances_for_wwwroot() to handle the new institution.id column · b1ee27e0
      Aaron Wells authored
      Bug 1323911: Now that the auth_instance table and the institution table both have a
      column called "id", the SQL query is ambiguous about which one it will return.
      Cutting the query down so that it only returns the fields actually used in the code
      resolves this ambiguity.
      Change-Id: I5242aa7bdee38af9aa0a7da308bb0d30dc700621
      Signed-off-by: default avatarYuliya Bozhko <yuliya.bozhko@totaralms.com>
    • Aaron Wells's avatar
      Refactor the Dwoo_Template_Mahara files · 97e96de0
      Aaron Wells authored
      Bug 1231755
      - Cleanup, documentation, and removing replicated code.
      - Not checking for whether the file exists. We'll just make a list
      of search paths and pass those through to Dwoo_Template_File, and
      let it determine which path has the file.
      - Eliminating the separate Dwoo_Template_Mahara classes for plugintypes,
      and moving the custom logic for how plugintypes find their template files,
      into the Plugin class itself.
      Change-Id: I877a4221323333e8e8b6c6df54062a0f8bf2b817
  18. 04 Jun, 2014 1 commit
  19. 27 May, 2014 1 commit
  20. 14 Apr, 2014 1 commit
  21. 07 Apr, 2014 1 commit
  22. 25 Mar, 2014 1 commit
  23. 18 Mar, 2014 1 commit
  24. 12 Mar, 2014 1 commit
  25. 07 Mar, 2014 1 commit
  26. 09 Feb, 2014 1 commit
  27. 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
      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>
  28. 21 Jan, 2014 1 commit
  29. 19 Dec, 2013 1 commit
  30. 15 Dec, 2013 1 commit
  31. 21 Nov, 2013 1 commit
  32. 17 Oct, 2013 1 commit
    • Robert Lyon's avatar
      Allowing pieform error text to not be escaped if needed (Bug 1239539) · bf3d14a3
      Robert Lyon authored
      Currently if there is html in an error message used by pieforms it
      escapes the html so the link becomes not usable.
      I have made a change where you can tell pieforms not to escape the
      error message.
      So instead of using:
      $form->set_error($field, $message);
      you can use:
      $form->set_error($field, $message, false);
      Where false means do not escape the message.
      As the terms and conditions are displayed on the page already I've
      updated the link to jump to the terms section
      Change-Id: Ia8650a9f2284fb007cbe81a4a94223f127c4f6cd
      Signed-off-by: Robert Lyon's avatarRobert Lyon <robertl@catalyst.net.nz>
  33. 14 Oct, 2013 1 commit
  34. 24 Sep, 2013 1 commit
  35. 02 Sep, 2013 1 commit
    • Aaron Wells's avatar
      Changing PluginAuth API to specifically indicate whether Auth requires remote username · 20512fdb
      Aaron Wells authored
      Bug 1160093: This adds a few new methods to the Auth class, which represents an auth instance:
       - is_parent_authority(): Indicates whether this auth instance is a parent authority or not
       - get_parent_authority(): Gets the ID of this auth instance's parent authority
       - needs_remote_username(): Indicates whether this auth instance needs the user to have a
            remote username setting (in auth_remote_user table)
      I've also updated the SAML and XMLRPC auth types, which are the only ones that use remote username.
      And I've updated create_user() to automatically populate auth_remote_user() for auth
      instances that use it.
      Note that an auth instance of ANY type will need a remote username if it's the parent to another
      authority (the parent feature allows a user to log in via the parent or the child auth instance;
      so it's quite possible for the user to have different usernames in the two of them. Currently
      only XMLRPC uses the parent auth feature.)
      Lastly, also updated the documentation of LiveUser->create_user() to indicate that it only
      uses the $remoteauth parameter as a boolean (which was true even before my code changes).
      Change-Id: I39b1b74e68cdbc9c2632b886655caaaece1bd312
  36. 15 Aug, 2013 1 commit
  37. 23 Jun, 2013 1 commit
  38. 17 Jan, 2013 1 commit