[development] hook_fileapi (file products and download permission)

Adam Cooper adam.j.cooper at gmail.com
Tue May 9 10:09:46 UTC 2006

I'm using the filemanager at the moment and am very happy with it.
What I particularly like is the ability to have separate namspaces for
files so that renaming doesn't confuse the users. I've not delved into
the api but I have overviewed it. It does seem more complete then the
drupal api and suits the module I'm developing down to the ground.


On 5/9/06, Robert Douglass <r.douglass at onlinehome.de> wrote:
> 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
> case.
> 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.
> cheers,
> Robert
> [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