[development] hook_fileapi (file products and download permission)

[Adam Cooper]

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.

Thanks
Adam

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?
> >
>
>