Mobile App Restrictions Result in Corrupt Files

Mobile App Restrictions Result in Corrupt Files

by Cory Robbins -
Number of replies: 2

Hello,

If I use this plugin: https://moodle.org/plugins/availability_mobileapp

I am able to restrict an activity or resource by mobile app usage.  The issue is, on a student account, while visibility behaves as expected, I can't download any files.  If I attach a PDF or image to an Assignment activity as additional resources, the resulting file size shows as 34KB, and it doesn't open.  Trying to use an app like Adobe acrobat for iPad returns a message stating the file is corrupt.  The same result happens if I use a drag-and-drop pdf/image upload, or a folder resource with PDFs or images in them.  I setup a group based restriction, and that does allow the mobile user to open a PDF...  Is there any advice here?


Edit:  I'm using the latest Mobile Apps 3.9.2, have tried multiple devices, and Moodle 3.8.3.


Edit 2:  It works if I use a teacher account, which has the ability to bypass restrictions, and it works with the same student account if I grant permission to bypass restrictions, so I think this means it isn't the file or the upload.

Average of ratings: -
In reply to Cory Robbins

Re: Mobile App Restrictions Result in Corrupt Files

by Dani Palou -
Picture of Core developers Picture of Moodle HQ Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers
Hi Cory,

I was able to reproduce it too. I've notified Juan (the plugin owner), we'll try to fix it when we have some time.

Cheers,
Dani
In reply to Cory Robbins

Re: Mobile App Restrictions Result in Corrupt Files

by Juan Leyva -
Picture of Core developers Picture of Moodle HQ Picture of Particularly helpful Moodlers Picture of Plugin developers Picture of Testers
Hi Cory,

I think Dani has found the line of code causing the issue, this line in availability/condition/mobile/classes/condition.php

if (strpos($ME, "webservice/") !== false) {

should be replaced with

if (strpos($ME, "webservice/") !== false || strpos($ME, "tokenpluginfile.php") !== false) {

That should fix the issue, I will try to provide a new version of the plugin during next week, in the meantime, you can manually apply the patch

Regards, Juan