Set these PHP settings in your php.in as follows: upload_max_filesize=2M, post_max_size=8M

For this test you'll need a teacher and your admin user.

Check your site's maximum uploaded file size. This is a site setting called "maxbytes". Set maxbytes to 2MB.

Also set the course setting "Maximum upload size" to 2MB.

You'll need a course backup. Check the file size and make sure that it is bigger than 10MB.

As admin go to course admin > users > permissions > check permissions and check "moodle/course:ignorefilesizelimits" for a teacher. The teacher should NOT have moodle/course:ignorefilesizelimits.

File system repository set up
1. create a directory at moodledata/repository/examplerepository then set up a file system repository using that directory by going to: Site administration > Plugins > Repositories > Manage repositories > File System > Settings > Create a Repository Instance
2. Outside of Moodle copy your course backup into the repository directory.

As a teacher go into a course and do a restore into a new course. Select the course backup from the file repo.
You should get an error about the file being too big.

As admin give teacher moodle/course:ignorefilesizelimits in the course.
Teacher should now be able to select the backup file and proceed with the restore.

Additional testing.

As any user but admin go to My private files.
You should see something like "Maximum size for newfiles: 2MB - drag and drop available" near the top right of the file manager.

As admin you should see something like "Maximum size for new files: -1 bytes - drag and drop available"
As admin drag the course backup into your private files. You should get an error message about PHP.
As admin click "Add..." and add add the course backup from your file repository. It should succeed.

Set these PHP settings in your php.in as follows: upload_max_filesize=2M, post_max_size=8M
For this test you'll need a teacher and your admin user.
Check your site's maximum uploaded file size. This is a site setting called "maxbytes". Set maxbytes to 2MB.
Also set the course setting "Maximum upload size" to 2MB.
You'll need a course backup. Check the file size and make sure that it is bigger than 10MB.
As admin go to course admin > users > permissions > check permissions and check "moodle/course:ignorefilesizelimits" for a teacher. The teacher should NOT have moodle/course:ignorefilesizelimits.
File system repository set up
1. create a directory at moodledata/repository/examplerepository then set up a file system repository using that directory by going to: Site administration > Plugins > Repositories > Manage repositories > File System > Settings > Create a Repository Instance
2. Outside of Moodle copy your course backup into the repository directory.
As a teacher go into a course and do a restore into a new course. Select the course backup from the file repo.
You should get an error about the file being too big.
As admin give teacher moodle/course:ignorefilesizelimits in the course.
Teacher should now be able to select the backup file and proceed with the restore.
Additional testing.
As any user but admin go to My private files.
You should see something like "Maximum size for newfiles: 2MB - drag and drop available" near the top right of the file manager.
As admin you should see something like "Maximum size for new files: -1 bytes - drag and drop available"
As admin drag the course backup into your private files. You should get an error message about PHP.
As admin click "Add..." and add add the course backup from your file repository. It should succeed.

Description

Files in the file system repository should not be limited by the PHP max file size.

Steps:

1. Setup file system repository in the moodledata/repository/examplerepository and enable the folder in: Site administration > Plugins > Repositories > Manage repositories > File System > Settings > Create a Repository Instance
2. Copy a file to the repository using the file system that is larger than the PHP upload_max_file_size setting
3. Create a new Page in a Course
4. Attempt to link to the file from the Page using the File Picker

Expected result:

Link to the file from the file system repository is created in the page

If the user interface repository file pickers do not assume that all file transfers need to go through the PHP upload routine, then the file system repository links should succeed regardless of upload_max_filesize.

Backup files bigger than the PHP upload_max_file_size are actually processed. So not only the .mbz file is read and uncompressed, but the contained files are also processed, many of which exceed the PHP file size limitation.

Guillermo M.
added a comment - 07/Oct/11 12:33 AM Backup files bigger than the PHP upload_max_file_size are actually processed. So not only the .mbz file is read and uncompressed, but the contained files are also processed, many of which exceed the PHP file size limitation.

I have experienced the same issue while tried to add a PPT file (96 MB) that was in the file repository on the server into the course and received the error "This file is bigger than the maximum size".

George Chen
added a comment - 14/Dec/11 7:03 AM I have experienced the same issue while tried to add a PPT file (96 MB) that was in the file repository on the server into the course and received the error "This file is bigger than the maximum size".

I second the comment made by George. This issue is currently affecting multiple clients of ours and would love to see a resolution to this issue. The new file picker system could be a even greater asset to Moodle users should some of these quirks be worked out.

Joseph Jacelone
added a comment - 14/Dec/11 10:21 PM I second the comment made by George. This issue is currently affecting multiple clients of ours and would love to see a resolution to this issue. The new file picker system could be a even greater asset to Moodle users should some of these quirks be worked out.

Andrew Davis
added a comment - 19/Dec/11 12:26 PM Just recording some notes on how this area of Moodle works
I've raised MDL-30792 which I stumbled on while exploring this area of Moodle. Its a security issue so you may not be able to see it.
Assuming ajax is enabled repository/filepicker.js sends an ajax request to /repository/repository_ajax.php Within repository_ajax.php the lines actually generating the error are...
// check if exceed maxbytes
if (($maxbytes!==-1) && (filesize($file['path']) > $maxbytes)) {
throw new file_exception('maxbytes');
}
so if repository_ajax.php asked the repository it could potentially set the value of $maxbytes to -1.
This could be done in one of a few ways.
We can use repository::static_function to call a function on the repo to ask for whether Moodle file size limits should be applied. Something like
$applysizelimits = repository::static_function($this->plugin, 'get_apply_file_size_limits');
Or we could use $repo->get_option(). get_option() retrieves repository options from the repository_instance_config table. The file repo could put an option in there when its created.
I'm not terribly familiar with this area of Moodle so I will record more as I learn more.

Martin Dougiamas
added a comment - 19/Dec/11 1:41 PM Without looking at code I don't know which method is best, but it's definitely a good idea to ask the repository.
I would actually DEFAULT to having this limit disabled for all plugins, as I think only the "upload" repository actually should have this limit.

Peter Ansell
added a comment - 19/Dec/11 6:11 PM Do you need to configure the new option for the file system repository plugin in or around repository/filesystem/lib.php?
Also, do you need to add the new code to repository/filepicker.php around line 96 to avoid the maxbytes check there?

Dan Poltawski
added a comment - 19/Dec/11 7:22 PM In fact, it looks like we already do check the filesize on upload in the upload repository, so I wonder if this functionally can be taken out of the repository ajax script wholesale.

Dan Poltawski
added a comment - 19/Dec/11 7:27 PM - edited Hmm thinking about it more can disable filesize checking for all plugins?
Use case where I think site admins might want to be able to restrict filesize: A forum thread where students can upload 1GB zip of mp3 files frm their dropbox account..

Peter, no. The new option I have proposed is actually in the upload repository. My change says "dont do size checks unless I specifically say so" and only the upload repository says so.

And if Im looking at the piece of code you mean when you say line 96 (could have been reshuffled since your comment) that is just calculating the max file size. I can probably do something to avoid doing that if its not necessary but it does no real harm.

Dan, this check in repository_ajax.php (around line 62) is interesting.

// if uploaded file is larger than post_max_size (php.ini) setting, $_POST content will lost

if (empty($_POST) && !empty($action)) {

$err->error = get_string('errorpostmaxsize', 'repository');

die(json_encode($err));

}

