"Recent journal entries" displays group journal in private portfolio area

[Kristina Hoeppner]

Mahara 15.10+

When you have a journal entry in a group and you select the "Recent journal entries" block on a personal portfolio page (not a group portfolio page), you see the group journal listed.

This is not the case for the blocks "Journal" and "Journal entry". The group journal should only be visible for a group page.

[Aaron Wells (u-aaronw)]

This is due to a bug in how group & institution blogs were inserted into the Journal blocktypes. The blog blocktypes use the "artefactchooser" Pieform element, which applies this logic to decide which artefacts the user can select, based on whether the page is owned by a group, institution, or user:

group: Show site artefacts, and all artefacts in this group which the user has "view" permission on

institution: Show site artefacts, and artefacts owned by this institution

user: Show public site artefacts, other site artefacts (if the user is an admin), artefacts of the user's institutions, group artefacts for the user's groups if the user has "republish" permission on them, and finally the user's own artefacts.

When the blog blocktypes were implemented, apparently it was a design decision that the access for these artefacts should be different, and limited only to institution blogs for an institution page, group blogs for a group page, and user blogs for a user page. This was implemented by adding a list of artefact IDs as a filter to the artefactchooser. The bug here, is that the code to add that list of artefact IDs, was added to the "journal" block and the "journal entry" block, but not the "recent journal entries" block.

Currently that filter code is copied & pasted into both journal & journal entry separately. The quick fix for 15.10 would be to copy and paste the code into the "recent journal entries" block as well.

A better fix, which we should probably do for 16.04, is to refactor that code so that it's shared between all there blog blocktypes, so that if we make future access changes, we won't have problems. Additionally, the way it's currently written it writes a SQL query that contains the ID of *every* artefact owne by the user (or group or institution), which could be quite large and cause memory problems. We should probably move this change in logic down into the artefactchooser somewhere.

[Aaron Wells (u-aaronw)]

It may make sense to just strip down get_artefactchooser_artefacts to be much, much simpler than it currently is. That method has a lot of outdated access control code in it. It looks like it was probably the method at one time used for selecting file artefacts, but they were long ago changed to use the Pieform "filebrowser" element instead, which has a different underlying method for retrieving the eligible artefacts.

Once the file artefacts were refactored away from "filechooser", the remaining blocktypes using it were blog, profile, and resume, none of which were available as group or institution artefacts until we added group & institution blogs in Mahara 15.10. Consequently the group & institution blogs inherited this dusty outdated access control that was originally meant for files.

That being the case, I think the best thing to do is to strip out all the convoluted access stuff in get_artefactchooser_artefacts(), and make it so that it basically matches the access model for blogs. We may even get a performance boost out of that. The other place it gets called is in BlockInstance->rebuild_artefact_list(), which gets called every time a block is updated, to get the list of artefacts "allowed" in that block. If we change it so that *only* the file artefact uses the convoluted version of the query with checks for group file permissions etc, then it may improve the save time for all the other block types.

[Mahara Bot (dev-mahara)]

Patch for "master" branch: https://reviews.mahara.org/7468