[development] files owned by uid, patch review request.

Darrel O'Pry dopry at thing.net
Mon May 7 19:13:12 UTC 2007


On Mon, 2007-05-07 at 13:00 +0200, Dries Buytaert wrote:
> On 07 May 2007, at 01:38, Darrel O'Pry wrote:
> > Yes there can be granular access control to files, but that is a  
> > feature
> > not included in this patch.
> 
> >
> > Groups are fun and important, but are out of scope for this change. I
> > could imaging a basic administer files permission that would create a
> > super user group. Much like administer content.
> 
> I don't think Cog is requesting that this would be part of this  
> patch.  I think he just wants to understand how this patch affects  
> feature requests like this.  As in; does this patch makes it easier  
> or more difficult to implement some of the common feature requests  
> related to file handling.

Yes I think it could be implemented, and I think it would make it
easier. While nodes did provide a convenient sort of grouping, we don't
have a group access control model in Drupal core. We use a role based
permission system currently. With the exception of organic groups.

I'm no expert on node access and admittedly barely grok it some days,
but further abstracting the existing node access system might help with
the model. I've conjectured that adding and `object type` column, where
an object could be node, comment, file, to the node access table would
give us pluggable permission for everything. I don't really knwo if its
feasible or how to head in that direction with node access. The nuances
elude me.

> What if I want the files to get deleted when the node is deleted?   
> Would they still be deleted with the proposed patch?

No. The file remains, but is disassociated from the node. There is no
way to guarantee the file is not in use elsewhere on your site, or
linked from an external site, so the file remains.

It can be modified to do so, but being able to do it sanely will require
the addition on drewish's modules column, or a hook delete for reference
counting to make sure files are not in use elsewhere.





More information about the development mailing list