I commented out the other ajaxy size check and then uploaded a large video and the above code executed and threw the error. I need to do some more experimenting but if the ajax size check occurs before the upload actually begins and the code above only executes once the upload is under way then we should probably retain the ajax size checks (where relevant). Im just worried about the case where someone is uploading a large video over a slow net connection. It would be better to tell them up front "this file is too big" rather than waiting for them to upload a few MB, hit a size limit then be told.

Andrew Davis
added a comment - 02/Feb/12 3:09 PM Peter, no. The new option I have proposed is actually in the upload repository. My change says "dont do size checks unless I specifically say so" and only the upload repository says so.
And if Im looking at the piece of code you mean when you say line 96 (could have been reshuffled since your comment) that is just calculating the max file size. I can probably do something to avoid doing that if its not necessary but it does no real harm.
Dan, this check in repository_ajax.php (around line 62) is interesting.
// if uploaded file is larger than post_max_size (php.ini) setting, $_POST content will lost
if (empty($_POST) && !empty($action)) {
$err->error = get_string('errorpostmaxsize', 'repository');
die(json_encode($err));
}
I commented out the other ajaxy size check and then uploaded a large video and the above code executed and threw the error. I need to do some more experimenting but if the ajax size check occurs before the upload actually begins and the code above only executes once the upload is under way then we should probably retain the ajax size checks (where relevant). Im just worried about the case where someone is uploading a large video over a slow net connection. It would be better to tell them up front "this file is too big" rather than waiting for them to upload a few MB, hit a size limit then be told.

When you upload a file (using the upload repo) filepicker.js calls repository_ajax.php with action == upload.

When you link to a file in a file system repo filepicker.js calls repository_ajax.php with action == download. It is quite possible that the file size check within the 'download' branch of the switch is entirely unnecessary. This code:

// check if exceed maxbytes

if (($maxbytes!==-1) && (filesize($file['path']) > $maxbytes)) {

throw new file_exception('maxbytes');

}

At this time I dont know whether to simply strip out that check or to go with the idea of adding a repository option that makes that check optional.

Andrew Davis
added a comment - 03/Feb/12 4:05 PM Im not sure if I'm learning or just confusing myself.
When you upload a file (using the upload repo) filepicker.js calls repository_ajax.php with action == upload.
When you link to a file in a file system repo filepicker.js calls repository_ajax.php with action == download. It is quite possible that the file size check within the 'download' branch of the switch is entirely unnecessary. This code:
// check if exceed maxbytes
if (($maxbytes!==-1) && (filesize($file['path']) > $maxbytes)) {
throw new file_exception('maxbytes');
}
At this time I dont know whether to simply strip out that check or to go with the idea of adding a repository option that makes that check optional.

I've just been looking at the two options now.
First up I'm seriously no repository expert, I've never really looked to deep into its code. Likely Dongsheng is the best person to ask.
However I have had a good look into things because it is always interesting to learn something new.
I started by looking at option 2 as it seemed the most straight forward.

During my review/research I looked at how the filesystem, youtube and dropbox repo's worked in regards to repository_ajax and the download action.
For both the filesystem and dropbox repos when using the editor and selecting an image to embed the image is copied into the draft files area (in the case of dropbox downloaded) and then when saving copied into the appropriate area. In the case of youtube it is linked as expected and nothing copied.
In thinking about it there is no PHP conf limitation to the size of the file for either the dropbox or filesystem repositories, there is only the limit we impose.
So my initial thoughts are that removing the check is fine.

Next I looked at the first set of changes, which is of course just an option to avoid the check. I'm not entirely sure about this option. I tested the upload option with the editor in the same way as the dropbox and filesystem repo's however the upload doesn't execute the download action (which makes sense when you type it out).
I didn't look more into this path either as too be truthful I'm not partial to it. The option to me doesn't feel necessary at the moment and I feel it is only adding clutter.

So at the moment I prefer the patch that simply removes the check.
HOWEVER I wonder whether there is a need for an option here. The repo's I looked at would not be limited by php conf such as upload_max_size or post_max_size, and for dropbox which uses curl well curl doesn't have a max size php option so theres no conf to limit it there either, however perhaps there are other means of `downloading` files onto the server that would be limited. I wonder whether we should give the repository an option to specify the maximum download size. Perhaps at the moment there is no need however. I do wonder still why that check was there in the first place.

In summary my +1 goes to removing the check pending Dongsheng or someone knowledgeable in all repositories confirming that there are no repositories using mechanisms other than curl or local file transfer to `download` files and that if there are that they won't have a limit imposed through other settings.
Hopefully that all makes sense.

Sam Hemelryk
added a comment - 16/Feb/12 1:22 PM Hi Andrew,
I've just been looking at the two options now.
First up I'm seriously no repository expert, I've never really looked to deep into its code. Likely Dongsheng is the best person to ask.
However I have had a good look into things because it is always interesting to learn something new.
I started by looking at option 2 as it seemed the most straight forward.
During my review/research I looked at how the filesystem, youtube and dropbox repo's worked in regards to repository_ajax and the download action.
For both the filesystem and dropbox repos when using the editor and selecting an image to embed the image is copied into the draft files area (in the case of dropbox downloaded) and then when saving copied into the appropriate area. In the case of youtube it is linked as expected and nothing copied.
In thinking about it there is no PHP conf limitation to the size of the file for either the dropbox or filesystem repositories, there is only the limit we impose.
So my initial thoughts are that removing the check is fine.
Next I looked at the first set of changes, which is of course just an option to avoid the check. I'm not entirely sure about this option. I tested the upload option with the editor in the same way as the dropbox and filesystem repo's however the upload doesn't execute the download action (which makes sense when you type it out).
I didn't look more into this path either as too be truthful I'm not partial to it. The option to me doesn't feel necessary at the moment and I feel it is only adding clutter.
So at the moment I prefer the patch that simply removes the check.
HOWEVER I wonder whether there is a need for an option here. The repo's I looked at would not be limited by php conf such as upload_max_size or post_max_size, and for dropbox which uses curl well curl doesn't have a max size php option so theres no conf to limit it there either, however perhaps there are other means of `downloading` files onto the server that would be limited. I wonder whether we should give the repository an option to specify the maximum download size. Perhaps at the moment there is no need however. I do wonder still why that check was there in the first place.
In summary my +1 goes to removing the check pending Dongsheng or someone knowledgeable in all repositories confirming that there are no repositories using mechanisms other than curl or local file transfer to `download` files and that if there are that they won't have a limit imposed through other settings.
Hopefully that all makes sense.
Cheers
Sam

The main moodle.git repository has just been updated with latest weekly modifications. You may wish to rebase your PULL branches to simplify history and avoid any possible merge conflicts. This would also make integrator's life easier next week.

Eloy Lafuente (stronk7)
added a comment - 17/Feb/12 10:10 AM The main moodle.git repository has just been updated with latest weekly modifications. You may wish to rebase your PULL branches to simplify history and avoid any possible merge conflicts. This would also make integrator's life easier next week.
TIA and ciao

1) There are still 'maxbytes' occurrences in the /repository directory (apart from the upload one).

2) Offtopic: Does drag and drop observe the limits (aka is considered "upload").

3) What happens with activity restrictions? Say forum only allows 200K attachments... with the patch that setting will be ignored completely if I'm not wrong.

4) Reflexion: While I don't like restrictions... if they are there, they must be observed. If somebody puts a 2GB file in the filesystem repo, or if somebody has one 3GB file in dropbox... their size should be checked. 100% sure. No problem at all with links, of course, but any file "loaded" (added) should observe the restriction.

