Yes — this was helpful and worked for me. Thanks.
It’s not working for me. I have a custom link template that includes the [download_link] variable. No preview button for PDF downloads is appearing.
Great! How do you add the preview button to a link template? What is the variable?
@BGM just wondering if you can share how you setup [doc_preview]
to open in a modal rather than be inline.
As I explained earlier, while that *works* — it’s not intuitive for end users. If I create a package and assign it to a category, I will expect the permissions selected for that category to control access. I would not expect needing to also *clear out* the allow access value on a per-package basis.
The Allow Access field basically overrides the category access. Normally you don’t default to an override value. So what I’m suggesting is to create a new default value for Allow Access called “inherit permissions” — or something like that — which inherits from the category by default, and then lets you override it if desired on a per-package basis.
We are using the Pro version. Though we recently upgraded and the behavior was present in the Free version as well.
The download link was present and could be clicked to download the file. If I remove the “all visitors” access, then it appears to inherit from the category as expected. Which is why, as explained earlier, I think the underlying restriction is working. The problem is that you need a different default option for the access field so that it inherits from the category by default, rather than requiring people to click and undo the default access selection in order for the category restriction to kick in.
I did some testing and it’s definitely improved, but I think there is still the potential for confusion. Here’s what I found.
* created a category and restricted to a role
* created a file and selected the category
* created a page with a block showing all files
If I view the page as an unauthenticated user, the file is visible and downloadable.
If I go back into the file, locate the “Allow Access” field under Package Settings and remove the “All Visitors” selection (which is selected by default), then things work as expected. When viewing as an unauthenticated user, the file is not downloadable. When viewing as a user with the role selected in the category settings, the file is downloadable.
So from a pure functionality standpoint, this seems to be fixed. However — the fact that “All Visitors” is selected by default AND it overrules the category permission, is problematic. I suggest having a new option under Allow Access called “Inherit from Category” and set that as the default value. That accomplishes a few things:
* allows the category permissions to be the default access control for files
* if no category is selected, we can assume “All Visitors”
* allows you to overrule the category permission on a per-package basis, which is useful
My concern with the current setup is that people will select the category and not realize they need to undo the default value in the Allow Access field in order for the expected perms to kick in.
No — there’s no apparent impact on functionality, which is why it’s odd. I’m able to upload and download files without issue. But the error in the error log persists, which is a cause for concern.
I can’t give you access to the site. But it wouldn’t matter anyway. You only see it when tailing the error logs.
I updated the Gutenberg plugin and the issue persists.
Here’s the link to the screenshot (didn’t show up earlier): https://lcdservices.tinytake.com/tt/NDM1NzcwOV8xMzc0MzczMQ
I can’t give you access to the site, but here’s a screenshot of the page and block config.
The block should filter and display downloads with the member-resources category. The first document listed does not have that category assigned (the second does).
I ran into this as well. Let us know when there is an update.