View Issue Details

IDProjectCategoryView StatusLast Update
0002785phpList 3 applicationSubscribe Processpublic20-05-05 20:17
Reporternetwear 
PrioritynormalSeverityminorReproducibilityalways
Status resolvedResolutionduplicate 
Product Version2.9.4 
Target VersionFixed in Version 
Summary0002785: Wrong handling of already subscribed adresses
DescriptionIf 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...

TagsNo tags attached.

Relationships

duplicate of 0003049 resolvedmichiel Invalid Subscribe URL 

Activities

michiel

23-03-05 11:04

manager   ~0004003

interesting find. I'll have a closer look at it when I have time.

yan

29-03-05 10:41

reporter   ~0004053

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.]

netwear

29-03-05 16:15

reporter   ~0004056

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.

Harald

michiel

29-03-05 16:38

manager   ~0004057

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.

netwear

29-03-05 16:54

reporter   ~0004058

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.

michiel

29-03-05 17:13

manager   ~0004059

ok, I will check this out

michiel

20-05-05 20:17

manager   ~0004981

the main issue of the confirmation URL not being replaced correctly is the duplicate.