5) And of course, we must not lose activity restrictions at all, no matter of all the rest. They are part of the learning experience and can be good reasons for having that restricted (from a teacher pov).

Eloy Lafuente (stronk7)
added a comment - 21/Feb/12 5:10 PM Uhm,
I don't understand this completely...
1) There are still 'maxbytes' occurrences in the /repository directory (apart from the upload one).
2) Offtopic: Does drag and drop observe the limits (aka is considered "upload").
3) What happens with activity restrictions? Say forum only allows 200K attachments... with the patch that setting will be ignored completely if I'm not wrong.
4) Reflexion: While I don't like restrictions... if they are there, they must be observed. If somebody puts a 2GB file in the filesystem repo, or if somebody has one 3GB file in dropbox... their size should be checked. 100% sure. No problem at all with links, of course, but any file "loaded" (added) should observe the restriction.
5) And of course, we must not lose activity restrictions at all, no matter of all the rest. They are part of the learning experience and can be good reasons for having that restricted (from a teacher pov).
So... I'm going to reopen this. This needs some more thinking IMO...

2) drag and drop appears to implement the activity file size restriction through some other mechanism. This change does not break that mechanism.

3) The change does however give users a way around activity file size restrictions. You can have a much larger file in a file system repo and the user can use it for an upload assignment that has a file size check that it should fail

Andrew Davis
added a comment - 02/Mar/12 12:34 PM Some responses.
2) drag and drop appears to implement the activity file size restriction through some other mechanism. This change does not break that mechanism.
3) The change does however give users a way around activity file size restrictions. You can have a much larger file in a file system repo and the user can use it for an upload assignment that has a file size check that it should fail

Students having their assignments uploaded to the file system prior to submitting them via web? Let's admit its very minor use-case, if ever. On contrary to what MD states above, I see all plugin controlled by upload_max_filesize. Note there is no conceptual difference between, say, Upload repo and URL Downloader repo. I mean, there would be no point to have Upload restricted and leave URL Downloader unrestricted (as there is an obvious way to bypass the restriction). So having the upload_max_filesize check disabled in the File system repository should be implemented, said that it is an exception - as we assume only admins having access to the file system so things are still under their control.

David Mudrák
added a comment - 05/Mar/12 2:04 PM Students having their assignments uploaded to the file system prior to submitting them via web? Let's admit its very minor use-case, if ever. On contrary to what MD states above, I see all plugin controlled by upload_max_filesize. Note there is no conceptual difference between, say, Upload repo and URL Downloader repo. I mean, there would be no point to have Upload restricted and leave URL Downloader unrestricted (as there is an obvious way to bypass the restriction). So having the upload_max_filesize check disabled in the File system repository should be implemented, said that it is an exception - as we assume only admins having access to the file system so things are still under their control.
The "IMHO" disclaimer applies as usually.

Andrew Davis
added a comment - 08/Mar/12 11:51 AM Maybe we're coming back around to an options that came up earlier. From above...
1) Adding an option to the repositories (actually only the upload repository) that demands strict enforcement of file size limits in the "download" branch of repository_ajax.php
https://github.com/andyjdavis/moodle/compare/master...MDL-27156_file_limitation

Andrew Davis
added a comment - 08/Mar/12 11:57 AM Ill be back shortly for a few more hours but will then be away for a week. I've rebased https://github.com/andyjdavis/moodle/compare/master...MDL-27156_file_limitation and updated the diff url just in case its decided that that is a viable decision while I am away.

Andrew Davis
added a comment - 08/Mar/12 3:24 PM As I'm going to be away for a week I'm putting this up for integration just to make sure it gets looked at. If anyone wants to take this issue over, modify my code or whatever, feel free to have a go

the main moodle.git repository has been updated with latest weekly modifications. You may wish to rebase your PULL branches to simplify history and avoid any possible merge conflicts. This would also make integrator's life easier next week.

Eloy Lafuente (stronk7)
added a comment - 10/Mar/12 5:30 AM Some hours ago...
the main moodle.git repository has been updated with latest weekly modifications. You may wish to rebase your PULL branches to simplify history and avoid any possible merge conflicts. This would also make integrator's life easier next week.
TIA and ciao

Eloy Lafuente (stronk7)
added a comment - 15/Mar/12 7:53 AM The integration of this issue has been delayed to next week because the integration period is over (Monday, Tuesday) and testing must happen on Wednesday.
This change to a more rigid timeframe on each integration/testing cycle aims to produce a better and clear separation and organization of tasks for everybody.
This is a bulk-automated message, so if you want to blame somebody/thing/where, don't do it here (use git instead) :-D :-P
Apologizes for the inconvenient, this will be integrated next week. Thanks for your collaboration & ciao

The main moodle.git repository has just been updated with latest weekly modifications. You may wish to rebase your PULL branches to simplify history and avoid any possible merge conflicts. This would also make integrator's life easier next week.

Eloy Lafuente (stronk7)
added a comment - 15/Mar/12 11:21 PM The main moodle.git repository has just been updated with latest weekly modifications. You may wish to rebase your PULL branches to simplify history and avoid any possible merge conflicts. This would also make integrator's life easier next week.
TIA and ciao

I think what we have come around to - the filesystem repository the only one being removed from this restriction by default makes sense - however maybe this should be an option that is visible to administrators so that they can override it.

If we are not making this configurable then I don't think that using this $options array is the right way to do it (as a user configurable option could potentially override it in third party plugin). I think it would be preferable to introduce a function definition observe_filesize_limits() or something like that where this would be statically defined in the API much like supported_returntypes().

Dan Poltawski
added a comment - 20/Mar/12 5:08 PM Hi,
I think what we have come around to - the filesystem repository the only one being removed from this restriction by default makes sense - however maybe this should be an option that is visible to administrators so that they can override it.
If we are not making this configurable then I don't think that using this $options array is the right way to do it (as a user configurable option could potentially override it in third party plugin). I think it would be preferable to introduce a function definition observe_filesize_limits() or something like that where this would be statically defined in the API much like supported_returntypes().
Anyway I am interested on opinions on this.

Martin Dougiamas
added a comment - 20/Mar/12 5:39 PM - edited There are several things getting confused here into one.
Currently we have:
HTTP: The upload limits imposed by PHP/Apache.
SERVER: The upload limit imposed by the admin. Must be < HTTP.
ACTIVITY: The final limits imposed by activities (and courses). Must be < SERVER.
For upload scenario this always made sense and the calculations work.
What I think we need to do is
A. Decouple HTTP from SERVER/ACTIVITY.
HTTP: The upload limits imposed by PHP/Apache.
SERVER: The upload limit imposed by the admin. Can be anything!
ACTIVITY: The final limits imposed by activities (and courses). Must be < SERVER.
B. Change the calculations so that:
get_max_upload_file_size() IGNORES HTTP. ACTIVITY could be bigger than HTTP. All repositories must respect this limit as they do now.
Upload plugin (only) uses maxsize is the minimum of HTTP and ACTIVITY, and prints that info somewhere near the upload form.

The use case for file system repository in my impression, is to allow arbitrary sized files if necessary for administrators. In the calculations above it looks like SERVER is not clearly used in this way.

