View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0002785||phpList 3 application||Subscribe Process||public||22-03-05 19:09||20-05-05 20:17|
|Target Version||Fixed in Version|
|Summary||0002785: Wrong handling of already subscribed adresses|
|Description||If somebody subscribes again even he is already subscribed (but should have only updated his configuration) he gets a positive message and a mail.|
But the mail has an unresolved [subscribeurl] in the text.
The right way should be to not send a mail at all and display an error message
instead e.g. "Sorry the e-mail adress is already subscribed. Go to your private configuration (link)" ... or something like that...
|Tags||No tags attached.|
||interesting find. I'll have a closer look at it when I have time.|
The problem is perhaps more complex: you cannot simply ask the user to go to his/her private preferencesURL because that will send the user to only ONE subscribe page (the default one), which does not necessarily have *all* the attributes necessary.
EXAMPLE: you have 2 subscribe pages. If a user subscribes using the first spage, the data will be stored in the database properly. If the same user subscribes again using another spage displaying *different attributes*, the new data is not stored, but the user is told that he/she 'will receive a confirmation email' etc.
This issue invalidates part of the use of having multiple subscribe pages.
[Test done with OS X browser.]
Thanks yan! You are right. The problem has much more depth than thought in first place.
Subscribing the same adress via different subscribe-pages must work - this is essential because the subscription pages are normally on different web pages. So seeing an unresolved [CONFIRMATIONURL] in the mail just leaves a frustrated user and the admin wonders why people don´t confirm...
My first thought was more simple: people subscribe again on the same list. Is this realistic to happen? Yes, because they often forget if the have already subscribed or not and the next time (or months later) they vist your page they maybe try again to subscribe just to make sure they are enrolled.
The problem is: The time the user subscribes the second time his status in the database is: confirmed - not depending on lists or subscription pages since this information is stored in the user_user table.
Here is what i think could be a workaround to not change too much in the db-structure:
When somebody is subscribing and the e-mail is already in the db then:
- subscribe the user to all selected lists in the last displayed subscribe-form
- unsubscribe the user to all the not selected lists in the last displayed subscribe form
- overwrite all displayed attributes with the values in the last displayed subscribe form
- leave all lists and attributes not listed in the last displayed subscribe form untouched for this user
set the status of the user to unconfirmed in user_user
send message with the confirm-url
The reconfirmation is nessesary so no one can simply change the data of somebody else...
This is smoother than pushing user to edit their preferences which may be uncomplete because of missing atttributes like yan stated.
||yes, but now you're describing the process the way it is intended to use. Can you identify in what way this is not happening? Which bits do not work that way, so we can update it.|
||michiel: The problem is that the second time a user is subscribing with the same adress (no matter if different subscribe-pages or not) the data in the db (lists subscribed, attributes) is not changed/updated and the user gets a mail with the unresolved [CONFIRMATIONURL] which he can´t confirm.|
||ok, I will check this out|
||the main issue of the confirmation URL not being replaced correctly is the duplicate.|