GitLab

behatnotneeded: Testing requires multiple simultaneous users

Change-Id: Icfac83b0ac9ed6ab0c304658550dd0260bd5d7eb
(cherry picked from commit 0eea42ce)

Change-Id: I827851a16eba74d474234c21dd6b6afc2d06470c
Signed-off-by: Yuliya Bozhko <yuliya.bozhko@totaralms.com>

As vetted in the May 2014 dev meeting
http://meetbot.mahara.org/mahara-dev/2014/mahara-dev.2014-05-01-08.01.log.html

Change-Id: I353ed74d69a5346fbe4e8e521e5c349dbe8dcbac

Change-Id: I44bb7b53dda86fd25b799c90645c6bfadf05ce2b
Signed-off-by: Nathan Lewis <nathan.lewis@totaralms.com>

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: Yuliya Bozhko <yuliya.bozhko@totaralms.com>

- 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: Nathan Lewis <nathan.lewis@totaralms.com>

Bug#1187212

Change-Id: If268ee5144eed83f8ec6ce3610b7488bb1dc9edd
Signed-off-by: Aaron Wells <aaronw@catalyst.net.nz>

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

- have updated copyright for the pages that had existing copyright
notices (except for the lib/pieforms/ section as i'm not too sure if
that needs changing as it is a different Catalyst IT product)

Change-Id: I11c65ad26cb9cd856cf16b1dccbd4223ba086645
Signed-off-by: Robert Lyon <robertl@catalyst.net.nz>
Signed-off-by: Aaron Wells <aaronw@catalyst.net.nz>

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

Functions created by create_function() don't ever get deallocated,
which contributes to scripts running out of memory.

Change-Id: Ifd78bf05bab67a9b1593a7d9722dd2433e7ad7ca
Signed-off-by: Aaron Wells <aaronw@catalyst.net.nz>

Spelling corrected only for strings that appear
in Mahara code. Third-party code has not been
touched.

Change-Id: Ic3556fb19aa14a231f30a91d810134ed0e4e2889
Signed-off-by: Kristina D.C. Hoeppner <kristina@catalyst.net.nz>

The upgrade to convert textboxes to artefacts tries to insert 5000
rows at a time into the artefact table.  This is too much data for
MySQL's default max_allowed_packet setting.  Reducing the number of
rows inserted per query to 100 (or a bit larger, depending on
max_allowed_packet) fixes the upgrade problem.

See https://mahara.org/interaction/forum/topic.php?id=4474#post20477



Change-Id: I8335323e247abb570a434cd105d4590cad103018
Signed-off-by: Richard Mansfield <richard.mansfield@catalyst.net.nz>

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: Richard Mansfield <richard.mansfield@catalyst.net.nz>

If the MySQL user doesn't have trigger permission, an SQLException was
thrown along with an unhelpful generic error message.  This privilege
is now checked before beginning the install/upgrade, and the message
is now informative.

Change-Id: If35750610cdc84e97bf8f2974d496dea43b8b991
Signed-off-by: Richard Mansfield <richard.mansfield@catalyst.net.nz>

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: Richard Mansfield <richard.mansfield@catalyst.net.nz>

Change-Id: Id4f87c1fef835a11bc7413df93d60a6fada59a6a
Signed-off-by: Richard Mansfield <richard.mansfield@catalyst.net.nz>

Change-Id: Ib9a72a9e36bb24da5907720242b23e991bb7bf9a
Signed-off-by: Richard Mansfield <richard.mansfield@catalyst.net.nz>

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: Richard Mansfield <richard.mansfield@catalyst.net.nz>

Bug #837013

Change-Id: I54e1964487c885bbde709bef51e4e377b1ae8904
Signed-off-by: Hugh Davenport <hugh@catalyst.net.nz>

Change-Id: Ie90dce891d3ca33aef721574a36dfca01a17f30f
Signed-off-by: Eugene Venter <eugene@catalyst.net.nz>

The get_record_select() query (checking record existence) in
ensure_record_exists() method was not using prepared statements and was
quoting all comparison values (regardless of their data type).

Change-Id: Ie862ad4062584efa8c956096a8b1cf08e3fc6c0b
Signed-off-by: Eugene Venter <eugene@catalyst.net.nz>

These closing tags are unnecessary and against our coding
guidelines. Let's get rid of them all in one go.

Change-Id: Ia94f103e525185597ee3780a3839d7577cdd0c29
Signed-off-by: Francois Marier <francois@catalyst.net.nz>

Bug #716533
Signed-off-by: Matt Oquist <moquist@majen.net>
Signed-off-by: Francois Marier <francois@catalyst.net.nz>

Signed-off-by: Richard Mansfield <richard.mansfield@catalyst.net.nz>

Signed-off-by: Richard Mansfield <richardm@catalyst.net.nz>

Signed-off-by: Richard Mansfield <richardm@catalyst.net.nz>

Several functions seemed to be missing the @param for $values and others
seemed had differing descriptions.
I've tried to keep all of these as similar as possible to avoid confusion.

[Nigel: removed part of one hunk - we don't name return variables in
phpdoc]
Signed-off-by: Andrew Robert Nicols <andrew.nicols@luns.net.uk>
Signed-off-by: Nigel McNie <nigel@catalyst.net.nz>

(cherry picked from commit 23670d2e5d77f930bfc79ecd5624ccf6e6b126e7)

This reverts commit 638c1a05.

This is the setting that rejects invalid data. Too risky to turn on for 1.0_STABLE.

Now no longer counts SET NAMES 'utf8' as a write. This means most pages
show as doing no writes, which is correct. 0 writes showed up as blank
in the footer, so tweaked the code appropriately.

This reverts commit 5780e905.

I'm going to fix installs now!

It's now only included on lib/upgrade.php.

One existing call to table_exists that was in safe_require has now been ditched as it's unnecessary.

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

This will be broken until I write a database patch. But the appropriate data is inserted into the group tables when a group is created now.