Whenever a user uploads a display picture, a folder is created:
moodledata/users/(id#)
Also, whenever a user uploads an assignment, a folder is created:
moodledata/.../moddata/assignment/(id#)
I need the folder to be created as such:
moodledata/users/(username)
and
moodledata/.../moddata/assignment/(username)
Any idea where I should start looking? Any help would be appreciated, thank you!
Why do you want to do this? I would avoid doing it, because it's kind of part of Moodle "architecture", so to speak, so it'll be fiddly to fix all the various bits of code that refer to it. Besides which, the user id number doesn't change for a user, while the username can be changed, which is a good reason not to depend on it.
I'd recommend that whatever you're intending to do, you do it by looking up the numeric user ID in the database and using that. If possible.
I'd recommend that whatever you're intending to do, you do it by looking up the numeric user ID in the database and using that. If possible.
... or use a script to create symbolic links to the numbered directories. That way, Moodle can keep using idnumbers to lookup directories for a user, while you can use the more human readable versions to locate things in the filesystem (if that's what you want to do). Like Dan said, changing the way Moodle stores files, is going to cause you all kinds of problems afterwards.
Hi Dan, thanks for replying.
I need to do this because the people who I'm customizing Moodle for want it this way. They say that when an admin or a teacher is browsing the folders and wants to quickly locate a certain assignment for a student, the admin or teacher would have a much easier time locating the student's folder if it was renamed to the username instead of the user id.
I was able to make Moodle create the folders with the student's username instead of the user id, but like you mention, any reference back to it through Moodle is now broken.
... Any ideas of how to stasify their specifications??
I need to do this because the people who I'm customizing Moodle for want it this way. They say that when an admin or a teacher is browsing the folders and wants to quickly locate a certain assignment for a student, the admin or teacher would have a much easier time locating the student's folder if it was renamed to the username instead of the user id.
I was able to make Moodle create the folders with the student's username instead of the user id, but like you mention, any reference back to it through Moodle is now broken.
... Any ideas of how to stasify their specifications??
I have some idea how to do this, because I did it for the assignment module.
As for it being a bad idea, well, if the entire user base wants a usable interface, then I think it's probably an idea that warrants some merit, and it's difficult to conceive of a method of making end users remembering the numeric IDs for assignments and users.
There are two ways to implement this: one, which might be better than my way, is to keep using numeric IDs for the *real* names (ie, the folder names *on disk* would be numeric) and just have this fact hidden by the interface.
What I did was a little different, but probably useful to you. You can find the whole solution and the (very small) code change here --> http://tracker.moodle.org/browse/MDL-6564
Also, if anyone uses that code, please comment on the feature improvement to add a 'me too' vote so that the moodle devs will add this functionality in some way shape or form or another. I'm not saying my way is right, but this feature *NEEDS* to be there in order for the "files" interface to be remotely usable by end users, which I believe is the point
brian.
As for it being a bad idea, well, if the entire user base wants a usable interface, then I think it's probably an idea that warrants some merit, and it's difficult to conceive of a method of making end users remembering the numeric IDs for assignments and users.
There are two ways to implement this: one, which might be better than my way, is to keep using numeric IDs for the *real* names (ie, the folder names *on disk* would be numeric) and just have this fact hidden by the interface.
What I did was a little different, but probably useful to you. You can find the whole solution and the (very small) code change here --> http://tracker.moodle.org/browse/MDL-6564
Also, if anyone uses that code, please comment on the feature improvement to add a 'me too' vote so that the moodle devs will add this functionality in some way shape or form or another. I'm not saying my way is right, but this feature *NEEDS* to be there in order for the "files" interface to be remotely usable by end users, which I believe is the point
brian.
Hi,
I tried your code, but here's what happens when a user tries to upload an assignment:
Warning: mkdir() [function.mkdir]: No such file or directory in C:\AppServ\www\new-moodle-162\moodle1.6.2\lib\setuplib.php on line 69
and
ERROR: Could not find or create a directory (C:\AppServ\www\new-moodle-162/moodledata-1.6/1/moddata/assignment/5y /ahmed_test)
5y is the assignment name and ahmed_test is the user's username...
I tried your code, but here's what happens when a user tries to upload an assignment:
Warning: mkdir() [function.mkdir]: No such file or directory in C:\AppServ\www\new-moodle-162\moodle1.6.2\lib\setuplib.php on line 69
and
ERROR: Could not find or create a directory (C:\AppServ\www\new-moodle-162/moodledata-1.6/1/moddata/assignment/5y /ahmed_test)
5y is the assignment name and ahmed_test is the user's username...
this feature NEEDS to be there in order for the "files" interface to be remotely usable by end users, which I believe is the point
I don't think we want end users browsing directly inside the moddata subdirectories. They should be able to view/rate/downlad/change files stored by a module through the userinterface provided by the module itself.
If somehow endusers find using that interface more difficult than directly looking up files in directories, than I believe the user interface for that module should change, not the "files" interface.
I totally agree with this sentiment.
I think it would be a disaster if we had the Moodle community dependent on accessing moddata in this way. The *only* way to access moodle's data ought to be either via the Moodle application or via some exposed API.
If for instance the development team decided to implement Moodle SharePoint-style with all files being stored in the database it should be free to do so... without stacks of institutions having issues.
This would suggest to me that we indeed either need a simpler way for users to browse and download module files via Moodle (particularly uploaded Assignment files - it is a MAJOR headache if you've a lot to read and review)... or perhaps we need a range of options made available via different interfaces (e.g. WebDAV, sFTP...?)
Coincidentally - Ahmed that's an ugly path. Try using the PHP constant "DIRECTORY_SEPARATOR" instead of just assuming that a forward slash (/) will be OK - PHP should translate that better for each platform.
MC
I think it would be a disaster if we had the Moodle community dependent on accessing moddata in this way. The *only* way to access moodle's data ought to be either via the Moodle application or via some exposed API.
If for instance the development team decided to implement Moodle SharePoint-style with all files being stored in the database it should be free to do so... without stacks of institutions having issues.
This would suggest to me that we indeed either need a simpler way for users to browse and download module files via Moodle (particularly uploaded Assignment files - it is a MAJOR headache if you've a lot to read and review)... or perhaps we need a range of options made available via different interfaces (e.g. WebDAV, sFTP...?)
Coincidentally - Ahmed that's an ugly path. Try using the PHP constant "DIRECTORY_SEPARATOR" instead of just assuming that a forward slash (/) will be OK - PHP should translate that better for each platform.
MC
First, my apologies, ahmed: my code uses forward slashes, as you'll note. My systems are all unix, and I don't have a windows server to test with. I'll look into what I can do with my code to make it more universally useful.
Second, Myles - you bring up some good points. If moodle went all sharepoint on me, I'd expect that they'd keep some notion of a files interface anyway. I'm not sure I would be able to use Moodle if all files (including uploaded assignments) were in the database, because I work for a Comp Sci dept that uses a module I wrote to allow users to upload multiple files, and then, if all of the files required by the assignment are uploaded, they can run a script against the file at the press of a button to make sure their assignment compiles cleanly on the server after the upload. If it doesn't compile cleanly, professors will likely want to see the user's code to see what went wrong (in some cases).
My burning question in light of the comments made here is "What exactly is the purpose of the "Files" interface?". If we aren't supposed to use it to store and retrieve files, why does it exist at all? If it's only supposed to be used for internal moodle operations, why is it exposed to the user via the interface at all? It was never my intention to misuse "Files" - it just seemed intuitive to use it this way, and there are lots of api functions to facilitate this kind of use.
Also, I disagree with the idea that every module create its own file browsing interface. This would become extremely confusing for end users at sites where a few different modules are used, because they'd have to figure out how to see the files for each different module. Further, one of the nice things about Moodle right now is the ability to reuse an enormous amount of code, almost to the point where you're rarely using built-in php functions. You're using mostly moodle api functions. Having to reinvent the wheel every time someone writes a module would be bad, methinks. There's little benefit to being modular if you can't build upon existing modules.
My $.02
brian.
Second, Myles - you bring up some good points. If moodle went all sharepoint on me, I'd expect that they'd keep some notion of a files interface anyway. I'm not sure I would be able to use Moodle if all files (including uploaded assignments) were in the database, because I work for a Comp Sci dept that uses a module I wrote to allow users to upload multiple files, and then, if all of the files required by the assignment are uploaded, they can run a script against the file at the press of a button to make sure their assignment compiles cleanly on the server after the upload. If it doesn't compile cleanly, professors will likely want to see the user's code to see what went wrong (in some cases).
My burning question in light of the comments made here is "What exactly is the purpose of the "Files" interface?". If we aren't supposed to use it to store and retrieve files, why does it exist at all? If it's only supposed to be used for internal moodle operations, why is it exposed to the user via the interface at all? It was never my intention to misuse "Files" - it just seemed intuitive to use it this way, and there are lots of api functions to facilitate this kind of use.
Also, I disagree with the idea that every module create its own file browsing interface. This would become extremely confusing for end users at sites where a few different modules are used, because they'd have to figure out how to see the files for each different module. Further, one of the nice things about Moodle right now is the ability to reuse an enormous amount of code, almost to the point where you're rarely using built-in php functions. You're using mostly moodle api functions. Having to reinvent the wheel every time someone writes a module would be bad, methinks. There's little benefit to being modular if you can't build upon existing modules.
My $.02
brian.
Brian > "What exactly is the purpose of the "Files" interface?". If we aren't
supposed to use it to store and retrieve files, why does it exist at
all?
In Moodle, each course has a Files repository associated with it (within moodledata) where a teacher (not students) can store course files and retrieve them from. Does that answer your question?
Joseph
Hi Joseph - I understood that it was the case that students were not to be allowed to even see the "Files" link. I think that's right, and I have no problem with that.
Maybe I can explain graphically what my uploadmulti module does, from a student's perspective. I think there are uses of the Files functionality that may be... underappreciated?
Background: a prof creates an assignment of type uploadmulti, where he specifies the number of required files, and the names of the required files, and sets other options like whether to allow files not specified by the professor to be uploaded, the file upload max size, and the default options that go with most assignment types.
The student then clicks to see the view of that assignment. Here's a shot of what he sees:
In that shot, the student has one file uploaded. Note that the "Run Script" button isn't enabled. If he submits all the files that are non-optional, *and* the professor has created a 'bin' directory for this assignment with a script in it, then the Run Script button will be enabled, which will call the profs script passing the user's assignment directory as the sole argument.
The student can then see the output of the script, and be ensured that the code he tested on his local machine actually compiles on the server as well.
I've hacked up a bogus run script and files. The run script here just spits out the contents of the file.
Note that the student is never able to browse the Files interface or do anything with any files except for his own uploaded assignment files, which he's allowed to unsubmit.
There's the enabled run script... and...
I wanted to show this not because what I did is so cool, but to show others that there are uses of the Files interface they may not have thought of yet, which justifies its existence.
Thanks for reading.
brian.
Maybe I can explain graphically what my uploadmulti module does, from a student's perspective. I think there are uses of the Files functionality that may be... underappreciated?
Background: a prof creates an assignment of type uploadmulti, where he specifies the number of required files, and the names of the required files, and sets other options like whether to allow files not specified by the professor to be uploaded, the file upload max size, and the default options that go with most assignment types.
The student then clicks to see the view of that assignment. Here's a shot of what he sees:
In that shot, the student has one file uploaded. Note that the "Run Script" button isn't enabled. If he submits all the files that are non-optional, *and* the professor has created a 'bin' directory for this assignment with a script in it, then the Run Script button will be enabled, which will call the profs script passing the user's assignment directory as the sole argument.
The student can then see the output of the script, and be ensured that the code he tested on his local machine actually compiles on the server as well.
I've hacked up a bogus run script and files. The run script here just spits out the contents of the file.
Note that the student is never able to browse the Files interface or do anything with any files except for his own uploaded assignment files, which he's allowed to unsubmit.
There's the enabled run script... and...
I wanted to show this not because what I did is so cool, but to show others that there are uses of the Files interface they may not have thought of yet, which justifies its existence.
Thanks for reading.
brian.