Configuration Options

something to disable certain sources per content type would do for now IMO. Maybe insert the settings in to the content_type main page for now?

Looks like #417122: Allow drupal_alter() on Field and Widget Settings is in CCK 6.x-2.5. Is this issue one that is required for a true 6.x-1.0 release of FileField Sources?

I tried to implement options to disable sources per widget today, but I'm not sure on the final solution. Filefield Sources adds process functions for all sources to the form element, where you don't know yet which widget you appear with (or at least I do not know how to do it).

quicksketch: How should I do this? I can imagine two solutions:
- only set filefield_sources_process and so on as callback and call the others manually from there
- unset the callbacks of disabled sources in filefield_sources_process

I'll submit a patch then.

Ok, here is a first try. If you prefer a 'checkboxes' element instead of single elements I can replace them. Not sure about the callbacks. You tell me. :)

This patch looks well written but it seems like it needs a re-roll because it seems like it only allows each source to expose a setting for whether or not it is enabled, when in fact other sources might have more options, such as the screenshot at http://drupal.org/node/454982#comment-2254194 .

I'll take a stab at this later today and see if I can help to make progress here. Perhaps each source can also define a $source_settings array that gets added underneath the checkbox for whether that source is enabled? If we end up having a lot of settings, we may want to place these settings in fieldsets. Another option is to place the more granular per-source settings in fieldsets under the list of which sources are enabled.

Actually, I take back the above feedback. We have hook_filefield_source_settings() for each enabled source to define their more granular settings, but it makes sense for filefield_sources() to store the settings for which of those sources are enabled.

I did a quick functional test of this patch and removing unchecking sources successfully removes them from the list of sources on a filefield widget.

Here's a minor re-roll of scroogie's patch that places the enabled checkbox for each source inside a fieldset, which would be the natural place for a widget to add its more granular settings.

It looks like this:

The change would be okay for me. I thought about doing that when implementing it in the first time, but decided that I'd let the sources define their fieldsets or whatever they want to do independently.
Your patch excludes the changes to the sources/ folder, though, which should make it fail when calling the settings callbacks.

You're correct, thanks. Here's a re-roll with the -R option.

So this is basically the same patch except the additional fieldset. This also fixes a (javascript) bug by the way.

quicksketch: You can choose between #5 and #10 :)

+1/subscribing. One might also consider creating some permissions so that you could, for example, keep everyone but administrators from getting an autocomplete field of all your files, which could pose a privacy/security risk in certain scenarios. That, of course, would be a separate issue, but I comment here because it's so closely related. Thanks to everyone for all the hard work on this!

Thanks for the +1.

"One might also consider creating some permissions so that you could, for example, keep everyone but administrators from getting an autocomplete field of all your files, which could pose a privacy/security risk in certain scenarios."

Files are protected by node access restrictions for their respective nodes and the private file system, so I don't think permissions on the level of the accessing field would be appropriate.

Here's an updated patch that now includes the functionality from #454982: Reference all filefield files, which I've marked as a duplicate. The two patches are interwoven and since we cannot have that feature without configuration options, and the configuration options do little when there is nothing to configure, it is appropriate to merge these two issues.

Minor re-roll removing the "is the following check sensible?" comment since I revised the check and it is now sensible ;).

These are really great extensions for Filefield Sources, thanks!

I applied the patch from #15 and it returns an error:

warning: Invalid argument supplied for foreach() in /home/web/drupal/6/website/includes/form.inc on line 1206.

Did I do something wrong?

Edit:
Actually, it seems to be returning that error only before any configuration options are saved—that is, the first time I access the field settings form. After that, no errors.

Like I said in #702866: Permissions on referenced files, I needed a way to restrict the possibility of referencing files only to those files that were uploaded by the active user. It can be useful in many situations—in my case I was trying to make FileField Sources work nicely with Domain Access, so this was very much needed.

So here is a patch that includes ezra-g's patch of #15. I didn't investigate the error I reported at #17, so that's probably still there.

The patch adds a checkbox in the file widget settings that controls whether or not users can reference all files or only those they personally uploaded. Administrators (user 1) can still reference all files. (Note: it might be even nicer to add access control, so that users with the right permissions can access all files—but it was beyond the scope of what I needed at this moment.)

I also made another change: the file-reference component was set up so that the autocomplete field matched the beginning of the file name. Since file names can be messy at times (I'm using http://drupal.org/project/filefield_paths to clean them up, but they can still be tricky), I changed the where clause in the query from f.filename LIKE '%s%%' to f.filename LIKE '%%s%%' so any part of the file name can be matched.

I tested it a bunch of times and it seems to be working.

This patch is not applying for me, can somebody please upload a zip? Thanks.

ManyNancy: the patch I posted works (or should work) against the current dev version of the module—that is you should not apply ezra-g's patch before, since it's included in mine. (I'm just trying to guess what might have gone wrong.)

Anyway, as unorthodox as it may be, here's the zip of the module, which includes both patches. I'm currently using it, so I'd say it works.

A side note (assuming quicksketch has been following the thread): it would be nice to know if the module is still being developed, and I think everyone is waiting for these patches to be tested and included in the next dev release. It would be very helpful. Thanks.

Thanks for the response, it's good to know.

And thanks for the hard work, @quicksketch. All your contributions are a gift to the community.

Is this applied ? tried the latest dev snapshot but it was the same as stable release

I'm unable to apply the patch in #25 on CVS head

sinasalek: that's because #25 is six months old and HEAD has changed many times since then.

So all it needs is a re-roll ? or it's not yet ready?

Depends on what your needs are. If you're interested in the filename match options (starts with/contains) for the autocomplete field, they're already in the official release. If you need file access restrictions, it's been established in #730578: Options for Autocomplete (restrict file list) that Views is going to be the way to go, but it's not ready yet.

@antiorario Actually i came to this issue from "reference all fields". and it seems that http://drupal.org/node/730578 can also do what i'm looking for. I'm going to give it a try

Thanks for the support :)

Sadly I couldn't apply the patch to the latest version -- actually I cannot access the dev (don't have git access on the one server I use)... thoughts?