General developer forum

"proof-of-concept" - as in the first line of my post.

Hi.

I'll briefly address #2 (more accurately the subject of this thread ... when I say #2 below, that's what I mean) and #3.  I don't know about #1.

First, I'm guessing there's a pretty good chance 2.1 will have #3 especially, maybe #2.  That's slated for the end of this month, hence there's a really good chance things'll all be working the way you want before next March, or at least you will have enough info. well prior to make a decision.

Second, note there is a Legacy Course Files Area (LFC Area) that basically works the same as the old Files area, except with better privacy.  All links to a file there would be "updated" when that target file was changed.

I am, though, concerned because the LCF Area is not supposed to be used (I believe because of privacy/security issues), and I'm assuming this also means it won't exist for ever, but I haven't yet seen work explicitly being done to support the link-once-update-multiple-times feature present in the old Files Area and the LCF Area.  The closest I've found is a mention of file synchronization in documentation, some related issues describing workarounds in 2.x, and a tracker issue (23306) on related improvements.

P.S. I'm not trying to say you should move to 2.x now, either.  Sticking with 1.9.x for now is reasonable.

Matt,

Your experience with teaching staff Moodle EXACTLY paralles mine!

Getting teachers to put basic files and work on-line is a simple, practical starting point that opens the door to all the other wonderful "interactive" things Moodle can do later when they ready to use them!!!!  Where you start to get initial success can be CRITICAL to long term adoption.

Losing the long established 1.9 file upload tool's simplicity has gutted our successful model for early adoption strategies.  Can we get back some key functional parts????  work tim did here say's "yes"  IF it can be continued!

I fully agree with you. See my post here, from an admin's point of view:

http://moodle.org/mod/forum/discuss.php?d=174702#p788253

And as I write in some posts there:

Multiple reference IS A PROBLEM, even a button to UPDATE ALL REFERENCES will probably cause more harm than benefit, especially when teachers work in teams on different courses sharing one and the same file(name) and file-areas. Who will help them to keep track of the different versions they upload and the courses/resources where they want to keep one version rather than the new one. So I would have to teach them a fix again: NEVER UPLOAD a file with the same name! Change the name like that file01.pdf, file02.pdf so as to be sure you can reference the correct version in any course/resource, otherwise you will certainly loose track. And I would have to tell them also: NEVER USE THE UPDATE ALL REFERENCES button, unless you are the only teacher of your courses and you know well what you are doing.

And attaching files to activities/resources is ok, but as activities/resources belong to a course anyway, I do not see why the files should  not be saved into an OS directory like it was done in 1.9, so as to keep backup&restore very simple for system administrators.

Rosario

ELIS is currently only available for Moodle 1.9 (though we are currently working on porting it to Moodle 2), so the comparison in that document is only in relation to Moodle 1.9's file system.

Moodle 2 already has an Alfresco repository plugin (among others).

Tim: I think the issue with files, like for download on the home page, is not a real problem. Also if it's 'files' that are reused in other places the solution is easy, upload it to the homepage as a file resource and then link to it from several places.

More likely the problem would be with images - say you make an image of, I dunno, the periodic table. You might use that image in 2 forum posts, a wiki page, 18 different quiz questions, etc. But now somebody discovers another element! Oh sh-!

(I agree that the problem with this ought to affect relatively few situations though.)

--sam

Tim said:

> I think it is much more likely you might have to upload the same document to several different courses, but the updating that is just as much of a pain in 2.0 as in 1.9.

In 1.9, I upload one file SCHEDULE.PDF to Site Files, copy the link, put it in a template course, CDW3Template, before I replicate identical courses with different teachers -- CDW3A, CDW3B, CDW3C, CDW3D, and so forth. I replicate the courses. Later, I discover that my idiot student worker used the 2009 calendar not the 2011to make SCHEDULE.PDF. In 1.9, I overwrite SCHEDULE.PDF with the new, corrected file. The links in all identical courses still point to the correct file.

