View Issue Details

Jump to NotesJump to History
This bug affects 1 person(s).
 6
IDProjectCategoryView StatusDate SubmittedLast Update
11458Bug reportsSurvey participants (Tokens)public2016-07-16 11:572017-01-30 09:17
Reportercjfzim Assigned Tomarkusfluer 
PriorityurgentSeverityminor 
Status closedResolutionfixed 
Product Version2.50.x 
Summary11458: Unexpected participant deduplication at time of invitation mail generation
Description

When multiple recipients happen to share the same e-mail address LimeSurvey automatically discards all but one recipient for each e-mail address even though they have different tokens.

I've carried out further testing and have established that multiple participants with the same e-mail address can work [b]provided that they have different names[/b]. In a data set where participants share names and e-mail address but are differentiated by token and various custom attributes, unexpected de-duplication occurs at invitation generation time.

Steps To Reproduce

Create a participant table with two participants that have identical firstname, lastname and email field values. They will have different tid and should have different tokens following token generation. Attempt to send invitations to these two tokens and only one mail will arrive at destination.
In my dataset I have additional custom attributes which provide distinguishing information for these two seemingly identical users but I do not think you will require this in order to see the surprise de-duplication take place.

Additional Information

It is arguably valid to have such a data set since both participants would have registered with the same e-mail address which has just one first and last name.

My evidence appears to indicate that LimeSurvey does do an unexpected (to me at least) de-duplication of the participants table at the time of invitation generation and appears to use the same default critera as offered during participant import whether or not it is appropriate for the data-set. Since there is no mention of this functionality in the Wiki or on the application pages I suspect that it is unintended behaviour. After all, if this was intentional then surely it would have been appropriate to either mimic the criteria actually used during participant import or offer a fresh selection box to gather de-duplication criteria to use at invitation generation time.

The absence of these features during mail generation suggests that the system intends to work on the premise that recipient de-duplication (according to criteria specific to the recipient data-set) has already been carried out during import and, therefore, now that each participant has a unique token, no further de-duplication should happen irrespective of any field values they may have in common with other recipients.

TagsNo tags attached.
Bug heat6
Complete LimeSurvey version number (& build)Version 2.50+ Build 160715
I will donate to the project if issue is resolvedYes
BrowserFirefox
Database type & version5.5.45-MariaDB
Server OS (if known)linux 2.6.32-573.3.1.el6.x86_64 + cpanel 11.56.0.25
Webserver software & version (if known)httpd (2.2.31 (Unix))
PHP Version5.4.45

Users monitoring this issue

cjfzim

Activities

cjfzim

cjfzim

2016-07-19 11:41

reporter   ~39981

Original tests were done using mailer type "PHP".
I have carried out additional testing using SMTP mailer with ALWAYS logging and I can see that the problem is not evident there! Perhaps only a side effect of PHP mailing.
markusfluer

markusfluer

2016-07-29 12:17

administrator   ~40109

I cannot reproduce it.
I tested on a CentOS 6 with nginx/PHP 5.6, Ubuntu 14.04 apache2.4/PHP5.6
and Ubuntu 16.04 Hiawatha/PHP7, maybe it may help to update the php version?
cjfzim

cjfzim

2016-07-29 12:20

reporter   ~40110

I will carry out extra testing with a different PHP version and revert. Thank you.
markusfluer

markusfluer

2016-08-02 10:13

administrator   ~40156

It may also be that your LTP/MTP does the deduplication.
The php mail system uses sendmail, if your local sendmail doesn't cope up with the amount of mails sent it will flush the cache inbetween.
This is what may cause the loss of emails.
Also php-mail is very ineffective for sending more than like a couple mails.
Some mailhosters doesn't allow multiple open smtp-sockets, which is the case with mail(). Each sent email leads to an open smtp-socket.
As also stated the official php-documentation.
Maybe this is where the deduplication is happening, multiple connections at once, or nearly at once, may be causing a false positive on spam detection software,
also on your own machine.

One thing you may try is to log all sendmail activity and see if your server is sending. If you need help please do not hesitate contacting us.

We still recommend using SMTP, it is the safest method.

Thank you very much for your detailed bugreport and effort for finding a solution.

Issue History

Date Modified Username Field Change
2016-07-16 11:57 cjfzim New Issue
2016-07-16 11:58 cjfzim Issue Monitored: cjfzim
2016-07-16 12:19 cjfzim Webserver software & version cpsrvd 11.56.0.25 => httpd (2.2.31 (Unix))
2016-07-16 12:21 cjfzim Operating System (Server) Hosted service on cpanel 11.56.0.25, sorry can't find OS/Version => linux 2.6.32-573.3.1.el6.x86_64 + cpanel 11.56.0.25
2016-07-19 10:59 c_schmitz Priority none => urgent
2016-07-19 11:41 cjfzim Note Added: 39981
2016-07-29 12:17 markusfluer Note Added: 40109
2016-07-29 12:20 cjfzim Note Added: 40110
2016-08-02 10:13 markusfluer Note Added: 40156
2016-08-02 10:13 markusfluer Assigned To => markusfluer
2016-08-02 10:13 markusfluer Status new => feedback
2016-12-08 10:39 c_schmitz Category Tokens => Survey participants (Tokens)
2017-01-30 09:17 markusfluer Status feedback => closed
2017-01-30 09:17 markusfluer Resolution open => fixed
2021-08-05 16:39 guest Bug heat 4 => 6