I had this problem with my PHPlist installation:
1. We have about 5000 users subscribed, some are members of our organization, others are just interested people.
2. About 1000 of them are members and so I like to periodically update their PHPlist information via CSV import from our membership database, which we try to keep up to date.
3. We also have several different email lists that people can subscribe to. All members are subscribed to our "announce" email list but there are six or eight other lists they can choose to join if they like.
4. Originally I had not used a foreign key with any users. However after going through the update cycle several times I realized we would have better luck with updating member emails etc. if we could match via Foreign Key.
5. So I added a Foreign Key and imported those users.
6. If you include a Foreign Key in your import record, then PHPlist matches entirely by Foreign Key and completed ignores email (as currently implemented in PHPlist 2.10.x).
7. This creates a problem in that my 1000 members are now imported completely afresh (their "new" Foreign Key in the import doesn't match with their current Foreign Key, which is blank). Thus these members' old PHPlist records are all changed to "Duplicate xxx@yyy.zzz" which renders those users inactive. Of course these users are still there--they all have newly imported/created records with the new foreign key and the newly imported attributed data.
8. The problem is that many of these members had subscribed to several different email lists, changed some of their attributes (which are not necessarily all updated via the membership database import), etc.
Even though the situation described above is a one-time problem that I have fixed by a bit of hacking, in fact the general problem of people starting out without a Foreign Key and then adding it (via a CSV list import) is an ongoing problem for us.
We are always working on those "interested people" who subscribe to our email list to join our organization. At that point they will be added to our membership database and they will get a foreign key.
Then when I import the membership database the existing PHPlist information, include list subscriptions, for that members will be lost.
The solution I believe is that PHPList should implement "soft matching" for Foreign Keys vs email.
That is to say:
1. if the Foreign Key from the import matches the Foreign Key in a current PHPlist record, then that is a match
2. if there is no Foreign Key match, then matching of import to existing records reverts to email matching
I'll explain the simple Mod to do this in a separate message.