In the case of the file system repository, the SERVER limit would be set by administrators based on their needs for the largest video or powerpoint that they will ever need to publish. They would then have the impression that they need to set ACTIVITY to limit users. However, they would actually need to set ACTIVITY to be just as large as SERVER to be useful, as "All repositories must respect this limit as they do now" includes the file system repository. Hence they would be limiting their use of the file system repository by limiting users with ACTIVITY, which was the point this bug was trying to fix. To obtain their desired behaviour they would infact need to rely on HTTP to limit users, as that is the only limit that will not limit the file system repository.

I don't understand why the "All repositories must respect this limit as they do now" is so important and why the algorithm must use ACTIVITY instead of SERVER in get_max_upload_file_size(). If get_max_upload_file_size() used SERVER the calculations above would be closer to a naive impression of the three limits in my opinion.

Peter Ansell
added a comment - 21/Mar/12 5:05 AM - edited The use case for file system repository in my impression, is to allow arbitrary sized files if necessary for administrators. In the calculations above it looks like SERVER is not clearly used in this way.
In the case of the file system repository, the SERVER limit would be set by administrators based on their needs for the largest video or powerpoint that they will ever need to publish. They would then have the impression that they need to set ACTIVITY to limit users. However, they would actually need to set ACTIVITY to be just as large as SERVER to be useful, as "All repositories must respect this limit as they do now" includes the file system repository. Hence they would be limiting their use of the file system repository by limiting users with ACTIVITY, which was the point this bug was trying to fix. To obtain their desired behaviour they would infact need to rely on HTTP to limit users, as that is the only limit that will not limit the file system repository.
I don't understand why the "All repositories must respect this limit as they do now" is so important and why the algorithm must use ACTIVITY instead of SERVER in get_max_upload_file_size(). If get_max_upload_file_size() used SERVER the calculations above would be closer to a naive impression of the three limits in my opinion.

Activities can able to set their own limits for educational reasons, and this is really important.

eg If a teacher says they want an assignment submission to be an image under 1 Mb, then that limit must be enforced.

eg If a site like moodle.org sets global limits of 100k attachments to keep the overall storage/size requirements down, and to encourage people to use links instead, then it should apply everywhere

People should not be able to get around these limitations by uploading via Dropbox. Nor should certain repositories have special exclusions from restrictions. Thus all repositories should obey the limits.

I do hear what you are saying, but we need a consistent design that is clear to understand (by developers and users).

There are at least two ways we can solve the particular use case you mention (that the File System repo should not have any size restrictions).

Add a override filesize limit setting for each repository which, if set, trumps all other ACTIVITY settings. The more I think about this the messier it seems, in that file size decisions need to know and check the repository settings, and different repositories will work inconsistently for the same person, etc. And we'll have people disabling Dropbox just because of the way it could be used to bypass restrictions etc etc ... It's confusing.

My preferred way would be to simply add a new capability like "Immune to file size limits". This could be given to certain roles by the admin and would allow those people to bypass any limits. It can easily be checked in get_max_upload_file_size() and elsewhere, and keeps capabilities where it belongs, in the capabilities system. My +10 for this.

Martin Dougiamas
added a comment - 21/Mar/12 12:17 PM - edited Peter,
Activities can able to set their own limits for educational reasons, and this is really important.
eg If a teacher says they want an assignment submission to be an image under 1 Mb, then that limit must be enforced.
eg If a site like moodle.org sets global limits of 100k attachments to keep the overall storage/size requirements down, and to encourage people to use links instead, then it should apply everywhere
People should not be able to get around these limitations by uploading via Dropbox. Nor should certain repositories have special exclusions from restrictions. Thus all repositories should obey the limits.
I do hear what you are saying, but we need a consistent design that is clear to understand (by developers and users).
There are at least two ways we can solve the particular use case you mention (that the File System repo should not have any size restrictions).
Add a override filesize limit setting for each repository which, if set, trumps all other ACTIVITY settings. The more I think about this the messier it seems, in that file size decisions need to know and check the repository settings, and different repositories will work inconsistently for the same person, etc. And we'll have people disabling Dropbox just because of the way it could be used to bypass restrictions etc etc ... It's confusing.
My preferred way would be to simply add a new capability like "Immune to file size limits". This could be given to certain roles by the admin and would allow those people to bypass any limits. It can easily be checked in get_max_upload_file_size() and elsewhere, and keeps capabilities where it belongs, in the capabilities system. My +10 for this.

This doesnt work quite how it should. The global $COURSE hasnt been initiated correctly so $COURSE->id is always 1 (system). This makes it impossible to grant the user the new capability within a single course. I'm not sure how to remedy this just yet. If anyone else knows feel free to jump in. I have emailed Michael and Dongsheng about this as Im a bit stuck at this point.

I was worried that exempting users from file size restrictions across all repository types would behave badly. The upload repository at least still handles it gracefully and still handles you trying to upload a file above PHP's file size limits (which we cannot bypass from within PHP)

Andrew Davis
added a comment - 27/Mar/12 6:47 PM - edited Updating the branch info. https://github.com/andyjdavis/moodle/compare/master...MDL-27156_file_cap
This doesnt work quite how it should. The global $COURSE hasnt been initiated correctly so $COURSE->id is always 1 (system). This makes it impossible to grant the user the new capability within a single course. I'm not sure how to remedy this just yet. If anyone else knows feel free to jump in. I have emailed Michael and Dongsheng about this as Im a bit stuck at this point.
I was worried that exempting users from file size restrictions across all repository types would behave badly. The upload repository at least still handles it gracefully and still handles you trying to upload a file above PHP's file size limits (which we cannot bypass from within PHP)

This is a big issue for us - as file system is how we plan to get around limits for uploading backups and what not (files that we, as admins, vet). The other way is going to have to be to setup a second sever link to the same file store and DB with different limits.

Eric Merrill
added a comment - 04/Apr/12 8:07 AM This is a big issue for us - as file system is how we plan to get around limits for uploading backups and what not (files that we, as admins, vet). The other way is going to have to be to setup a second sever link to the same file store and DB with different limits.
I add my +0.001 to Martin's option #2 (capability to ignore limits).

It appears that the issues Dongsheng mentioned have been integrated and the problem with course ID in the file picker has been resolved. I'll do some testing myself and update the testing instructions.

Andrew Davis
added a comment - 21/Apr/12 1:47 PM It appears that the issues Dongsheng mentioned have been integrated and the problem with course ID in the file picker has been resolved. I'll do some testing myself and update the testing instructions.

Ill need to do some more work on this. I have the check for the new capability in get_max_upload_file_size() but then the user's individual capability alters the site admin pages. Specifically if get_max_upload_file_size() returns -1 because the user is immune to file size restrictions the only options you get for maxbytes are server limit and -1. You're meant to get 8MB, 5MB, 2MB etc.

I could rework how the admin stuff works but I get the feeling that get_max_upload_file_size() should continue to behave the same for all users. Individual user exemptions can be dealt with outside of it.

Andrew Davis
added a comment - 24/Apr/12 12:30 PM Ill need to do some more work on this. I have the check for the new capability in get_max_upload_file_size() but then the user's individual capability alters the site admin pages. Specifically if get_max_upload_file_size() returns -1 because the user is immune to file size restrictions the only options you get for maxbytes are server limit and -1. You're meant to get 8MB, 5MB, 2MB etc.
I could rework how the admin stuff works but I get the feeling that get_max_upload_file_size() should continue to behave the same for all users. Individual user exemptions can be dealt with outside of it.

