16 / 16
Apr 2012

Hi there,



I need to edit the email customer list. A few emails need to be removed, and a few changed. I also need to add a few. Is there functionality to achieve this?



...Mike

Not yet, but we will be adding it in a future update. In the meantime you can bookmark that link and access it directly.

Oh... if you change a customer's email and then you re-send their thing (their link email), it will go to the old email.

Did you reactivate and resend the download link? That doesn't refer to the mailing list but to the email given on that particular transaction--which would have been the older email.



If you use the "Send Free Download" option instead you can send it to the new address, but that feature doesn't access the mailing list either, you just get to enter what email address to send the link to manually.



The mailing list itself applies to the Updates/Newsletter service.

QUOTE: Did you reactivate and resend the download link?

Yes



QUOTE: If you use the "Send Free Download" option

I did that and asked the customer to subscribe to the mailing list.



-----------------------

Another way to go is to use serial keys... and then a software vendor can handle updates outside of e-junkie's update system. It seems like an easier way to add free users, let people download multiple files (e.g. beta versions, old versions), etc.

1 month later

So basically, there is no way to update the email address for a past client? Really?



I would suggest that this be added in an update to the admin UI, and soon. A "Free download" thing is a hack, not a solution. A solution will be to provide access to this stuff.

You can update buyer email addresses in your Buyer Group mailing lists, as stated in our first reply:



E-JunkieMonsterYou can access your mailing list through this link while logged in to your E-junkie account:

https://www.e-junkie.com/ej/view4 mailing_list.php





However, if you use the "Re-activate expired links & Re-send thank-you email" function in your Seller Admin, that just resets the attempts/hours count on the link you originally issued for their original purchase and, if you choose, re-sends a copy of the thank-you email to that original buyer email address. You can use "Send free download link" in Seller Admin to issue a fresh link to any email address you wish.



If you want to re-activate a buyer's original link, but also re-send that link to a different email than the one they used for their original purchase, you can use "Re-activate expired links" and then find their Transaction ID in your E-junkie Transaction Log. Each Transaction ID in the log is linked to the thank-you page URL for that sale, so you can just right-click on that buyer's linked Transaction ID to "Copy link location/target/address" (that last word varies among different browsers) and then paste that into a personal message to the buyer's new address.

So then, to review:



I can change an email address for a past client, which results in

1. All future updates/newsletters are sent to the new address, but

2. "Re-activate expired links" will be sent to the old address. This cannot be changed.



Is that about right?



E-junkieGuru"If you want to re-activate a buyer's original link, but also re-send that link to a different email than the one they used for their original purchase"




This is exactly what I want to do BTW.



E-junkieGuru...you can use "Re-activate expired links" and then find their Transaction ID in your E-junkie Transaction Log. Each Transaction ID in the log is linked to the thank-you page URL for that sale, so you can just right-click on that buyer's linked Transaction ID to "Copy link location/target" and then paste that into a personal message to the buyer's new address."





In other words, I have to do all that manually, outside of EJunkie. Is that right? Because the "Re-activate expired links" page only takes the transaction ID, and the transaction ID is linked to the old, seemingly permanent and wrong email address. Correct?



If so, how does all that reset the download link count and time expiry limits?



Or do you mean to do the following:



1. Get the transaction ID from the customer log

2. Paste that TID into the "Re-activate expired links"

3. Click send, and off it goes to the wrong address

4. Copy the generated link

5. Compose a new message outside of EJunkie, and paste the generated link into it



Is that what you mean?



Wouldn't it be a lot simpler to just allow the email address to be modified?



...Mike

Re-sending the link is optional when you re-activate it. Most sellers would just send a free link to the buyer's new address, but if you need to reactivate the buyer's original link for some reason, this is what you'd actually do:



- If the buyer did not provide their Transaction ID as proof of purchase:

- - Find the buyer's Transaction ID in your Transaction Log;

- - Copy the buyer's Transaction ID (and leave the log screen open).



- Go to Seller Admin > "Re-activate expired links";

- Paste in the Transaction ID you'd copied;

- UN-check the box to "Re-send email to buyer";

- Click Submit;

- Go back to your Transaction Log and find the buyer's Transaction ID;

- Right-click on that Transaction ID and "Copy link location/target/address";

- Paste that link into an email to the buyer's new address.



The transaction log is just that: a read-only record of order data we received from the payment processor for each transaction. It would be a major undertaking, and a potentially serious security risk, to make that transaction database writable/editable by our clientele, and there may be legal implications for allowing data about previous transactions to be altered after the fact. It is not intended nor really suitable as a customer contact database.



We are preparing a new version of the Seller Admin interface which will also make it easier for us to introduce new features more frequently, so we can make it a wishlist item to add some way of specifying an alternate email recipient when re-sending the email for a re-activated link.

It's read only...except I can change the email address using the links specified in the second post, you mean. So if it is a serious security risk, that ship has sailed, no?



Now then: if I change an email address using that link, by your description there will now be two email addresses associated with that purchase: the one used at time of purchase, and the newly updated one. However, only the newly updated one is actually shown.



In other words, if I change an email address, neither a record of the change, nor the old time-of-purchase address, is indicated. This could be problematic at some point, no? And isn't this the security risk...the lack of a log?



It also implies that in your DB structure there are at least two fields for the email address: one for the POS email, and another for the updated/current one. How would it be a security risk to allow the changing of one, but not the other?



