Is there already a current plugin that implements a tool for admins to upload CSV files or txt files to /var/www/moodledata/ directory???
What exactly are you trying to do? Uploading any file is handled by the Files API, I've written a few plugins that upload CSV files for processing:
http://moodle.org/plugins/view.php?plugin=block_metalink
http://moodle.org/plugins/view.php?plugin=block_tutorlink
oooh thanks for those links but i think what i am trying to do is simpler. I would just like to know if there is a form or plugin or whatever that allows an admin to upload a file (txt or csv) to /moodledate folder.
I dont have to save it to the database. Just pure uploading into file server for easy usage by admin.
Would you know if there is an existing plugin already?
Thanks.
Did you check in the FRONT-PAGE Area in the Admin-Block where it says SITE-FILES? I would have to check whether those uploads are stored in moodleData/1/ directory.
YES, they are, I just verified.
But of course only the Moodle-site-Admin is able to upload files there.
Rosario (talking about Moodle 1.9.x)
Ooooh. I'm going to look for it. For now, I dont see any SITE FILES there. I've attached a screen cap of how my FRONT PAGE looks like.
Thanks for the info.
Well, unfortunately we're using Moodle 2.0 so SITE FILES is not available anymore.
Thanks anyway.
In Moodle 2.x the File-System has been redesigned completely and unfortunately not only for the better of us system-administrators. See my complaints in these forums.
But you could enable legacy course files and see whether it works. At least this should give you some course-related directories if they are not encrypted anyway.
Otherwise you should set up sort of a common repository for administrators. Unfortunately I have to explore these things myself as I will have to implement something to enable teams of teachers to have a common place in Moodle where they can see and upload their files to. This was very simple in Moodle 1.9 where files were stored in the course files area and every teacher of the same course could see and manipulate those files. Now, with personal upload areas which are detached from the courses/resources where you link your files to, it is more complicated.
Rosario
Rosario,
This may be of interest for you: http://moodle.org/plugins/view.php?plugin=local_davroot
Tomek
Thanks a lot. If I can use WEBDAV built in in Moodle 2.x and set it up to reflect the windows-share used by every single university of our school, it would be a good solution I think. But I wonder how the WebDav-repositories in Moodle would pass authorization to the windows-share. If username and password was asked, it would be fine, as only teachers of every single university can access only their own share and not another one's. And as we use shibboleth to authorize our Moodle users, correct authorization would be known by the users' web-browsers. But I do not think that web-browsers could pass this Information down by WebDav to the windows-share. So no single sign-on for the moment being, but asking for the credentials would be fine anyway.
Rosario
Hi Rosario,
I'm the author of that local plugin: this plugin authenticates the user against the standard Moodle chain of auth plugins - lib/moodlelib.php::authenticate_user_login(), probably not true for MNET, not really sure - and it should work out-of-the-box for "most" of the auth plugins, probably Shibboleth included.
If not, I can help you in debugging issues: I'm actually missing a testing environment for your scenario but we can try to help each other in finding fixes, if needed.
I'm used to use Cyberduck so credentials will be always asked to the final user but, since HTTP Basic is the auth mechanism presented to the WebDAV client, the native Windows WebDAV client should never try to perform a silent NTLM authentication.
IMHO the best way to give DAVRoot a try is to use Cyberduck for discovering potential issues, both technical or functional, before going further in using the Windows native client.
HTH,
Matteo
Carissimo Matteo, unfortunately I did not have time to dive deeper into the new file system. But when I heard that WebDav would be implemented into Moodle 1.9 I thought, this would give me a chance to let teams of teachers connect to their own windows-share.
When I wanted to give it a try, I realized that the module was not so easy to implement into 1.9, so I never tried and never tested, hoping the module would be built into core in 2.x
Ok, my 2.07 testserver has been running for a year now and SUSE SLES SP 2 (just released) offers PHP 5.3 so that the prerequisites for 2.2 and higher are met.
And with that I must start to find a solution for teachers working in teams and needing a common upload-area or upload-repository.
Now tell me the difference between your plugin and the built in WebDav repository support.
As far as I can see (by reading the Moodle-doc-page in the WebDav-Repository), an IIS Server on the windows-file-server-side is a prerequisite. So if I understand correctly, Moodle will actually be communicating with that IIS and not accessing the windows-share directly. This makes sort of a sense, because you could not expose a windows-share and its cifs file-protocol directly to internet. So the IIS would have to expose/access the desired windows-share and would have to deal also with user access ACLs set on that share. If the users are allowed to access that share, IIS would expose its contents via WebDav-Protocol to Moodle... Am I right? Please correct me if I didn't catch it right.
Saluti dalla Svizzera, Rosario
Ciao Rosario,
you are correct but... WebDAV repo and DAVRoot local plugin are quite different things at the functional level, they just share their using WebDAV to "manage" files: the first will give you the possibility to access files in Moodle through an "external filesystem" being managed with WebDAV, the second will give you the possibility to directly access the (new hashed&area-based) Moodle 2.x filesystem.
Log story short: DAVRoot has been coded to learn Files API and to troubleshoot file issues in Moodle 2.x i.e. for debugging purposes. Thanks to the hard work of Moodle DEVs in creating the Files API, this plugin can give you a WebDAV access to every object of the new virtual file system in Moodle 2.x e.g. direct creation of folders&files as in Moodle 1.9 with the (old) course files manager.
HTH,
Matteo
Aaah, I see. It is not what I am looking for, but very very useful if I wanted to restore one single file from tape. Which is one of my major complaints regarding the new file system. It was very comfortable before because I could restore every single file when teachers missed them. Now I would have to figure out first in which directory it was stored with which name. But I fear that your plugin will not help in this because if a file were deleted, I will not be able to find the place where it was stored. So not knowing how it was called and where it was stored, I will not even be able to locate it on the tape.
Or am I mistaken??
Rosario
Ciao Rosario,
well, you're not wrong but... the new trashdir folder is something equal to the normal files pool folder (filedir) and it is purged once per day for each deleted context if you don't set:
$CFG->fileslastcleanup = time();
in your config.php - see more at lib/filestorage/file_storage.php::cron() - and the files table will be your bad friend to work at the deleted files recovery, unless - obviously - even the context will be destroyed. The nice thing is that in this scenario you'll be able to recover the file simply accessing it e.g. using the HTTP Moodle link or accessing the file with DAVRoot: view or save will get that content from Moodle and Moodle will move it from the trashdir into the filedir.
Unfortunately Files API doesn't provide any direct access to the Moodle trash bin so DAVRoot is not currently able to present you a file/folder just deleted in a separate folder like the Windows trash bin.
BTW I'll look deeper if there will be some "easy" hack to overcome these limits in this interesting scenario.
Matteo
Hi Matteo and Rosario,
You may also be interested in the patch attached to http://tracker.moodle.org/browse/MDL-31645
This patch provides and the tracker issue suggests a configurable trash time so that when a file is removed in the user interface, it hangs around for the configured time before actually being removed from disk.
This is different to setting
If you like the idea of the feature and think that you would use it, please vote for it!
Andrew
You may also be interested in the patch attached to http://tracker.moodle.org/browse/MDL-31645
This patch provides and the tracker issue suggests a configurable trash time so that when a file is removed in the user interface, it hangs around for the configured time before actually being removed from disk.
This is different to setting
$CFG->filelastcleanup = time(); as files are eventually removed, but in a more controlled fashion.If you like the idea of the feature and think that you would use it, please vote for it!
Andrew
This is sort of good news and I will vote for it. But why did I feel a lot much better, when I was able to see every single file of a course neatly stored in its course-directory??
As I wrote elsewhere, I never had a total crash/loss of the server, so I never had to go back to restore the database and the Moodle data-dir. But I have a lot of incidents where teachers lose some files or mess up their courses with bad HTML they copy from Word or other editors.
In those daily little cases I can not revert the database and the whole Moodle data-dir to its previous state. That's where restoring sigle files from tape to its course-dir came in handy and where I could even retrieve a whole backup-zip-file from tape to restore the whole course or parts of it into a new Moodle course.
In Moodle 2.x I will have to rearrange my backup strategy and my restore service to something completely new.
So the idea to restore things from trashdir is surely a good idea if you can set the trash-retension-time to 6 or 12 months.
So where do the backup-zip files get stored if you enable legacy course files in Moodle 2.x? Still hashed somewhere?
And what happens if you type in a server-directory where to store all of the backup-zip-files? I guess the directory will keep the name you gave it. But what happens to the backup-zip-file-names? Is it possible to identify them with its course-fullname or course-shortname?
I can see the trashdir on my server. But how would you recover such a file in the Moodle GUI? Using the filepicker when uploading a file?
Rosario
Matteo, I had a look into the Create WebDav Repo. It seems you have to specify a webDav-Server, so I guess this would be my IIS-Web-Server, if it were capable to expose our Windows-File-Shares.
I think even if this would work, it would be my last resort.
But I am asking myself now, whether we could not go the other way round:
- declare/create as many file areas as needed by every teacher or team of teachers ON THE MOODLE-Server
- every teacher or team of teachers could connect through their WebDav-Client, eg. their windows-explorer or Finder/File-browser, etc. to this file area
This would be an easier access, no other Web-Dav-Servers to set up and maintain.
What do you think about this? Rosario
Ciao Rosario,
I never played with WebDAV repos in Moodle: DAVRoot has been coded to understand Moodle Files API and for debugging purposes rather than to replace that type of repo and that's the scope of my experience with WebDAV in Moodle.
That being said, yes, it sounds quite correct but your teachers will be ALWAYS required to use the repo to "add" a resource in Moodle and yes they do not require to use a WebDAV client to populate their WebDAV-exposed folders, they could use an UNC path or a local unit mapping if they are used to work within the LAN.
You can also use the file repo and give each teacher a "private space" in a file system which seems simpler than keeping care of WebDAV configurations, IF your teachers will always work at office.
Note: when using a WebDAV repo, take also care of MDL-22663.
HTH,
Matteo
Thanks Matteo. Anne Krijger explained such a scenario with file repos:
http://moodle.org/mod/forum/discuss.php?d=196713
and it sounds good. But see there my problems if I were to samba-mount the windows-shares. This would be on a rather static basis and not user-permissions/credentials driven.
Rosario
Ciao Rosario,
oopps I forgot that thread . Need more than a bit of time to focus on your scenario, which is actually interesting.
In the meantime take a look at http://moodle.org/mod/data/view.php?d=13&rid=991:
- http://www.citricity.com/moodlegpl/windowssharewebclient/
- http://www.citricity.com/moodlegpl/ldapcapture/
Those links seem not to address your scenario but to kindly suggest that among the Moodle repos a SMB/CIFS one could be a nice-to-have, at least to avoid the extra load of setting up a WebDAV server to present Moodle a set of Windows shares.
HTH,
Matteo