Options for Autocomplete (restrict file list)

Just checking in to say that I still intend to look into the whole views integration, but haven't had a second to think about it so far, and probably won't for the next two or three weeks. But since it's something I really need, I'll definitely do something about it.

We also need this. So if someone doesn't beat me to it, I'll have a look at this in the coming weeks.

wow this sounds like a great idea. I just started messing with this module and it seems like a perfect solution.

Has anyone taken a look at this? dixon_? I haven't been able to do anything about it so far, but I'm back on the project where I need this, so I will look into it probably early next week. It would be more efficient if we shared any progress that has been made so far.

Another good idea would be (•) Any file uploaded through same field type.

For example say I only want to show files that were uploaded through the file field. Not an image field. But I might have a couple different file fields created.

Sorry if this doesn't make any sense its the end of the day on friday and i'm about to leave the office lol.

This is especially useful for access control. Great effort!

At the end of the day, seems to me views integration is the best course for producing a clean list of eligible Files (NOT using IMCE), but there's a correlating consideration, in my mind, with one's approach to IMCE profile setup, if you're going to have IMCE in the picture.

It's in your interest to ensure someone isn't going to use IMCE to delete/resize an image uploaded with a FileField, or pollute the given FileField's directory with files arbitrarily uploaded within IMCE. To do this, IMCE profile settings need to enforce use of a sub-directory in the files/ directory (something like files/imce or files/assets) to keep your users out of other top-level directories, where imagecache/ lives, and other directories created by your various FileField path settings.

What might work for you, if the ONLY reason you need IMCE is to accomplish this referencing cleanly, is to use a files/assets sub-directory within IMCE profile settings, disallow upload/resize/delete, and then set all of your FileField paths to use directories that fall under file/assets.

Bartclarkson, how would you make a views integration for producing a clean list of eligible files ? This is exactly what I need.
To show in a select list only the eligible files from a specific directory in files/