Eric Merrill
added a comment - 24/Apr/12 7:41 PM Maybe add a optional param 'allowoverride'?
Then you just set it in the places where get_max_upload_file_size are used to inform the filepicker (it actually is only used in a handful of places in moodle)

Jason Fowler
added a comment - 30/Apr/12 11:18 AM repository/repository_ajax.php line 87 is extra whitespace where as repository/filepicker.php doesn't have the blank line (near line 96)
Other than that the code looks good andrew - love the name of the new capability

Andrew Davis
added a comment - 30/Apr/12 11:31 AM Fixed the white space. Putting this up for integration. As it involves introducing a new capability I'm not sure if this will be master only. I suspect it will as its rather new feature-ish.

The main moodle.git repository has just been updated with latest weekly modifications. You may wish to rebase your PULL branches to simplify history and avoid any possible merge conflicts. This would also make integrator's life easier next week.

Eloy Lafuente (stronk7)
added a comment - 12/May/12 1:35 AM The main moodle.git repository has just been updated with latest weekly modifications. You may wish to rebase your PULL branches to simplify history and avoid any possible merge conflicts. This would also make integrator's life easier next week.
TIA and ciao

The main moodle.git repository has just been updated with latest weekly modifications. You may wish to rebase your PULL branches to simplify history and avoid any possible merge conflicts. This would also make integrator's life easier next week.

Eloy Lafuente (stronk7)
added a comment - 19/May/12 7:00 PM The main moodle.git repository has just been updated with latest weekly modifications. You may wish to rebase your PULL branches to simplify history and avoid any possible merge conflicts. This would also make integrator's life easier next week.
TIA and ciao

The main moodle.git repository has just been updated with latest weekly modifications. You may wish to rebase your PULL branches to simplify history and avoid any possible merge conflicts. This would also make integrator's life easier next week.

Dan Poltawski
added a comment - 01/Jun/12 5:31 PM The main moodle.git repository has just been updated with latest weekly modifications. You may wish to rebase your PULL branches to simplify history and avoid any possible merge conflicts. This would also make integrator's life easier next week.
TIA and ciao

The main concern about this change is that by using the $COURSE global, it is going in the wrong direction (course centric, rather than context centric).

I'm still thinking about this, but I think my gut feeling i that we want this permission to only be a system level permission. The admin can give certain users the permission to override the course/activity limits.

Dan Poltawski
added a comment - 04/Jun/12 3:48 PM Hi Andrew,
The main concern about this change is that by using the $COURSE global, it is going in the wrong direction (course centric, rather than context centric).
I'm still thinking about this, but I think my gut feeling i that we want this permission to only be a system level permission. The admin can give certain users the permission to override the course/activity limits.

Andrew Davis
added a comment - 05/Jun/12 8:45 AM "The main concern about this change is that by using the $COURSE global, it is going in the wrong direction (course centric, rather than context centric)."
I dont understand what you mean. Can you explain that in another way?

Dan Poltawski
added a comment - 05/Jun/12 9:22 AM I dont understand what you mean. Can you explain that in another way?
Well, lets say an admin wants to allow a user to upload a big file in one specific activity rather than in the whole course then this is not possible using the course global to work out the context.
Where as if there was a specific context param then the admin could do both at course level and at course module level.

Discussed this a bit more between integrators and agreed that this course centric approach does not seem right, especially as we need to know the context in order to create a file in the filesystem as every file is tied to a context.

We came up with the following idea:

Introduce a new function get_user_max_upload_file_size, passing context as the first param and user as an optional fifth.

Check the capability to bypass file limits in the context passed

Investigate all the calls to get_max_upload_file_size and convert to the new max_upload_file_size

(optionally, probably advisable Depreciate the old function and mark with developer warnings).

Sorry for my incompetence causing the delay of this issue. I will be happy to help with this to get it resolved ASAP.

Dan Poltawski
added a comment - 05/Jun/12 9:27 AM Discussed this a bit more between integrators and agreed that this course centric approach does not seem right, especially as we need to know the context in order to create a file in the filesystem as every file is tied to a context.
We came up with the following idea:
Introduce a new function get_user_max_upload_file_size, passing context as the first param and user as an optional fifth.
Check the capability to bypass file limits in the context passed
Investigate all the calls to get_max_upload_file_size and convert to the new max_upload_file_size
(optionally, probably advisable Depreciate the old function and mark with developer warnings).
Sorry for my incompetence causing the delay of this issue. I will be happy to help with this to get it resolved ASAP.

"Investigate all the calls to get_max_upload_file_size and convert to the new max_upload_file_size"

I think there's some confusion here. I'm adding a new function called get_user_max_upload_file_size() that will exist alongside the current get_max_upload_file_size(). I dont think anything is getting deprecated. We cant always use the new get_user_max_upload_file_size() as using it makes viewing the system settings pages not work (admin looks at them, is immune to file size limits, all limits show -1)

Andrew Davis
added a comment - 05/Jun/12 10:54 AM Mostly done.
"Investigate all the calls to get_max_upload_file_size and convert to the new max_upload_file_size"
I think there's some confusion here. I'm adding a new function called get_user_max_upload_file_size() that will exist alongside the current get_max_upload_file_size(). I dont think anything is getting deprecated. We cant always use the new get_user_max_upload_file_size() as using it makes viewing the system settings pages not work (admin looks at them, is immune to file size limits, all limits show -1)

Ive altered the capability name. Hopefully the new one is more moodley. I did like the old one though. It reminded me of dungeons and dragons

"My concern was that there is a risk of inconsistency here if everywhere isn't using this new function."

There is some risk of inconsistency but its the good kind, if there is such a thing. If somewhere should be using the new function but isn't then the user will be dealt with more strictly than they should be. Going through calls to the old function now.

Andrew Davis
added a comment - 05/Jun/12 5:07 PM - edited Ive altered the capability name. Hopefully the new one is more moodley. I did like the old one though. It reminded me of dungeons and dragons
"My concern was that there is a risk of inconsistency here if everywhere isn't using this new function."
There is some risk of inconsistency but its the good kind, if there is such a thing. If somewhere should be using the new function but isn't then the user will be dealt with more strictly than they should be. Going through calls to the old function now.

I'm increasingly convinced that it would be a bad idea to make any further code changes in regards to this issue at this time. We've fixed the problem that saw this issue raised. I'd be happy to see this go in as is. We can flush out places where we are being overly strict over time.

My concern is that by switching from more places over from get_max_upload_file_size() to get_user_max_upload_file_size() we're placing the burden of additional error handling on the calling code. If you call get_max_upload_file_size() PHP's own file limits will be factored in. If you call get_user_max_upload_file_size() and the user is exempt from file limits you need to deal with the possibility that the user will then try to upload something so large that PHP itself throws an error. I'm not confident that the existing error handling is up to scratch. Maybe it is but I'm not confident. I feel like Im making a lot of changes deep in the bowels of Moodle in areas I dont understand and that are going to affect basically everywhere.

Plus the testing would essentially be "test everywhere that a user can upload a file" which is an awful lot of places :\

