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

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

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

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

As reported by Georgi Yadkov -
http://mahara.org/interaction/forum/topic.php?id=1250#post6144

Signed-off-by: Nigel McNie <nigel@catalyst.net.nz>

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

Remove use of tablerenderer for view/artefact feedback; create feedback list using templates; use artefactchooser paginator
Signed-off-by: Richard Mansfield <richardm@catalyst.net.nz>

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

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

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

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

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

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

(cherry picked from commit 7c6c97b1e8bc9672e13c2da32eab91afd0d9c91d)

Conflicts:

	htdocs/theme/raw/templates/group/membersearchresults.tpl
	htdocs/theme/raw/templates/group/view.tpl

If you are adding a casenote and  isn't set, get artefacttype from the class.

Moodle outcomes integration: view submission/release to/from mnet hosts; hidden view access keys; export of additional artefacts with views

This patch changes the behaviour to be thus:

- If the artefact now has no parent, we can safely remove all records in the APC
- If it does have a parent, insert a non-dirty record representing that relationship
- Mark all other rows referencing the artefact as dirty - we can't make any more conclusions at this point.

The cronjob will come through and clean up the dirty rows, as it always has done.
(cherry picked from commit bdca8220ebddf155bffa26c34f48c5795a774e0b)

How were we not doing this before?!
(cherry picked from commit 3e2222b01157bbfbbae7fd92ebc7c13f44b0a233)

This is the #1 cause of Fatal Errors in Mahara - when a second exception (usually an SQLException) is thrown while we're in the middle of handling one already.

Now the first exception gets to follow through to its conclusion, which results in far better error messages.

The loop happened when the user copying the view didn't have a
'viewfiles' folder, and they were copying a view that did have one.

There's some dodgy looking up of directories by name, that lead the code
to believe that the viewfiles folder it was copying was supposed to be
the parent for all files copied from the View, including the viewfiles
folder itself. Thus, the viewfiles folder and another temporary folder
were marked as parents of each other, and an infinite loop occured.

This dodgy fix gives the relevant bits of code a list of artefacts to
ignore when trying to find a viewfiles folder, but the real fix is to
fix bug #3106.

Allow blog, blogpost and textbox blocktypes having links or manually created <img> tags to artefacts to have those artefacts counted as being within the blocktype, and thus within the view.

This is so if people manually link to or source artefacts within textual content, those artefacts will be downloadable when the view is shown to others.

Not backporting to 1.0 although the problem will most certainly exist there - the patch is just too big to trust on a stable release.

Side effect of the performance work done previously.