Download link does not display on Node or in Views

Does it work if the CCK Field Permissions module is turned off?

I can affirm this problem! I am not using cck Perm!

Ok, thanks for the input. Seems I'll have to take a closer look at this problem.

Ok, I installed filefield from scratch on a new installation, and I came to the conclusion that you need to check the "List" checkbox in front of the file to get it to show up. Additionally, filefield 5.x-2.x has a new "view filefield uploads" permission that you should enable for all roles that can access filefield uploads - but as there was a small bug in 5.x-2.0 (it showed up even without that permission) this shouldn't have been the cause of your problem.

In any case, please get the newly created bugfix release 5.x-2.1 and make sure three facts are true for your files:
1. The "view filefield permission" is enabled for the current role.
2. The display settings of the field (http://example.com/admin/content/types/[contenttype]/display) is set to "Default".
3. Each file that you want to view has "List" turned on.

If you still can't see your files after that, then we have a bug. I'd probably need more detailed reproducement guidelines or a database dump of yours in order to make it work.

Marking fixed for now, please reopen the issue if the problem persists.

Is there any way to programatically turn the "list" setting on for each file in the system?

I've got a ton of files on my site, and it'll take me days to click through each individually. I poked through the database, and I can't figure out where this setting is stored. Point me in the right direction, and I can probably figure it out.

Aside from the panic calls from my users ... nice feature!

It seems that when the "List" field is hidden, it would perhaps make sense to display files regardless of their current "List" status (which they could have kept from "Show List" times). That is currently not the case, as hiding the list fields only auto-checks the "List" values but doesn't enable those that have kept their status from before. So, I think I'll change filefield to always display files when "List" is hidden. Would that make sense for all cases? Feedback?

Or do you (tsteingard) want to say that even when a new file is uploaded, disabling "Show List" does not work? One more explanation please, I should be able to fix this afterwards.

jshuster: as with any other CCK-managed field, the values can be found (and modified) in the {content_field_[name]} or {content_type_[name]} tables, depending on how the field was set up. If your filefield is named "file", then the column is named "field_file_list". Also, when you modify stuff like this through the database, clearing the content cache is always a good idea. However, please open up a separate support issue next time, as your inquiry doesn't have much to do with the originally reported problem.

Oh right, and the issue doesn't seem to be "critical" anymore.

jpetso: thanks for the info! I found the field, but the content cache was the missing bit of information. I know what to do now, and I'll open a new issue if I run into any other trouble.

With regard to your question about the field's "show list" setting: my sense is that the default behavior should be to show the file. That's on the basis that if someone uploaded a file, they did so because some other user needs access to the file. Thus, I'd recommend implementing the "show list" setting as follows:

• if "show list" is unchecked, the field should always show the files (as you described in the help text).
• if "show list" is checked, each file's "list" setting should be checked by default (so the file is shown).
• if "show list" is checked, and the user unchecks the "list" setting, then the file is hidden.

If your user base needs control over the default behavior if "show list" is checked, you could add a second parameter to specify this. There is some precedence in other modules (e.g., OG) along these lines. For me, though, defaulting on the side of displaying the file suits my needs.

I hope that helps -- and again, thanks for the fast reply.

Thanks for the reply. Of course, you're right that the file should be shown by default - the issue with your second point is that the Form API (at least in Drupal 5, need to check the D6 version) can't be told to show "List" in a clean way, and needs a hack to circumvent this. Which is quite low-level, and I'm not exactly comfortable applying this. So, hopefully it's going to get better with Drupal 6's Form API.

Implementing the first point should be very feasible though, and of course the third is already the case.

Yeah baby! "Hide" instead of "List" is a great idea in my opinion - thanks a lot for thinking outside the box! I could imagine that is a much more understandable terminology and a considerable usability improvement. (In addition to removing technical difficulties with "List" checkbox, that is.) I'm quite tempted to go with this idea.

From the technical side this is a no-brainer, except for the upgrade path which does need a bit of work. As this is clearly out of scope for this bug report, I created a new issue for this. Please leave your comments regarding this idea there.

Ok, I solved the problem with a quick fix in commit 84369 (should soon be in the current 5.x-2.x-dev and HEAD snapshots): Files are now always shown if "List" is hidden.

I called it a quick fix because I'm not so sure about the caption of the 'Show "List button' option - I imagine 'Always show files' would make for a better description. (I'm also not so sure if "Hide" is such a good idea - maybe "List" is simply the wrong term when it should be called "Show"? Anyways, that's the other issue.)

Please grab your -dev release - I want to fix one or two other things before releasing a the 5.x-2.3.

Gnrr. Sorry. Can't be all too difficult, I'll be fixing this soon.

> Can't be all too difficult, (...)

Guess who's wrong again! It doesn't work in Views because 'show_list' is a widget setting, and as such can be different for the same field in different content types. What's more important, Views doesn't let us know about widget settings as they're supposed to control only the node editing form but not the field itself. And that was ok with a 'Show "List"' option (which controlled how the field is edited) but doesn't apply to an option that controls the field itself.

In other words, the 'Show "List"' option has to go and needs to be replaced by a field setting instead of a widget setting. On a more positive note, this makes the automated upgrade easier than I had anticipated before: it simply can't be done reliably anyways because the setting might be different for the same field in different content types. So I'll just introduce the new "Always show files" setting and remove "Show List" and pop up a message on upgrading that explains to the admin how to proceed, without automatically upgrading anything. Objections?

Fixed in current CVS HEAD (and DRUPAL-5--2 a.k.a. 5.x-2.x-dev). Guess I'll have less issues if I provide a heuristic upgrade path, but that's not done yet.

Anyways, there's now an "Always list files" field setting (as opposed to widget setting, which is what "Show 'List' option" was before) and that one works fine with Views, and as an implication works the same across all instances of a field in different content types. "Show 'List' option" was dropped, upgrade path pending as stated. (Of course, you can skip the upgrade path if you just check the checkbox in each field where you want/need it.)

The code is a bit cleaner now, and the concept as well, so I'm overall quite happy with this solution. And of course, naming the option this way makes the naming of "List" vs. "Hide" an issue that is completely independent of this one.