From the discussion in
MDL-33297 and Martin's comments
"The choice is basically this:
1) Easiest/some risk: Dan's idea above: we changes the managefiles check to (managefiles OR is owner of the file). I don't think it's too unreasonable, though it does break the idea a little that the modules own the files and there might be repercussions of that down the track (can't think of scenarios though).
2) Easy/no risk: we modify get_listing() in repository/recent/lib.php so that it does NOT call the file browser, and uses some other way to build $fileinfo more directly. I can't see a good function for this so we might need to make one. At least all the hackiness is one contained place rather than all through the file browser machinery.
3) Harder/riskier: We do what I mentioned above, which is to create a new filearea called "recentfiles" under the user, and every time new files are added to Moodle from any external source, we create a clone copy of the file in this area. This will DOUBLE the files table, yes, but it is "correct" according to the current Files API design.
I need some votes on this from senior people so we can proceed.
Martin Dougiamas added a comment - 29/May/12 7:52 PM - edited
4) Define recent files as "show all the existing draft files with my userid". Anything you had added in an filemanager recently would show up,as well as files you own that you had just looked at in a filemanager. But it would disappear after a few days.
this issue is about solving the difficult problem from
so the one way is option #3:
For displaying 'Recent files' (repository_recent) and correctly process files access restrictions it was decided to create new filearea
- Create new filearea user/recentfiles
- Create some function to copy files there
- Call this function at all the places in the code where we want files to be considered recent files
- Modify recentfiles to use this filearea, with no references allowed
- Add settings to control lifetime of these files
- Add cron job to clean out these files older than lifetime