I am looking for a feature and have not been able to find it, is itpossible to expire the download access as soon as 1 successful download has occurred? Thanks, Matthew Paull
Comments Philippe Lizon If available user should be able to modify this option when sending a message July 1, 2011, 17:56 Scott McMullan If done in a modular/extensible way, the implementation of this feature could create a huge win for administrators with special post-download needs. Here's what I mean: Right now, there's a process that runs after a successful download to notify the sender that the file has been downloaded. To implement this feature "quick and dirty" you could add an optional step to the post-download process that would expire the file. But imagine this instead... create a library of post-download functions (notify sender once, notify sender on every download, decrement link-expiration counter, send follow-up email to the recipient, etc) and make this library user-extendable. Then make the list of active post-download function(s) configurable system-wide by the administrator, and make settings available per-user or per-message (possibly in a later release). With an extendable framework in place, adding new and interesting post-download behaviors becomes a lot easier... especially if you define a standard way to let users provide configuration options to extensions, probably on the web interface. August 22, 2011, 23:02 Jim Schonemann I like Scott's idea to create a "post download" framework. I can think of several ways such a feature could be used. In absence of such a framework the ability to delete the files immediately once they have been successfully downloaded once is a feature we need. November 3, 2011, 00:33 Mike Alvarez This is the number one feature I hear from everyone I show this system. I think it would be very helpful to have an option to delete the file after x number of downloads. An extra check box (unchecked by default) which then allows you to set the number of downloads after which the file is no longer available (default being 1). February 20, 2013, 03:35 Johan Allard LiquidFiles Hi guys, Ok, can you please provide a bit more feedback to how you would like to see this implemented. If we assume a message for a@x.com and b@y.com with two files attached, file1.doc and file2.doc. a@x.com visits the message and downloads file1.doc but not file2.doc. Next day they visit the message page again. Can they still download file1.doc? I.e. is message expiration per file or per message? Per message would probably make more sense from a strict implementation perspective, but maybe a lot of the appeal of the function would get lost? When sending with permission "Only Specified Recpients", implementation is pretty straight forward. But for any other permission setting, we have to assume that unspecified recipients can download the files. For the setting "Anyone can download", it wouldn't make no sense at all to limit the number of times a file can be downloaded, as there would be no use penalising the users we know who they are, when the same user could logout and download the file anyway? And probably the same with "Anyone after authentication", someone who wanted to download the file again could just login as another user (with email authentication) and download the file. This leaves "Only Specified Recipients and local users", should we restrict users from downloading the files again, or should local users be able to download the files until the original expiration date? For any other permission than "Only Specified Recipients", we would have to keep the files on the system until the original expiration date. For "Only Specified Recipients", we could delete the files when the last recipient has downloaded the files. Any other details in regards to this? February 20, 2013, 15:36 Johan Allard LiquidFiles Response from Matthew (responding to the email will open a ticket, not add a comment here): I can tell you that my original request was based upon the high security route, using your assumption below I would like to see… If we assume a message for a@x.com and b@y.com with two files attached, file1.doc and file2.doc. When sending with permission "Only Specified Recipients" and selecting the option expire links after one download, a@x.com visits the message and successfully downloads file1.doc but not file2.doc. Next day a@x.com visits the message page again, a@x.com can still download file2.doc but not file1.doc as that has been completed successfully. I.E. message expiration per file and per user? b@y.com is still eligible to download both until the overall message expiration time period has expired. I hope that clarifies the intent behind my original request. February 21, 2013, 06:26 Johan Allard LiquidFiles Ok Matthew, that makes sense. And what about the different permissions? Should this apply to "Only Specified Recipients" only, or how do you see this working for other permission settings? February 21, 2013, 06:28 Mike Alvarez Hi Guys, I agree with Matthew. I also think it should apply for all permission settings the same way. It would make it intuitive, consistent, predictable and easy to understand / explain. -Mike February 21, 2013, 07:02 Johan Allard LiquidFiles Mike, It can't be the same way, becuase "can only download 1 time" would have different meanings with different permssions. Take for instance the permission that "Anyone can download". Lets say that we have a message, again to a@x.com and b@y.com, with the permission that "anyone can download" with a setting of "expire after 1 download". Now, when a user visits the page, we won't authenticate them so we don't know who they are. But lets say that a@x.com visits the page and downloads the files. Next day a@x.com visits the page again. We still don't authenticate so we don't know who they are. What happens then? Have the "expire after 1 download" kicked in? Or should "expire after 1 download" in this context mean a total number of 2 downloads, becuase there are 2 receipients. But if a@x.com downloads the file on the second day. What happens on the 3rd day when b@y.com visits the page? February 21, 2013, 08:52 Scott McMullan I'm not sure that there's a conflict between "expire after 1 download" and unauthenticated downloads. Suppose I wanted to send out something with the terms of "whoever gets this first gets it" or "only availble to the first 10 people to download" ... while it's possible for one person to mess with the results, the download server's behavior would make sense. As long as the behavior is documented and predictable, I'd say let it fly. Alternately, only implement "expire after x downloads" for authenticated downloads at first, and see how that flies. February 21, 2013, 09:30 Johan Allard LiquidFiles Response from Matthew (when you respond via email, it creates a ticket): In the case you are proposing I do not believe you can impose it unless you are enrolling everyone or tracking them based upon some other criteria. I believe it should be handled the same way in all cases that have a specific user list defined, the exception being the anonymous download case I.E. “Anyone can download”. February 21, 2013, 10:24 Mark Williams Johan, Any idea when this will be available? For my case, it would be fine if only working on the "Only Specified Recpients" option. Thanks Mark April 24, 2013, 06:47 Johan Allard LiquidFiles This feature will be available in the next major release, due out in a couple of weeks. April 24, 2013, 06:59 Johan Allard LiquidFiles Hi guys, If you're interested to testing this feature out, please open a support case and we can install a beta release for you. One thing though - you have to be willing to run a beta release on your production system. This is not available for demo/trial installations. If you're not willing to run a beta release on your production system, please hold off for a couple of weeks and there will be a release version. May 2, 2013, 11:36 Johan Allard LiquidFiles This feature was added in version 2.3. May 15, 2013, 07:24
