Media/Files Code Sprint in Portland, Oregon

i'd been tossing those dates around for a bit but i'm not married to them. my only concern would be that moving it to the next weekend might be bad for other people...

This is Angie Byron's response to the write up above, posted with her permission. There were at least three people at the meeting struggling with file management who might find this useful.

Unfortunately, file management is an area of Drupal that is (and has been historically) in need of a bit of TLC. And it shows, since by browsing through the list of file management modules @ http://drupal.org/project/Modules/category/62, there are several examples of people saying "Screw this. I can write a better file management API. Use $module instead!" Asset, WebFM, Disk Node, etc. are all examples of this.

The danger, of course, is that these "other" file management systems are:
a) wildly inconsistent in what they offer
b) wildly inconsistent in how they solve various problems
c) independent development "silos", separate from core, and dependent on the maintainers of those systems sticking around.

Drupal core's upload.module is the only one guaranteed to be updated through the ages, with CCK's file field a close second, since it's essentially "as core as you can be without being core." Venturing outside of these two paths is dangerous, but some kind of "module soup" (plus a healthy dose of new/custom development) will almost certainly be required to fulfill all of the requirements you have laid out here.

So what I'd strongly suggest first and foremost is prioritizing these requirements, and figuring out:

a) What is the bare minimum that needs to be rolled out with this upgrade in order to keep all of the various stakeholders from killing each other?

b) How much of the proposed functionality do they think they want vs. actually need? And is it possible, politically, to get them to back off on the optional stuff, in the interest of easier future maintenance of the site?

Now, with that out of the way... ;) Let's go through your requirements list of "file-related thingies."

Bulk file uploads:
- While there are various solutions around for bulk-uploading images, unfortunately none of these solutions look to be generalized for files. You can make a multi-value file upload field in CCK, but it's clunky, and in Drupal 5 you get 3 of those and that's it. :\
- There are "Allow multiple uploads" feature requests for just about every utility module imaginable. They're all active. :P

Automatic file renaming:
No existing solution for this that I could find. http://drupal.org/project/uploadpath could be something to build from, though. It uses the "Token" module, same as Pathauto, and lets you specify a pattern for what subdirectory a file should be uploaded to. For example:

[type]/[user-name]

Would upload forms to:

files/upload_file/admin/form-name.pdf
files/upload_file/bob/some-other-form.pdf

and so on.

Two issues:
1. It doesn't touch renaming the files themselves, only controlling which sub-directory they're uploaded to. This would actually make your duplicate form problem worse, because instead of them being _0 or _1, they'd now be files/forms/something/something/duplicate-name.pdf
2. It seems to be suffering from "overloaded-module-maintainer-itis" (Larry's a great guy, but he has his finger in one too many pies ;)).

Finely-grained file access:
Hoooo boy. ;)

So Drupal core offers an "all or nothing" private/public file solution. Your files are either public (in which case Apache serves all files just as it would normal .css files or whatever) or private (in which case Drupal serves them itself, which allows it to do permissions checking).

Naturally, lots of people thought that was dumb, and implemented their own workarounds. There's http://drupal.org/project/private_upload which lets you control a "Private" checkbox on a per-file basis, using core's upload.module. On the CCK side of things, CCK Field Permissions would let you set create/edit & delete/view access on those file fields that are part of the primary/secondary file types. This wouldn't affect the underlying file, however.

With private files, access is determined based on access to the node to which the file is attached, so when using a node_access module like Taxonomy Access Control, you have the ability to control who can view files to the same level of control that you have to control who can view the nodes.

Private files only control viewing of the files, however. If you can edit the node, you can edit the files attached to them as well. Further, Drupal's permission system is also role-focused, rather than user-focused, so implementing "Mary can view Susan's files but can't upload them" isn't really something that Drupal could deal real well without blowing up your already gigantic roles page even more. :\

This might be something you could handle with Unix system-level file permissions, if you had some smart scripts on the back-end. Nothing that I'm aware of in Drupal can handle this currently, however.

Consistent UI
*I'm still searching for some kind of 'magic bullet' here, but something that *might be worth looking at, both from a bulk-file-upload standpoint as well as a "unified user experience" standpoint, is SWFUpload: http://demo.swfupload.org/ which provides a Flash/JS-powered local file browser that looks exactly like your OS file browser, but allows multiple file uploads via AJAX (you have to ctrl+click them though; not sure what kind of learning curve that would represent for your users). There's a module for it at http://drupal.org/project/swfupload, but it doesn't seem to work overly well, or that is to say "at all." :\ It's also specific to core upload module, although it might not be terribly hard to create a patch to make this work for CCK File fields and IMCE too.

*File link breakage notification
*That is indeed a cool feature, and I'm not aware of any other modules that offer it. :\ I do know that in my test environment, Disknode completely forgot about the file I pointed it to between saving and re-editing the node, so I'm wondering how critical this feature is. :P

since you're the only one i know of that's coming to town specifically for this, i bumped the dates to jive with the dates you'll be here. i'll see you tomorrow.