file ownership per user/role

Is there any way to simply the following process? I and II will need to be done for each new role (customer) you create. This is the most cumbersome part. III needs to be done for each user.

I. Create a role and taxonomy corresponding to a corporate customer, and
limit access to that taxonomy to the corresponding role:

1. Add a "Customer3" role ("Customer3" is just an example. Use
something relevant)
(administer->access controls->roles->Add role)
2. Add a "Customer3" term under the "Upload for" vocabulary
(administer->categories->add term)
3. Give the "Customer3" role full access to the "Customer3" term by
checking the corresponding View, Update, Delete, Create, and List
check boxes.
(administer->access control->category permissions->edit)

II. Create a content type per role (this for uploading files).

1. administer->content->content types->add content type
2. Give it a "Content type name:", such as "Customer3 Upload"
This is the only required field. Click on the Submit button.
3. In the content type list view, find the newly created content type
and click on "add file".
Give it a descriptive "Field label:" such as "File to upload".
Check the "Required field" checkbox.
Click on the Submit button.
You should now have a new content type that has a Title and File to
Upload attribute.
4. Now configure the default behavior of this content type:
administer->content->configure->content types->configure
Under default options, make sure "Published" and "Create new
revision" is checked. Leave "Attachments" disabled.
Click on the "Save configuration" button.
5. Now you need to grant the relevant role access to this content type:
administer->access control
Under the "flexinode module", check the following 3 checkboxes
corresponding to the proper role column: "create Customer3 Upload content",
"edit own Customer3 Upload content", and "view uploaded Customer
Upload files"
6. Now you need to make the "Upload for" vocabulary show up when
the new "Customer3 Upload" content is being created.
administer->categories->edit vocabulary (Upload for)
Under "Types", make sure the new "Customer3 Upload" type is checked.
Click on the "Submit" button.
7. Add a "Customer" term under the "Upload for" vocabulary
(administer->categories->add term)

NOTE: It is important that this term and the role name
corresponding to this term match exactly (case and everything).
This is the key used in database search to dynamically generate the
contents of the downloads page.

III. Add users to the new role

1. If the user doesn't exist, create it first
administer->users->add user
Enter the username, email, and password.
2. Add user to the role
(administer->users->edit)
Check the checkbox corresponding to the appropriate new role.

For this, i use attachment.module, with filemanager (w/ private patch).
You can make a simple content type, with attachment enabled.
To this content type you can assign terms (controlled by TAC module) like 'Customer1", 2 ,3 etc... So only users with "view" permission can access the nodes (and the attachments to that node).

The only problem with that when I tried it is that I can't prevent Customer1 from seeing Customer2's files and vice versa.

Anyway, to make it short what do you want, from TAC to do?
Default category permission settings for new roles (when adding new roles)?

The taxonomy_access module does exactly what I want. Managing a bunch of roles and restricting access to those roles is a bit cumbersome, though. Whatever can be done reasonably to reduce the number of steps I listed would be great. Default category permission would be a great start.

For this, i use attachment.module, with filemanager (w/ private patch).
You can make a simple content type, with attachment enabled.
To this content type you can assign terms (controlled by TAC module) like 'Customer1", 2 ,3 etc... So only users with "view" permission can access the nodes (and the attachments to that node).

Let me clarify this. I tested with filemanager+attachment module. I did apply the private patch to filemanager (http://drupal.org/node/38116). TAC seems to be very good for protecting the node, or metadata, from unauthorized access. But, it doesn't protect the actual file. That is, if a user knows, or can guess, the url of the file attached to the node, the file can be downloaded without authorization. Otherwise, what you described would be perfect. I'd simply create a generic upload content type and protect access (node and attachment) with TAC. This is briefly discussed at http://drupal.org/node/37719#comment-69824.

What I did find, though, is if you use the "add file" attribute of a flexinode, instead of using an attachment, then the actual file is protected from unauthorized users. This is precisely, why I had to go through all those steps I listed to create a flexinode content type per role at the start of this thread.

Let me explain a couple of use cases using the flexinode "add file" attribute:

1. Let's say you have (user, role, content type, taxonomy) for each user, i.e. (User1, Role1, UploadType1, Term1) and (User2, Role2, UploadType2, Term2). Use TAC to restrict Role1 to Term1 and Role2 to Term2. The result is users in each of the roles has access to each of their own nodes and files, respectively. No user (User1, User2, or anonymous) can guess the name of the file and download it via the URL.

2. Same as above, except you use a generic content type for both roles, i.e. (User1, Role1, GenericUploadType, Term1) and (User2, Role2, GenericUploadType, Term2). Use TAC to restrict access per role. The result is users in each of the roles can only see the GenericUploadType nodes that matches content type and taxonomy term they have access to -- just as you'd expect. However, if either user can guess the filename associated with the other's node, they can download the file. Anonymous users will still get a 404 error.

It seems like if you are granted view uploaded new flexinode files permissions, you can gain access to the files, which is probably the desired behavior from flexinode. TAC prevents you from getting access to the nodes that those files are associated with, but not the files themselves. Would this be a bug or a limitation of TAC?