In 2.0, the procedure is to upload the new SCHEDULE.PDF, copy the link, and go through each course, one by one, replacing the link.

As I understand it, Moodle 2.0's internal file naming scheme does not give the same name to the newly uploaded file, and so, you must relink in each course.

There are at least TWO scenarios in which teachers upload new versions of their files:

1. Single Teacher, multiple courses of the same sort, with different classes: every file he/she uploads may be a first draft, a second improved draft, and a final one. Every draft being refined and tuned and improved with the students collaboration, something you develop during the course
2. Multiple Teachers, multiple courses of the same sort, with different classes: dito

A real course area, with files lying on the OS file system, still has its reasons to continue to exist like in 1.9, even if it were only to make life easier for system admins who have to recover sigle files from tapes, when teachers lose them or acidentally overwrite them with the wrong version of the same file, which in principle is the very same danger/mess of the new file system. The only difference is that in 1.9 a lost or overwritten file belonged to the course's file area and could easily be retrieved from tape. Now in 2 you never know which version of the file uploaded with the same name and hence replaced is still referenced by which resource. And copying the whole file into a resource's file area only makes things worse, because teacher know this copy of the file only by its original file name and not by the metadata produced by Moodle to correctly handle it internally. So teachers will definitively get lost. A slightly better approach would really be to keep only ONE copy of an uploaded file, so as to store it really only once on the OS' file system and save a lot of disk space, but then a certain file name could only be used once. And if the file's name would be allowed to be used in each course, we return to the point where we startet, the course-file-area of 1.9

As I already said, resources/activities/etc. belong to a course anyway and hence keeping the legacy file system of 1.9 is the best solution for teachers and system admins.

Why do you not combine the CONS of both file systems?

• I would even agree on creating not a course-file-area any more, BUT on a personal basis, i.e. per given teacher or group of teachers (cohort?)
• this area would be created transparently on the OS' file-system to facilitate backup&recovery to/from tapes, no hash no scramble no lookup-tables necessary
• so a file would exist only once and could be referenced in different courses/activities/resources/etc.
• uploading a file with the same name replaces any older version and all references to that file would still continue to work, no link-update necessary
• course backups would include all referenced files to be consistent when you restore them
• restore of backup-zip-files would include an intelligent mechanism to RElink and save the referenced files again into the new teacher's/cohort's file area. So this process has to be interactive so as to specifiy the teacher/cohort before starting the restore
• access permissions should be inherited from the activity/resource/etc. where the file is referenced and not from the file-area where the file resides
• so as not to offer the students the opportunity of guessing a file name like it was in 1.9 links should not show the original file name but a randomly generated ID when the links in activities/resources/etc. are created
• file-areas of single teachers or teacher teams (cohorts?) should be treated as private and hence should not be accessible for others
• still there should be a global Moodle file area like site files in 1.9 accessible to all teachers and admins only. Files from there have to be downloaded first and then uploaded into the teachers'/cohorts' file area, or copied internally to avoid criss-cross references and orphaned links if someone deletes a file there
• multiple references to one file are still dangerous in such shared file areas but we have to leave this to the responsibility of the teacher teams which have to agree on a common policy if they reference a file in different courses/activities/resources/etc.

As per http://moodle.drupalgardens.com/article/tue-06152010-1918/ftp-files-moodle-20-repository-api

>>
Then you can go ahead and create folders for each teacher, or course or however you want to structure the files, and give the content creators (probably the teachers) upload permissions to the folders using FTP or whatever method you allow.

The Moodle 2.0 admin can then add those directories as sources for files in the file picker.
>>

is far too complicated for a medium to large scale site like ours. This should be handled internally by Moodle as I proposed, one directory per teacher oder teacher team. Whether the sysadmin wants to expose those directories per FTP or WebDav should be possible and stay in his/her responsibility.

Rosario