[development] hook_fileapi (file products and download permission)

Robert Douglass r.douglass at onlinehome.de
Tue May 9 10:56:51 UTC 2006

A fileapi hook was proposed nearly 2 years ago, much along the same 
lines. It was concluded, along the way, that the place for this is in 
the file.inc file or in some centralized upload manager. I agree.

The filemanager[1] module has had the problem of access permissions 
solved for a very long time. It has a hook that lets modules impose 
their own access restrictions on downloads, and supports separate 
public/private download regions (it doesn't force you to choose between 
one or the other). Furthermore, the filemanager module only provides the 
API for uploading and downloading, not the user interface. The UI is 
provided by the attachment module [2]. Other modules (acidfree) have 
decided to use the filemanager module as their basis for dealing with 
uploads. I feel that it is close to what we want in core, and that 
building the proposed fileapi hook would be much easier if this were the 

If you're not familiar with the filemanager module, please review it. 
I'd be interested in hearing what criticisms exist. I'd be in favor of 
moving it to core.



[1] http://drupal.org/project/filemanager
[2] http://drupal.org/node/10245

Nedjo Rogers wrote:
> Dave,
> So far as I can tell, the problem you're addressing indeed exists as 
> you describe it: there is no opening in the file api to enable nuanced 
> file access control. And it should be addressed--there's no sense in 
> us having to override/replace our file api just to control access (as 
> was done, e.g., in the ecommerce file.module).
> Your suggested approach for handling access looks basically sound to 
> me--but it would be more useful to hear from more experienced 
> fileapi-ers. Walkah, killes, dopry, Chris Johnson, etc.?
> Likley we'd want to keep it as close as possible to existing _api and 
> _access hooks. So, e.g.,
> * @param $op
> *   The type of event ('upload', 'download', 'update', 'delete')
> might be better as
> * @param $op
> *   The type of event ('insert', 'view', 'update', 'delete')
> Are you thinking of doing this as a contrib module for 4.7? Part of 
> ecommerce, or a generic file handling module?

More information about the development mailing list