1. 15 Jun, 2015 3 commits
  2. 28 Apr, 2015 1 commit
  3. 26 Mar, 2015 1 commit
  4. 17 Mar, 2015 1 commit
  5. 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
      content.
      
      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
      import.
      
      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>
      55a8deb8
  6. 26 Feb, 2015 1 commit
  7. 05 Feb, 2015 1 commit
  8. 23 Sep, 2014 1 commit
  9. 22 Sep, 2014 1 commit
  10. 18 Sep, 2014 1 commit
    • Robert Lyon's avatar
      The archiving of submitted pages/collections from groups (Bug #1335670) · 5c57b565
      Robert Lyon authored
      
      
      This patch contains:
      - The export queue system where pages/collections on release from
      submission are added to the export queue table ready to be archived.
      - The export queue admin page showing what is in the queue to be
      exported. The cron runs every 6 minutes. Queue items failed to export
      are also shown here.
      - The archive list admin page, where one can download the generated
      leap2a files for the archived submissions.
      
      In this patch you should be able to add things to the export queue by
      either releasing a sumbission on a group that has 'archive
      submissions' option ticked. This will add the archive to that archived
      submission page, or you can also run a leap2a export from portfolio
      export which will add the export queue and send you an email once the
      export is done.
      
      Things to note:
      - The is a server busy function that stops the export queue from
      running but I'm not too sure if the threshold is too low/high
      - The export queue tries to export the first 100 items each run but if
      resources are fine in handling that easily then the number could be
      higher but I'm not sure of what will be a good number.
      - Currently there is alsoe infrastructure like table columns for dealing
      with releasing submissions from external systems (eg moodle) but that
      functuionality is yet to be built.
      - The checking of server busy in MS windows untested - may need to
      just let MS ignore server busy check as there doesn't seem to be
      standard way to check this.
      
      Change-Id: If4c1d272e9c5d46fbf16b2ff73ceb2687c06ffd4
      Signed-off-by: Robert Lyon's avatarRobert Lyon <robertl@catalyst.net.nz>
      5c57b565
  11. 15 Sep, 2014 1 commit
    • Aaron Wells's avatar
      Fixing cli install / upgrade regression (Bug #1367998) · 5d1ea9b3
      Aaron Wells authored and Robert Lyon's avatar Robert Lyon committed
      When you request that check_upgrades() checks for upgrades in all
      components, the return data now includes a false component called
      "settings". I've moved "disablelogin", "newinstallcount" and "toupgradecount" into that settings component.
      
      Change-Id: I57e26e0e05848da607b8a44089c92547ebda078b
      5d1ea9b3
  12. 12 Sep, 2014 1 commit
  13. 24 Aug, 2014 1 commit
  14. 05 Jun, 2014 1 commit
  15. 27 May, 2014 3 commits
  16. 23 May, 2014 1 commit
  17. 06 Apr, 2014 2 commits
  18. 30 Mar, 2014 1 commit
    • Aaron Wells's avatar
      Renaming general pages to static pages · d4c63e88
      Aaron Wells authored and Robert Lyon's avatar Robert Lyon committed
      Bug1282219: See the lengthy discussion on the bug tracker. No perfect name
      for these items has arisen yet, but I think "static pages" is the best
      so far because:
      
      1. It means they're obviously not the same type of thing as the Pages in your
      portfolio, because those are dynamic.
      
      2. It's more self-evident. If I were brand new to Mahara and were
      trying to figure out how to change the "Privacy Policy" page, "Static pages"
      is probably what I would think to click on.
      
      Change-Id: I7dd4e3fe6e86fd35dce973afb78b3e56049aab69
      d4c63e88
  19. 27 Mar, 2014 1 commit
  20. 26 Mar, 2014 1 commit
  21. 24 Mar, 2014 1 commit
  22. 17 Mar, 2014 1 commit
  23. 09 Mar, 2014 3 commits
  24. 03 Mar, 2014 1 commit
  25. 26 Feb, 2014 1 commit
  26. 23 Feb, 2014 2 commits
  27. 21 Feb, 2014 1 commit
  28. 18 Feb, 2014 1 commit
  29. 17 Feb, 2014 1 commit
    • Jono Mingard's avatar
      Made Attachments expander keyboard-accessible (Bug #1279530) · 9d52504d
      Jono Mingard authored
      
      
      - Changed trigger to an anchor instead of a <td>, moved js file out of resume (since
      resume isn't the only thing using it) and added focus management - the first link in
      the expander is focused when it's opened
      - Modified the expander in Cookie Consent 2 to use the same logic
      - Fixed Resume blocktypes, which were no longer displaying properly after the change
      
      Change-Id: I399ea9558482c1af91bd904f4057851cdb0b3ee7
      Signed-off-by: default avatarJono Mingard <jonom@catalyst.net.nz>
      9d52504d
  30. 02 Feb, 2014 1 commit
  31. 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
  32. 14 Jan, 2014 1 commit