I've worked on Views integration, following quicksketch's suggestion (in #732450: Referenced files: access restriction by user) to mimic what nodereference.module does. So I did, and here's a patch to reference.inc. I think it's still a little rough around the edges, but it seems to be working with a simple view. I haven't had time to test it with more complex views (such as those involving Domain Access, which is what actually matters to me the most), but I will, and report back.

There are notes in the code (marked *** NOTE ***). I've also fixed a couple of minor mistakes in the documentation.

There still might be some help text that refers to nodereference (it might say "node" instead of "file" and such), especially in the widget settings page, but my goal was to deliver a patch first, then go for the details.

Enjoy!

Thanks for the comments. After submitting I did have second thoughts about the starts_with/contains issue.

About the work the patch needs, I think this was the best I could do for the time being. I'm not fond of the way I forced the view to return what I wanted, but I'm sure someone else knows how to deal with it properly.

Subscribing

Here's a new patch against HEAD. I removed comments left over from Node Reference and changed starts_with/contains back to 0/1 (with appropriate changes in function code).

It also fixes a missing argument in attach.inc, line 83 (it's not a real fix, I just replaced t() with t('') to avoid receiving an error).

I'm rerolling the patch against 1.2. Nothing has changed, except that my code is now properly indented.

Please disregard the previous patch. Now a brand-new one, where I've removed/edited more leftovers from Node Reference.

I'm here again. It seems the patch has "stopped working." It's not picking up views data and the widget settings don't save the selected view. I'll see what I did wrong and will get back with news later.

I should learn to take a break from time to time. I had simply forgotten a whole bunch of lines of code before creating the patch. Here it is again with the latest improvements, and working as expected.

Applied cleanly against 1.2. I can see the configuration but there isn't any views associated with it as you already mentioned. I used a file view i created for another purpose and it seems to works just fine.

I have a question as well, is it possible to distinguish between files uploaded via different filefields/imagefields with Views. So we can for example that reference all files from field x and field y only? (Using Relationships ?)

I receive this warning by the way when i edit a node with views assign to filefield_source or when i select file to be assigned to a filefield via auto complete
warning: Invalid argument supplied for foreach() in sites\all\modules\filefield_sources\sources\reference.inc on line 198

The views i'm using is also attached.

Good job @antiorario

I have tried the view you provided, and I don't get that error, so I'm not sure how to help. What is says is that filefield_source_reference_get_files() is not returning the expected array of files, but since I can't replicate the error I don't know why that happens. You said the view works just fine—does it return that error but still shows the list of files?

I'm attaching the test view I used for development. What it does is restrict the file list to the "Image" field (field_image) via a relationship. (Of course you must have a field named field_image for the view to work.) Using relationship is very useful because it opens the view to many more filtering options—such as node types, users, or (for those who, like me, are interested) Domain Access–related filters.

#20 patches cleanly and works well for me. Thanks!

I was looking for functionality as described in #454982: Reference all filefield files, which was marked as duplicate and should get implemented within #436174: Configuration Options, and eventually I got here.

Now when will this get committed?

Will there then be an admin accessible FileField Sources settings area?

subscribe

I would love to have the "Referenceable fields" choice as shown in this screenshot of ezra-g 's patch.

But now I already have 6.x-1.2 installed, which itself improved the "Autocomplete Reference Field" on/off switch, as shown in ezra-g's old patch, to the newer and better switch "Starts with string" or "Contains string". Hence I guess I cannot use that old patch with 6.x-1.2.

Antiorario's patch (from comment #20) which is compatible with 6.x-1.2, does not offer the option "Referenceable fields" anymore. Instead it offers a restriction method through Views. For sure the concept behind that is great and made "Referenceable fields" obsolete. But as there is no documentation, it is hard for me to understand, whereas "Referenceable fields" is easy to understand.

P.S.: Generally, a documentation for FileField Sources would be nice.

P.P.S: My practical application: I have one CCK field "Images" which is used quite universally among many of my node types (displayed as mid size ImageCache image in a side column beside the body). And I have one CCK field "Image Main", which is only used in the content type "Image", where it is displayed very prominently (large size ImageCache image above the body). And I would love to be able to use the same image files in both fields (to reduce duplicate file redudancies)!

@porg: using Views was the solution recommended by quicksketch. There will be documentation when the patch is committed.

Here's a re-roll of the patch in #20 that incorporates some coding standards corrections (spacing and tabs)
and changes the text to "The list of files that can be referenced can be based on a view but no appropriate views were found. Please create a view with the type "file."'"

and

"Choose the view that selects the files that can be referenced. Only views with type "file" are shown here.''

In order to make it more clear how to use this feature.

I think including a default view would be overkill and add to clutter in the codebase and the view listing screen. Since this feature is about optional customizability that not everyone will use, it seems appropriate to leave out.

In testing, this works great with a file view, appropriately restricting files based on the view's filters. However, if you use a filter that excludes a file, but know it's name and FID, you can type that in and it's accepted and saved to the node without validation.

Is that OK, or would that present a security issue? If we don't have validation, we should at least set expectations for admins in the config text.

Thanks ezra-g for the re-roll and the corrections. I also agree that a default view would be overkill—I imagine anyone interested in the level of customization provided by FileField Sources will also know how to build a view.

About your concerns, it doesn't sound to me like an actual security issue, more like an inconvenience. We can still think of a way to perform further validation.

Thanks for this patch. It's working for me and just what I needed. :)

Michelle

Considering the lack of response from quicksketch, I've decided to take this matter into my own hands, and create a module that extends FileField Sources (using the provided API) and makes it unnecessary to commit this patch. It doesn't make reference.inc obsolete, it just enhances its options (reference.inc is actually still necessary for the basic Autocomplete checkbox to appear in the FileField widget).

Here's FileField Sources Reference Options: http://drupal.org/project/filefield_sources_reference_opt (I know, long project name—I don't like it either.) A dev release should be available later.

I've tested it, and I'd say if you remove the patched version of FileField Sources, replace it with 1.2 and enable this module, everything should get picked up with no problem. Please test it on a non-production site first.