Andrew Davis
added a comment - 06/Jun/12 9:54 AM I'm increasingly convinced that it would be a bad idea to make any further code changes in regards to this issue at this time. We've fixed the problem that saw this issue raised. I'd be happy to see this go in as is. We can flush out places where we are being overly strict over time.
My concern is that by switching from more places over from get_max_upload_file_size() to get_user_max_upload_file_size() we're placing the burden of additional error handling on the calling code. If you call get_max_upload_file_size() PHP's own file limits will be factored in. If you call get_user_max_upload_file_size() and the user is exempt from file limits you need to deal with the possibility that the user will then try to upload something so large that PHP itself throws an error. I'm not confident that the existing error handling is up to scratch. Maybe it is but I'm not confident. I feel like Im making a lot of changes deep in the bowels of Moodle in areas I dont understand and that are going to affect basically everywhere.
Plus the testing would essentially be "test everywhere that a user can upload a file" which is an awful lot of places :\

We're just chatting about this - man this issue just keeps throwing hurdles in our way as we discover them!

One (not sounding very elegant solution) would be to have a parameter, defaulting to on of whether we observe php file limits. Then when users have the capability to bypass restrictions they could go all the way up to the max php limit in places restricted by that. Places that don't need to care about the php restriction would be truely unlimited if they passed the param.

Dan Poltawski
added a comment - 06/Jun/12 10:10 AM We're just chatting about this - man this issue just keeps throwing hurdles in our way as we discover them!
One (not sounding very elegant solution) would be to have a parameter, defaulting to on of whether we observe php file limits. Then when users have the capability to bypass restrictions they could go all the way up to the max php limit in places restricted by that. Places that don't need to care about the php restriction would be truely unlimited if they passed the param.

Andrew Davis
added a comment - 08/Jun/12 1:02 PM Ive made some minor tweaks. I'm trying to identify a subset of the calls to get_max_upload_file_size() that are reasonably easy to to switch over and test comprehensively.

Ive switched over 2 instances of get_max_upload_file_size() and added additional testing instructions. A lot of the other calls to get_max_upload_file_size() I cannot for the life of me figure out how to get the code to be executed from the UI.

Andrew Davis
added a comment - 08/Jun/12 6:31 PM Ive switched over 2 instances of get_max_upload_file_size() and added additional testing instructions. A lot of the other calls to get_max_upload_file_size() I cannot for the life of me figure out how to get the code to be executed from the UI.

Marina Glancy
added a comment - 11/Jun/12 11:22 AM Hi Andrew, how about filemanager and filepicker form elements?
In form_filepicker we call get_max_upload_file_size() always:
https://github.com/moodle/moodle/blob/master/lib/form/filepicker.php#L82
and acually it is often called in other places in the code before ->addElement('filepicker',
And in form_filemanager we also call get_max_upload_file_size() several times:
https://github.com/marinaglancy/moodle/blob/master/lib/form/filemanager.php

Marina Glancy
added a comment - 11/Jun/12 11:47 AM - edited another thing is that I would exclude lines like
'maxbytes' => get_max_upload_file_size($CFG->maxbytes),
completely or set to -1 (in rubrics and lesson), because now it makes no sense. Maxbytes will be adjusted to server/php/apache limits anyway.

I'm afraid that "'maxbytes' => get_max_upload_file_size($CFG->maxbytes)" is still necessary. The function that determines max file size doesnt actually retrieve the site maximum file limit. It relies on having it passed in. There's probably a reason why it was implemented that way but I dont know what it is.

Andrew Davis
added a comment - 11/Jun/12 6:46 PM I'm afraid that "'maxbytes' => get_max_upload_file_size($CFG->maxbytes)" is still necessary. The function that determines max file size doesnt actually retrieve the site maximum file limit. It relies on having it passed in. There's probably a reason why it was implemented that way but I dont know what it is.

Andrew Davis
added a comment - 13/Jun/12 9:27 AM For whatever reason most of the capability definitions in lib/db/access.php have an empty line there. I just copied what was already there. Not sure why...
Submitting for integration.

Eloy Lafuente (stronk7)
added a comment - 14/Jun/12 8:54 AM Ho,
while for sure more work is needed to get the limits applied properly site-wide, I think current patch achieves the goals for this issue: To be able to bypass the calculated maxbytes via capability.
I don't know if the code achieves that (haven't looked/know much), but the testing instructions do (IMO). So this gets my +1 if works as expected in the instructions.
Only 2 comments:
1) Does all this work with JS disabled?
2) Does people with the capability really see "-1 bytes". If so, it's really horrible. Please fix that to be "unlimited" or whatever. Here or in another issue.
Ciao

Dan Poltawski
added a comment - 14/Jun/12 12:19 PM I've integrated this now.
Thanks Andrew for all your work on this, I know this was a bit of a beast, we got there eventually!
I agree we need to sort out the -1 issue, perhaps even as a blocker.

Failed when addind a video/audio to a page resource. The file size can be anything when using the file repository. I tried the upload, and the max upload limit error is raised.

I did not check the capability as the first steps failed.

I tried hard to track why this fails but did not find much. What happens is that the maxbytes setting is wrong. It appears to be zero even though I had set it to 2MB. And the call to repository_ajax.php sends maxbytes = -1.

Frédéric Massart
added a comment - 14/Jun/12 2:36 PM - edited Failed when addind a video/audio to a page resource. The file size can be anything when using the file repository. I tried the upload, and the max upload limit error is raised.
I did not check the capability as the first steps failed.
I tried hard to track why this fails but did not find much. What happens is that the maxbytes setting is wrong. It appears to be zero even though I had set it to 2MB. And the call to repository_ajax.php sends maxbytes = -1.
Edit:
Found that in repository/filepicker.js:545,
params['maxbytes'] = this.options.maxbytes?this.options.maxbytes:-1;
sets maxbytes to -1 when it is equal to 0. It shouldn't.

Ive raised MDL-33760 to deal with the page description not observing file size limits. It appears to be an old but that we've just now noticed. Im also updating the testing instructions to specifically exclude the page description from the testing of this issue.

Andrew Davis
added a comment - 15/Jun/12 11:02 AM Ive raised MDL-33760 to deal with the page description not observing file size limits. It appears to be an old but that we've just now noticed. Im also updating the testing instructions to specifically exclude the page description from the testing of this issue.

As a teacher, in my private files "Maximum size for new files: 100MB" which is the userquota. "You have reached your file quota limit" is displayed but I can still upload any file with any file size, exception made for the files which exceed max_upload_size. I have removed the capability from all the roles and checked that the teacher didn't have it.

Edit: It appears that My private files uses the userquota and nothing else when validating the form.

More edit: I have linked this issue with a new one (MDL-33766), I'll let you decide if that new one blocks this issue or not. If not, the test passes.

Frédéric Massart
added a comment - 15/Jun/12 2:04 PM - edited Hi Andrew,
Ok, now it makes sense about the content and description, and it works.
I am just concerned about My private files where I cannot reproduce your steps.
My settings
moodlecourse | maxbytes = 2MB
userquota = 104857600
upload_max_filesize = 120M
post_max_size = 128M
As a teacher, in my private files "Maximum size for new files: 100MB" which is the userquota. "You have reached your file quota limit" is displayed but I can still upload any file with any file size, exception made for the files which exceed max_upload_size. I have removed the capability from all the roles and checked that the teacher didn't have it.
Edit: It appears that My private files uses the userquota and nothing else when validating the form.
More edit: I have linked this issue with a new one ( MDL-33766 ), I'll let you decide if that new one blocks this issue or not. If not, the test passes.

was testing other issues when I discovered that picking files from the filesystem repository was not working any more. Bisecting the problem back, it seems that this commit (part of this issue): 845c2ae

