Site admins can't see group activities without joining.

[Ruslan Kabalin]

I might be too lazy to do a deep search, but quick search have not indicated any related discussion or bug. Basically the problem is that site (and institution) admins can't see group activities without joining them using ordinary route or making themselves group admin using own privileges. Not sure if this is right and do not see why site admin should not be able to access any group forum or pages directly without joining the group.

[Aaron Wells (u-aaronw)]

I suspect groups were designed this way on purpose, for privacy purposes. It's an extension of how a site admin can't view a user's individual un-shared portfolio content without doing "login as". So, since it'd be a change to Mahara's privacy policy more or less, we should probably ask for community feedback on the mahara.org forums before making a change. (Or make the change configurable & inactive by default for upgraded sites.)

Personally, I'd be in favor of letting admins view group content, because I occasionally encounter this issue as an admin as well, and the current functionality is just a speedbump to me viewing the contents. Or perhaps, rather than completely open access, we could add an equivalent to "Login as" that lets you act as if you are in the group. (This could even have the option to send the group admins a notification, the same as the notification we have for user "Login as".)

It's worth noting, in addition to joining the group, another workaround to view group content is that you can "login as" an existing member of the group.

[Kristina Hoeppner (kris-hoeppner)]

I'd not give a blanket login possibility to admins to view content of groups that they are not a member off. That would be violating privacy quite a bit because it essentially would circumvent the "masquerading". Groups can be used for highly personal discussions. Thus, at most I think we should implement functionality similarly to providing a reason for masquerading that would then be sent to the group admins so they know that an admin had been in their group.

[Kristina Hoeppner (kris-hoeppner)]

Excluding the viewing of objectionable content. See bug #1024872

[Ruslan Kabalin (rkabalin)]

OK, will copy commit message here for the record, as it basically explain everything about the feature:

The feature allows to report objectionable content in the forum posts and topics. When post is reported, the notification is sent to site admins, group admins and forum moderators. Any of above can take action and either mark the post as not objectionable or delete it. In both cases the notification about action will be sent to users who were originally notified about objectionable content, so that they will be aware on other person action and outcomes. Site admin normally can't access the content of the forum he/she is not a member of, however in the case of objectionable content, site admin will be able to have temporary rights similar to group admins, making possible to delete or edit any post in the given forum. Once the issues is resolved (forum no longer contains objectionable content), admin will not longer be able to access forum in the group he/she is not a member.

Ready for revision:
https://reviews.mahara.org/3022
https://reviews.mahara.org/3023

[Ruslan Kabalin (rkabalin)]

Good question which I asked myself why I have not introduced the new system group role, such as "inspector", that would not be possible to assign people via membership page, but will be assigned to admins if there is an objection content. I started working that way initially, but then realised that though roles are in the table, there are many-many occurrences in the code when they are literally compared to its string values rather than some capabilities that are supposed to be defined in the grouptype_roles table, so between adding more mess or less, I have chosen adding less )) and added all forum access validation for site admins to user_can_access_forum. Ideally the "system" grouptype is needed with system roles that will be inherited by other grouptypes (standard and course), and all permissions validation needs to be done against capabilities defined at grouptype level. But that is different story that require a separate issue and substantial amount of work.

[Ruslan Kabalin (rkabalin)]

Above two comments supposed to belong to bug #1024872 Sorry.