The only reason I can see for this to be problematic is because paypal payments are tied to a specific email address...so if a payment is reversed in paypal, that linkage would be lost in your DB record of it. However, the only way that would occur is if the email address was changed within the 30 days allowed for a refund by paypal, and then a refund was issued. This is easily controlled by not allowing a change of email for any transaction less than 45 days though.



I'm sure that there is a lot about this that is more complicated than you care to share. I also realize -- and appreciate -- that the link you provided is an experimental/testing/undocumented page not yet ready for prime time. However I do believe that before it is rolled out for general use, some of the issue brought up in this thread are considered.



...Mike

MikeDNow then: if I change an email address using that link, by your description there will now be two email addresses associated with that purchase: the one used at time of purchase, and the newly updated one. However, only the newly updated one is actually shown.



In other words, if I change an email address, neither a record of the change, nor the old time-of-purchase address, is indicated. This could be problematic at some point, no? And isn't this the security risk...the lack of a log?





That is exactly what we are avoiding by maintaining your Buyer Group mailing lists completely separately from your Transaction Log data. Buyer emails are added to your Buyer Group list for each item they purchased at the same time we log their order data in the Transaction Log, but those records are not otherwise directly related. When you add, remove or change an email in your Buyer Groups, that does not touch the Transaction Log at all. The original purchase date/time, buyer email, and everything else about the original order is always kept in the Transaction Log; the buyer's current address can be kept and updated as often as you wish in the Mailing List admin screen without affecting your Transaction Log.



The Mailing List admin screen to edit Buyer Group lists is ready for prime-time, or else we wouldn't provide the direct URL to reach it at all. We simply haven't revised Seller Admin to add a link to it yet because Development has been rolling all new features/functions into an all-new, HTML-based Seller Admin they've been working on to replace our current Flash-based Admin panels (which latter are frankly a pain to add anything new to, which is why we're building a new Admin that will be easier for us to modify in the future).



The Transaction Log data must retain all the original order data as-is from the time of the original transaction, or else it really isn't an accurate log of the original transaction data at all anymore. Making the Transaction Log itself directly user-editable just opens a huge can of worms, as we have to consider what misuses and abuses all sorts of scammers, hackers, or just technically-inept or confused users might try to do with that, aside from the bulk of honest, competent users using it correctly and as-intended.



E.g., sellers could mistreat the Transaction Log as a customer-contact database and lose track of their original transaction data or make mistakes changing things in there with either no way to revert, or else we'd have to devise a way to retain a record of previous values for every editable field, which is about the same as the separate Buyer Group vs. Transaction Log records we already maintain anyway, at least for buyer email data. Fraudulent sellers could try to scam people somehow by changing a buyer's order data after they'd received payment, then using that modified record as "proof". We'd have to beef up input-sanitizing to account for the fact that anyone could try to type anything in there rather than just our order-handling scripts doing exactly and only what we programmed them to do. Etc., etc., etc...



We have to devote our limited Development resources where there will be the greatest, most popular/useful, and above all safest result for the least resource-investment sunk. Frankly, making the Transaction Log itself editable would entail a massive effort with potentially serious and wide-ranging security/stability/legal implications, just to add a feature that I can't recall anyone asking about before your interest in it just now, and you apparently only want this feature so you can send a download link to a buyer's new email address, which is like using a Sawzall to do the work of an Xacto knife.



If your primary concern is that you simply want to be able to re-activate a buyer's original download link, but re-send that link to a different email than the buyer's original email address, that seems a reasonable, simple and low-risk feature we could add, so it should get fairly high rank on the wishlist, but we can't promise when or even if it would be added. Meanwhile, you can already do what most other sellers do: use the "Send free download link" function to send a new link to the buyer's current email, and edit your Buyer Group list to update their email if you'll be using our Updates/Newsletter service and want the buyer's current address to be included in those mailings.

E-junkieGuruYour Buyer Group mailing lists are maintained completely separately from your Transaction Log data. Buyer emails are added to your Buyer Group list for each item they purchased at the same time we log their order data in the Transaction Log, but those records are not otherwise directly related. When you add, remove or change an email in your Buyer Groups, that does not touch the Transaction Log at all.





A ha. See, that was the part I didn't know: that they were two separate entities.



E-junkieGuruThe Mailing List admin screen to edit Buyer Group lists is ready for prime-time, or else we wouldn't provide the direct URL to reach it at all.





Gotcha. I mis-understood, my bad.



However, IMHO your examples of the dire consequences of what would happen should the list be editable are a little disingenuous though...I'm not asking for everything to be editable, just the email address. One does not beget the other.



But I appreciate that there are limited resources at play, and one corner case doesn't rank highly. Besides, if you are prioritizing, I'd like to see this get fixed first http://www.e-junkie.com/bb/topic/2912/pg/0#post :slight_smile:



I am very happy to hear that the flash admin section is going away, too...1Password doesn't work with flash logins.



...Mike



1 year later

I went looking again for this post to update a few emails, and I read in this thread from 2 years ago that the HTML interface was being worked on. Is there an ETA for it yet?

We're still working on the new HTML-based Admin; there have been considerable technical and personal setbacks delaying progress on the new Admin last year, but we've just hired a new Developer to help out, so once he gets up to speed on our current codebase and methods, progress will become much swifter.



BTW, until the new Admin is ready, you can always find the link to Mailing List Admin in our Updates & Newsletters help page (towards the bottom under "Removals and updating contact information"):

2http://www.e-junkie.com/ej/help.updates.htm2