Eloy Lafuente (stronk7)
added a comment - 15/Jun/12 5:09 PM Hi,
was testing other issues when I discovered that picking files from the filesystem repository was not working any more. Bisecting the problem back, it seems that this commit (part of this issue): 845c2ae
is the one causing the problem.
To reproduce:
1/ create filesystem repository instance.
2/ add the any backup file (1.1MB or bigger)
3/ click settings->restore
4/ pick the file (apparently it's picked ok)
5/ click "restore"
Expected:
A page showing the backup summary information is show.
Current:
error/invalidrestorefile with information:
Debug info:
Error code: invalidrestorefile
$a contents:
Stack trace:
line 157 of /backup/util/ui/restore_ui_stage.class.php: restore_ui_exception thrown
line 42 of /backup/restore.php: call to restore_ui_stage_confirm->process()
Note it's restore the one throwing the error, but surely caused because of some previous error (silently happen, I don't get any other information nor on screen nor in logs).
The exact previous commmit 1812ea3 (also belonging to this issue) allows the restore to happen, so...
Ciao

Helen Foster
added a comment - 15/Jun/12 5:39 PM I also obtained error/invalidrestorefile (with same debug info and stack trace) when attempting to upload a small (less than 1MB) backup file to http://qa.moodle.net then clicking restore.

We are not going to revert this change and going to leave master in this 'broken' state because we'd really like to see this improvement into 2.3 and not delayed any further. So if you could work on a fix with urgency then hopefully we can get this integrated and signed off for release.

Dan Poltawski
added a comment - 15/Jun/12 6:01 PM Hi Andrew,
We are not going to revert this change and going to leave master in this 'broken' state because we'd really like to see this improvement into 2.3 and not delayed any further. So if you could work on a fix with urgency then hopefully we can get this integrated and signed off for release.

Andrew et all, FYI, I'm adding this commit right now, to allow the picker to continue working as it was before the patch. It simply avoids the -1 to be returned and I've verified here that it makes both upload and fs repos to, at least, work.

Without it nothing can be picked properly. Of course, the final solution for this should uncomment that commit. It's just one interim solution to keep things working.

Helen Foster
added a comment - 16/Jun/12 11:50 PM Just tried again to upload a backup file to http://qa.moodle.net then clicked restore. No error this time! The course backup restored without any problem.

Later code is meant to copy the backup file to /home/andrew/Desktop/tempdata/moodledata/dev/master/temp/backup/61761eb5e161d33ee4a570acb151b7b6 however $fs->get_area_files() is returning an empty array so we're returning.

As a side note, /backup/restorefile.php should probably be checking the return value of $form->save_file('backupfile', $pathname); UPDATE: raised MDL-33799 to deal with this.

Andrew Davis
added a comment - 17/Jun/12 5:35 PM - edited Just recording some notes. If anyone has any theories feel free to jump in.
This is the code thats producing the visible error. From restore_ui_stage.class.php
if (!file_exists("$CFG->tempdir/backup/".$this->filename)) {
throw new restore_ui_exception('invalidrestorefile');
}
This is the problem in moodleform::save_file()
if (!$files = $fs->get_area_files($context->id, 'user', 'draft', $draftid, 'id DESC', false)) {
return false;
}
Later code is meant to copy the backup file to /home/andrew/Desktop/tempdata/moodledata/dev/master/temp/backup/61761eb5e161d33ee4a570acb151b7b6 however $fs->get_area_files() is returning an empty array so we're returning.
As a side note, /backup/restorefile.php should probably be checking the return value of $form->save_file('backupfile', $pathname); UPDATE: raised MDL-33799 to deal with this.

repository_ajax.php is actually adding the backup file to the file table. Then the user is redirected to /backup/restorefile.php and something is actually deleting the row from the file table before the backup code is able to access the file.

update: the get_data() call backup/restorefile.php is deleting rows from the file table

Andrew Davis
added a comment - 18/Jun/12 11:47 AM - edited repository_ajax.php is actually adding the backup file to the file table. Then the user is redirected to /backup/restorefile.php and something is actually deleting the row from the file table before the backup code is able to access the file.
update: the get_data() call backup/restorefile.php is deleting rows from the file table
$form = new course_restore_form(null, array('contextid'=>$contextid));
$data = $form->get_data();

Im going to heavily update the testing instructions. Just in case here are the old ones.

For this test you'll need a teacher and your admin user. A 3rd user with very basic capabilities ie a student, will also be handy.

Check your site's maximum uploaded file size. This is a site setting called "maxbytes".

Set maxbytes to 2MB.

You'll need 2 files.
1 small file ie smaller than 2 MB.
1 large file. I'm using an 82MB video. The precise size doesn't matter but it should be bigger than your PHP max upload size.
They both need to be media files (video or music).

As admin go to course admin > users > permissions > check permissions and check "moodle/course:ignorefilesizelimits" for a teacher. The teacher should NOT have moodle/course:ignorefilesizelimits.

File system repository set up
1. create a directory at moodledata/repository/examplerepository then set up a file system repository using that directory by going to: Site administration > Plugins > Repositories > Manage repositories > File System > Settings > Create a Repository Instance
2. Outside of Moodle copy your 2 files into the repository directory.

Create a new Page in a Course

All of the following uses the page content field. Do NOT use page description due to an outstanding bug (MDL-33760).

User without moodle/course:ignorefilesizelimits test
1. Edit the page. Using the media button add a link to the smaller file in your file repository in the page content. It should succeed.
2. Repeat this with the bigger file. It should fail with a message like "This file is bigger than the maximum size"

Has capability test
1. As admin give the teacher role moodle/course:ignorefilesizelimits within the course. course administration > users > permissions.
2. As teacher edit the page and check that you can now use the media button to link to both the small and the large file when they are in a file system repository.

Upload repository test
1. Edit your page again but this time on the file picker click "upload a file" and link to the smaller file. It should succeed.
2. Repeat this with the larger file. You should get an error saying that the file is too big. This is due to PHP's max file upload size which we cannot easily avoid but which we should handle gracefully.

Additional tests for other areas using the new function

1.create a lesson and add a content page. after the page is created, edit the page and put an image in the page content. Just checking that image insertion still works.

2. create assignment, set grading to rubric and create a new rubric.

3. With a user who has moodle/course:ignorefilesizelimits backup a course. Outside of Moodle copy it into your file repository. Start a course restore and you should be able to access the backup file in the file repository.

4. My private files. Bear in mind the context where you gave the user the capability. my files is outside of a course.
1) Go to my private files. As a user without moodle/course:ignorefilesizelimits you should see
something like "Maximum size for newfiles: 2MB - drag and drop available" near the top right of the file manager.
2) As a user with moodle/course:ignorefilesizelimits (or admin) you should see something like
"Maximum size for new files: -1 bytes - drag and drop available"
3) As the user with the capability drag your large file into your private files. You should get an error message about PHP.
4) As the user with the capability click "Add..." and add a large file from your file repository. It should succeed.

