PDA

View Full Version : Suggestions for Improvements to DigiDelivery


simonknee
06-20-2007, 07:54 AM
Firstly note that I havn't searched this forum before posting and I haven't tried the latest server software. (actually I just checked and I am on 2.1.2) However I have administered our Digidelivery GT for several months and would like to see the following improvements.

1. Accounts should allow multiple recipient email addresses (e.g. operate like an email group or have a primary and a list of secondaries)

2. Further to 1. the extra email addresses should have an option to be "notify only". These addresses do not get the download link in their emails. They should also be able to get "history reports" at fixed intervals.

3. Relay should only make a single transfer if there are multiple recipients on the same (remote) server.

4. Admins should be able to resend the "delivery posted" email to the original recipient from the server pages.

5. History pages to be filterable by any column as well as Date.

6. Admins allowed to change all passwords without knowing old one or give users "forgot password" option.

Notes and Explainations.

The above has come to light because in the real world users are sending to multiple recipients for:
a. safety (more than one recipient gets the link)
b. administration (recipient 1 is supposed to download but recipient 2,3,4 all want to keep an eye on him/her).
However in doing this we end up with:
a. Messy histories with many deliveries left pending (frustrating the billing process)
b. Multiple, redundant, downloads impacting bandwidth
c. Multiple relays, impacting bandwidth
d. If used properly (i.e. one recipient) lost/inaccessible/eaten emails so lengthy reposting only option.
e. Heavy, error prone, editing in excel to get usable bill for client.

Awaiting your thoughts with interest...

Simon
IT Manager
AIR Studios
London
http://www.airstudios.com

PS It's a brilliant technology that is so simple it confuses the hell out of our users. I have to tell them to think less and just trust it, especially when it comes to relay.

sleadley
06-23-2007, 04:45 PM
Firstly note that I havn't searched this forum before posting and I haven't tried the latest server software. (actually I just checked and I am on 2.1.2) However I have administered our Digidelivery GT for several months and would like to see the following improvements.

1. Accounts should allow multiple recipient email addresses (e.g. operate like an email group or have a primary and a list of secondaries)

2. Further to 1. the extra email addresses should have an option to be "notify only". These addresses do not get the download link in their emails. They should also be able to get "history reports" at fixed intervals.

3. Relay should only make a single transfer if there are multiple recipients on the same (remote) server.

4. Admins should be able to resend the "delivery posted" email to the original recipient from the server pages.

5. History pages to be filterable by any column as well as Date.

6. Admins allowed to change all passwords without knowing old one or give users "forgot password" option.

Notes and Explainations.

The above has come to light because in the real world users are sending to multiple recipients for:
a. safety (more than one recipient gets the link)
b. administration (recipient 1 is supposed to download but recipient 2,3,4 all want to keep an eye on him/her).
However in doing this we end up with:
a. Messy histories with many deliveries left pending (frustrating the billing process)
b. Multiple, redundant, downloads impacting bandwidth
c. Multiple relays, impacting bandwidth
d. If used properly (i.e. one recipient) lost/inaccessible/eaten emails so lengthy reposting only option.
e. Heavy, error prone, editing in excel to get usable bill for client.

Awaiting your thoughts with interest...

Simon
IT Manager
AIR Studios
London
http://www.airstudios.com

PS It's a brilliant technology that is so simple it confuses the hell out of our users. I have to tell them to think less and just trust it, especially when it comes to relay.



Dear Simon,
I agree with you. Having done some very large transfers to a number of People in LA over the last few months I would endorse all of your suggestions. The Group account is certainly a good one.
I also think that the password reset is essential. The only option currently is to remove the user and re-create.
The resending of the initial link is also a very useful idea. I have had several situations where the receiving party has trashed the origianl email (because the mail app thought it was spam) and we had to delete the delivery and re-send.
Hope all is well in the Old Dart.
my 2c
Simon Leadley

Gordon Lyon
06-28-2007, 06:40 PM
1. Accounts should allow multiple recipient email addresses (e.g. operate like an email group or have a primary and a list of secondaries)

2. Further to 1. the extra email addresses should have an option to be "notify only". These addresses do not get the download link in their emails. They should also be able to get "history reports" at fixed intervals.

3. Relay should only make a single transfer if there are multiple recipients on the same (remote) server.

4. Admins should be able to resend the "delivery posted" email to the original recipient from the server pages.

5. History pages to be filterable by any column as well as Date.

6. Admins allowed to change all passwords without knowing old one or give users "forgot password" option.



Hi Simon - apologies for the slow reply.

These are all excellent suggestions. A few notes:
- 1,2 & 6 are common requests. I'm working to get them implemented in the future.
- 3 & 5 should already work this way.
- 4 would be great, and even better would be the ability for the sender to add a recipient after the original delivery was sent. Both of these would require storing decryption keys on the server, so present a security risk. Nonetheless, we're looking into ways to accomplish this securely, since it is the #1 feature request...

Glad the box is working well for you. Send more suggestions as you think of them.

Thanks, Gordon