I am listening. I do know that you have put a lot of work into this in the past year, I just wanted to make sure that some currently available common use cases have been taken into account. On 5/5/07, Darrel O'Pry <dopry@thing.net> wrote:
On Sat, 2007-05-05 at 06:28 +0300, Cog Rusty wrote:
I wonder what the user-file association would mean for a site which hires/fires editors and still owns/reuses their files. Or in a site like drupal.org with patches as attached files?
files won't be deleted if users are deleted. for ownership we can assume uid 1 safely if user.uid doesn't exist.
I understand that the orphaned user-files would pile up in a default user account, but if that is very likely to happen for a lot of files, then user ownership of files would seem accidental.
huh? pile up in a user account? accidental? user_access always returns true when uid=1... that isn't accidental.
I think I understand what you mean. By "accidental" I meant that if (under some common scenarios) too many files are assigned to account #1 and the user-owned files are few, then user-ownership of files would seem unimportant for basing the system on it. But I can see that account #1 can support permissions. I have one more more question (below) about whether account #1 is a good way to do that.
This patch cares very little for where files pile up when a user is deleted. Right now we don't really care what happens to files if their node gets deleted and they don't, but we also don't have any safe way of sharing files between nodes.
Perhaps files should be able to stand on their own, with options to associate then with nodes or users?
Then who can update, delete, and alter files? How do you control access to files? Drupal's permission system is user based, hence user_access.
Another questions is (a) who can update, delete, and alter orphaned files owned by user #1 (the "super-admin") and (b) whether there can be any granularity for securing files "really" owned by user #1.
I've thought about this issue a lot. I've explored it and alternatives quite a bit over the last year. It's the easiest way I've found to implement files in Drupal without depending on nodes. It should be a fairly familiar model, most filesystem systems implement user ownership of files and grant the system super user an all access pass.
In a Unix-like filesystem, the concept of "user group" permissions seems essential for access to files owned by other users or by user #1. Does the plan include anything similar? Or isn't this really essential?
The patch for changing default file relationships from nodes to users solves many issues without introducing excessive permissions related issues.
It's a relatively simple change that doesn't introduce any new tables, and only make a minor change to our existing data model.
The real point of this patch is remove all the hackage associated with file previews... Have you ever looked at the code that handles displaying file previews? Basically today, we have to save the file to the session, create a fake menu entry for the file at its final destination, and serve the file preview through drupal. It's kind of a pita, resource hog, and in makes file previews dependent on clean urls.
Search through the issue queue for file preview related bug reports.
Look at the crazy code that does file path replacement for node bodies during previews. Look at inline and how it manages to work with previews...
It was the most difficult part for me to figure out working with drupal's files. I want to eliminate that pain from every other developer's life.
As an aside this patch also centralizes validation handling from upload.module to file.inc, so we do gains centralized quota's and file extension validation as boon.
Resolving the hanging temp file issues for uploads for this patch also resolves the long standing issues with garbage collection in drupal 4.7 and 5.
The patch has been updated with feedback from unconed(steven wittens) and quicksketch(nate huang). I was able to resolve several issues with the patch. It's miles from where it was yesterday, and awaiting a fresh thrashing and some kind pgsql maven to write a pgsql update path.
.darrel.