16 May 2016, 11:25

Hello Karen,

I'm afraid I still can't replicate your problem. Are there any error messages in the error log on the server (not the generic message about access denied that you see on the screen) that might give more information?

Cheers

Kristina

18 May 2016, 22:29

Hello Kristina, 

We don't seem to have direct access to Mahara's error logs as our Mahara installation is hosted by an external company. But they sent us a *.qz file which we don't know how to open and I don't seem to be able to attach to this forum post. So I'm stuck...

Any ideas?

Thanks,

Karen

19 May 2016, 14:38

Hi Karen,

I took a look at the *.gz file you emailed to Kristina, and the enclosed log file was actually empty. Which I means your Mahara site is not printing any errors (or there was a mistake when they sent you the logs).

Like Ghada, I tested out the group submission behavior in Mahara 15.04, and the archived submission feature, and couldn't replicate the problem. I also took a look at the underlying program code to see if I could spot any bugs there, and I don't see any direct way that the archived submission setting could cause this problem.

However, I do see a possibility for a discrepancy between the "group views" block and the page view permissions, because they look at different database tables. The group views block bases its results on:

1. Does your role in the group have the "see_submitted_views" flag set in the "grouptype_roles" table?

2. And, does the page have this group's id in the "submittedgroup" column in the "view" table?

But when you go to view the page, your access is actually based on:

1. Is there a record in the "view_access" table for that view, group, and your role in the group?

Now, normally this doesn't cause any problems, because when you submit a view we set the "view.submittedgroup" value and create the "view_access" records at the same time. But if I go into the database and manually delete the "view_access" record for the tutor role for a page, then I get the same behavior you're describing: as a tutor I see the page in the "Submissions to this group" section of the "Group pages" block; but when I try to view the page I get "Access Denied".

So it's possible you've got something in your code preventing that tutor record from being created, or clearing it away. But at the same time it would have to be allowing the "admin" role's record to be created, which is very strange, and I can't see any obvious way for that to happen in the code.

You can verify if this is the cause of the underlying condition by querying the "view_access" table. Get the ID of a view from its URL (you'll see the "?id=___" on the end), and then run this query: SELECT * FROM view_access WHERE view=10 (except with your view's ID instead of 10). If the group is set to the "course" roles, and the page is submitted to that group, you should see something like this:

mahara=# select * from view_access where view=9;
 view | accesstype | group | role  | usr | institution 
------+------------+-------+-------+-----+-------------
    9 |            |    13 | tutor |     |             
    9 |            |    13 | admin |     |             
(2 rows)

... except with the view's ID and the group's ID there. If the user has shared the page with others, you may see additional rows as well, but the important part is those "group" and "role" columns. Unfortunately, though, even knowing that, without any visible error messages it would be rather difficult to track down *why* this is happening.

Cheers,

Aaron