[ZendTo] Zendto feature requests -

Pedrosi, Derek G. pedrosi at millercanfield.com
Tue Apr 4 21:46:16 BST 2017


Ran the latest beta installer and got this...

Preparing to unpack zt ...
Unpacking zendto (4.24-1) over (4.25-4) ...
Setting up zendto (4.25-4) ...

If you are upgrading from a previous version, please make sure your
config files in /opt/zendto/config/* are all up to date.

/var/lib/dpkg/info/zendto.postinst: line 51: unexpected EOF while looking for matching `''
/var/lib/dpkg/info/zendto.postinst: line 55: syntax error: unexpected end of file
dpkg: error processing package zendto (--install):
subprocess installed post-installation script returned error exit status 2
Errors were encountered while processing:
zendto



From: zendto-bounces at zend.to [mailto:zendto-bounces at zend.to] On Behalf Of Jules
Sent: Monday, April 03, 2017 12:11 PM
To: ZendTo Users
Subject: Re: [ZendTo] Zendto feature requests -

Thomas and others,

Okay, there's a new beta out 4.25-4.

You now have a tool "upgrade_zendto_conf" to go with "upgrade_preferences_php". Hopefully you can guess what it does....

I've made significant improvements to the New Dropoff form, in line with Thomas's suggestion below.
I've also swapped the "pick up" and "request drop off" buttons in line with his suggestion below.

Please try it out and let me know what you think!

Other comments and thoughts in-line below:
On 31/03/2017 13:29, TEXIER Thomas wrote:
Hi,

I'm working as CTO in a french govt agency with 1500+ users.
We are seriously considering using Zendto to support our big files exchanges requirements.

If I may, I would suggest some features that may be interesting to include in future builds:

·         For people invited (not logged users) to pick-up or drop-off files: an option to hide information like IP address (network information), number of downloads and dates, etc.
I've checked the "showRecipsonPickup" setting. Set this to FALSE and it should do what you want. I've tested it, looks okay.
I have changed the default value to FALSE as having it TRUE by default was nuts from a security and privacy perspective.



·         For people invited (not logged users) to drop-off: an option to disable email notification when logged user pick-up the file
Why?


·         When logged users make a drop-off: an option to NOT include claimID and passcode in the email (and the link in it) and let the user give it to people by another way (sms or anything but not managed by zendto). A reminder of the base URL of the application to send to people would be nice to.
You could just untick the "Send email to recipients" box in the "New Dropoff" form. Then just send them an entirely separate email explaining how you'll contact them with the details.
Would that do? Or are you looking for a way of automatically sending them the link to the empty Pickup page?



·         When logged users make a drop-off: an option to deselect by default the "send email message to recipients" check box. This would disable the + icon to add email addresses as well.
Most people's work-around for this is to send the drop-off just to themselves. Then they can give the file's actual download link (not the link to the download page) to people. 1 click and they've got the file immediately.


·         When drop-offs are expired: the ability to display history of dropboffs, downloads, etc. even if the files itselves are not available anymore.
There is /var/zendto/zendto.log. Is this not sufficient? I'm always wary of having database tables that just grow. One of my systems (a workstation booking system) has been running for nearly 20 years; it manages it because its tables prune themselves so they cannot just grow over time.


·         When logged users make a drop-off : an option to limit the number of downloads to X times only. When reached, download is not possible anymore.
Bad idea I'm afraid. You can never guarantee a download was actually successful, despite all your best attempts to do so (and ZendTo tries quite hard in that area). And wouldn't the value of X have to vary with the number of recipients? And what happens in the cases above where the original sender has given the link to an unknown number of people?


·         In the home page for anonymous users: dropoff and pickup buttons could be swapped.
Why? Most often external users will only reach the main menu when they need to dropoff files. If they are picking up, they will have been sent a download link by ZendTo anyway, so won't start from the main menu.


·         In the logged in user home page: I think you should swap "pick-up" and "request drop off" buttons because it requires first to make a request then to pick it up.
Agreed. Done.


·         The first drop-off page where the program asks a request code is not very easy to handle for loggued in people who wants to drop off a file. This might be better to put a check box just before the next button that would show the Request Code textbox. Or maybe consider a "pure" dropoff diffently than a "dropoff" after a request to dropoff. That would avoid confusion to users.
Agreed. Done.


·         Multilingual: possibility to configure default language and others languages.

On all pages, a listbox allowing to switch between configured languages with template support.
i18n support is on my to-do list. It's a bit lower priority than Shibboleth / ADFS / SAML single sign-on support.


I understand that may be a lot of work to make all the adjustments.

I don't know if you'll take this suggestions into account; anyway, thank you for your time and work on this project; this is a very interesting and usefull application.
I would be interested in your (and anyone else's!) thoughts on my comments and questions above.

But I've done okay for today. Time for the pub!


Keep goin'! :)

NB : after upgrading our test instance from 4.20-6 to 4.24-3, it seems the email sent when dropping-off or requesting to dropoff have a problem: the email is received by people but it is empty. I rolled back to 4.20-6 and it works again. I haven't looked a lot about that issue and that might be just a problem in our config files (we used the upgrade_preferences_php utility to overwrite the previous config and did nothing more than that).
Email bug is fixed (typo in my code). Check out the "SMTPserver" setting in preferences.php, set that and it will start sending pretty HTML emails too!
And you now have an "upgrade_zendto_conf" utility to do the other half of the job!

Cheers,
Jules.



Regards,
--
Thomas TEXIER
Email: thomas.texier at anses.fr<mailto:thomas.texier at anses.fr>
Téléphone: 01 49 77 23 13

[Description : Description : anses-pt]
Agence Nationale de Sécurité Sanitaire
14 rue Pierre et Marie CURIE
94700 Maisons-Alfort
MailScanner has detected a possible fraud attempt from "www.afsset.fr" claiming to be www.anses.fr<http://www.afsset.fr/>





_______________________________________________

ZendTo mailing list

ZendTo at zend.to<mailto:ZendTo at zend.to>

http://mailman.ecs.soton.ac.uk/mailman/listinfo/zendto



Jules



--

Julian Field MEng CEng CITP MBCS MIEEE MACM





www.Zend.To<http://www.Zend.To>

Twitter: @JulesFM

PGP footprint: EE81 D763 3DB0 0BFD E1DC 7222 11F6 5947 1415 B654
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ecs.soton.ac.uk/pipermail/zendto/attachments/20170404/8d83a600/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 2806 bytes
Desc: image001.png
Url : http://mailman.ecs.soton.ac.uk/pipermail/zendto/attachments/20170404/8d83a600/attachment-0001.png 


More information about the ZendTo mailing list