Andrew Davis
added a comment - 18/Jun/12 12:41 PM Im going to heavily update the testing instructions. Just in case here are the old ones.
For this test you'll need a teacher and your admin user. A 3rd user with very basic capabilities ie a student, will also be handy.
Check your site's maximum uploaded file size. This is a site setting called "maxbytes".
Set maxbytes to 2MB.
You'll need 2 files.
1 small file ie smaller than 2 MB.
1 large file. I'm using an 82MB video. The precise size doesn't matter but it should be bigger than your PHP max upload size.
They both need to be media files (video or music).
As admin go to course admin > users > permissions > check permissions and check "moodle/course:ignorefilesizelimits" for a teacher. The teacher should NOT have moodle/course:ignorefilesizelimits.
File system repository set up
1. create a directory at moodledata/repository/examplerepository then set up a file system repository using that directory by going to: Site administration > Plugins > Repositories > Manage repositories > File System > Settings > Create a Repository Instance
2. Outside of Moodle copy your 2 files into the repository directory.
Create a new Page in a Course
All of the following uses the page content field. Do NOT use page description due to an outstanding bug ( MDL-33760 ).
User without moodle/course:ignorefilesizelimits test
1. Edit the page. Using the media button add a link to the smaller file in your file repository in the page content. It should succeed.
2. Repeat this with the bigger file. It should fail with a message like "This file is bigger than the maximum size"
Has capability test
1. As admin give the teacher role moodle/course:ignorefilesizelimits within the course. course administration > users > permissions.
2. As teacher edit the page and check that you can now use the media button to link to both the small and the large file when they are in a file system repository.
Upload repository test
1. Edit your page again but this time on the file picker click "upload a file" and link to the smaller file. It should succeed.
2. Repeat this with the larger file. You should get an error saying that the file is too big. This is due to PHP's max file upload size which we cannot easily avoid but which we should handle gracefully.
Additional tests for other areas using the new function
1.create a lesson and add a content page. after the page is created, edit the page and put an image in the page content. Just checking that image insertion still works.
2. create assignment, set grading to rubric and create a new rubric.
3. With a user who has moodle/course:ignorefilesizelimits backup a course. Outside of Moodle copy it into your file repository. Start a course restore and you should be able to access the backup file in the file repository.
4. My private files. Bear in mind the context where you gave the user the capability. my files is outside of a course.
1) Go to my private files. As a user without moodle/course:ignorefilesizelimits you should see
something like "Maximum size for newfiles: 2MB - drag and drop available" near the top right of the file manager.
2) As a user with moodle/course:ignorefilesizelimits (or admin) you should see something like
"Maximum size for new files: -1 bytes - drag and drop available"
3) As the user with the capability drag your large file into your private files. You should get an error message about PHP.
4) As the user with the capability click "Add..." and add a large file from your file repository. It should succeed.

Andrew Davis
added a comment - 18/Jun/12 12:52 PM This is now up for peer review. afaik, this can go straight to integration if there are no issues found.
Integrators, if you're not happy with the constant name feel free to change it if Im not online

Ive raised MDL-33803. I'm intending to fix that once this issue is done with. Its only a problem if JS is disabled in the browser so I dont think its massively important. I will certainly fix it however this issue doesnt need to be dragged out any longer.

Andrew Davis
added a comment - 18/Jun/12 1:34 PM Ive raised MDL-33803 . I'm intending to fix that once this issue is done with. Its only a problem if JS is disabled in the browser so I dont think its massively important. I will certainly fix it however this issue doesnt need to be dragged out any longer.

Andrew Davis
added a comment - 19/Jun/12 12:24 PM Submitting for integration.
For anyone interested, I introduced the constant as I can see theres going to be more places where we need check against maxbytes. Trying to avoid having mysterious -1's scattered throughout the code.

Frédéric Massart
added a comment - 20/Jun/12 12:19 PM All right guys, we're getting closer to closing this issue, but there are still a few bugs.
When a teacher, without the capability, on the restore backup page, the maxbytes limit is the php limit, not the maxbytes setting. Probably because this is a filepicker, not a filemanager.
When an admin, dragging/dropping files larger than the php post limit result in sesskey error. Probably because $_POST is empty as it exceeded the post limit.
Not failing or passing yet.
(That'd be nice if the test instructions mentioned the course max upload size, and the php post/upload limit to use)

We're a little stuck here. Ultimately what we probably need is to switch to using an object (or something) to represent file size restrictions instead of a single number. Returning the calling code an object containing the activity/course file size limit, PHP's file limit plus a flag indicating whether or not the user can ignore limits would allow a more nuanced approach. Overloading an int with multiple meanings has limitations which we're discovering

Andrew Davis
added a comment - 20/Jun/12 12:26 PM Looking at these now.
We're a little stuck here. Ultimately what we probably need is to switch to using an object (or something) to represent file size restrictions instead of a single number. Returning the calling code an object containing the activity/course file size limit, PHP's file limit plus a flag indicating whether or not the user can ignore limits would allow a more nuanced approach. Overloading an int with multiple meanings has limitations which we're discovering
Anyhow, trying to figure out the best way forward now.

"When a teacher, without the capability, on the restore backup page, the maxbytes limit is the php limit, not the maxbytes setting. Probably because this is a filepicker, not a filemanager."

Im not sure about filepicker Vs file manager however the file size limit displayed on the restore page is definitely the site setting "maxbytes" even if the course setting "maximum upload size" is lower than maxbytes. Im checking the logic but Im not entirely sure whether or not that is correct.

Andrew Davis
added a comment - 20/Jun/12 1:05 PM "When a teacher, without the capability, on the restore backup page, the maxbytes limit is the php limit, not the maxbytes setting. Probably because this is a filepicker, not a filemanager."
Im not sure about filepicker Vs file manager however the file size limit displayed on the restore page is definitely the site setting "maxbytes" even if the course setting "maximum upload size" is lower than maxbytes. Im checking the logic but Im not entirely sure whether or not that is correct.

Frédéric Massart
added a comment - 20/Jun/12 1:22 PM In my case, the maxbytes setting for course and site are 2MB, and the PHP limit is 120MB. I can upload larger files than 2MB on the restore page as a teacher. Larger than 120MB fails.

Andrew Davis
added a comment - 20/Jun/12 4:31 PM I have added a 2nd commit to the branch. https://github.com/andyjdavis/moodle/commit/703ffaea05dd73cff661cbad8d58e6286fc6b20a
This makes the file picker observe the course file size limits. However, I quite literally have no idea why it wasn't working before.
This was always returning false for some unknown reason.
if (!empty($PAGE->course)) {
This works
if (!empty($PAGE->course->maxbytes)) {

Andrew Davis
added a comment - 20/Jun/12 4:35 PM re the poor handling if the user uploads a file above PHP's post_max_size, I'm not sure we are going to be able to find a good way to handle that in a timely fashion.

Eloy Lafuente (stronk7)
added a comment - 25/Jun/12 12:42 AM And this has been incorporated to all the weekly builds and also, to Moodle 2.3 Release Candidate 1, yay!
Many, many thanks for your hard work!
Ciao

Mary Cooch
added a comment - 24/Jul/12 4:14 AM I am about to remove the docs_required label but just checking - although the title here refers to the Filesystem repository, this conversation seems to go much further and actually relates more to the new capability http://docs.moodle.org/23/en/Capabilities/moodle/course:ignorefilesizelimits Am I correct in this or have I missed something out?

Dan Poltawski
added a comment - 24/Jul/12 10:00 AM Mary, you are correct - it relates to the ignorefilesizelimits capability. This is a solution for the 'I want to upload files bigger than the server limits (php)'.
This allows the person granted this capability to bypass the moodle restrictions where they are able to - it won't work for things like upload a file as that is restricted by php.

Daniel Neis Araujo
added a comment - 28/Jul/13 1:52 AM Hello,
i think we should review this capability as it is confusing and tell users about "php.ini" stuff is not that helpful. Please take a look at the linked issues.
Kind regards,
Daniel