In a nutshell, that's what will happen in 3.1 (the alpha that's out will has this design, already)
�I am facing this problem myself at the moment. However, I have to figure out a solution yet. Taking a look at the mysql backend, the database design is a bit weak. There should be a table for subscribers, a table for lists, and another table that maps subscribers to lists.
I don't know if this'll help the scenarios everyone is facing, though: wanting to send the same message to more than one list.
This did used to be a feature in Dada Mail.
It was *removed*, when subscriber fields were introduced - subscriber fields could be used instead to make dynamic sublists.
The reason for the removal was that there was going to be a mass of confusion if you ever, say, wanted to send a message to *part* of more than one list. Each time a subscriber is subscribed to a mailing list, the subscription fields would be duplicated and could, potentially, be different.
In 3.1, the subscriber fields info is separate from the table that tells what addresses are subscribed to which lists, so this won't be a problem anymore. The "Send to more than one list" feature could potentially be reintroduced.
I really really want to get 3.1 out. The last thing I'm working is allowing a subscriber to update their email address. It's a lot harder than it seems, though, so It's taking a slow time.
The new features also don't have any TAP tests associated with them and there's no docs on the new API, both of which are not so much fun to make and take a long time to make right. Sigh.
--
Justin J.
Dada Mail - �Write Once: Distribute Everywhere Software
url: http://dadamailproject.com
Demo:
http://demo.dadamailproject.com
Seen Dada Mail 3?
http://dadamailproject.com/features/3_0/--
On Apr 29, 2009, at 11:16 AM, Samer Bechara wrote:
�I am facing this problem myself at the moment. However, I have to figure out a solution yet. Taking a look at the mysql backend, the database design is a bit weak. There should be a table for subscribers, a table for lists, and another table that maps subscribers to lists.
Currently, if I need to email multiple lists, a user who has subscribed to multiple lists will receive the same message more than once. However, with a better database design, it would make this much easier.
I am willing to work on the backend database design, however, I need someone to help me with scripting, as my perl skills are not very advanced.
Lennie Jarratt wrote:
Post:
I keep running into the following scenario and was wondering if anyone else has dealt with this yet.
Organization has multiple lists. �They want to send out an email blast to all lists or select which lists to send to with one simple send instead of copying and sending a message to each list.
I was handling this for one client by adding hidden user fields so they have 1 list. �That way when they send, they choose who to send it to with the filters. �They then have issues with manually adding new names. �It's a political campaign so they get names at events that need to be added manually.
What I have thought about to handle this is to create a mapping table that identifies the lists a user belong to removing and removing the list name from the subscribers table. � This would also necessitate changes to the send and subscribe functions.
First, has anyone else worked with this? �Or has anyone else run into this?
Thanks in advance.
Lennie
--
Twitter: http://twitter.com/ljarratt
Facebook: http://www.facebook.com/people/Lennie_Jarratt/1182350486
"The necessity of the times, more than ever, calls for our utmost circumspection, deliberation, fortitude, and perseverance." - Samuel Adams
Post:
mailto:dadadev@PROTECTED
Unsubscribe:
http://dadamailproject.com/cgi-bin/dada/mail.cgi/u/dadadev/
List Information:
http://dadamailproject.com/cgi-bin/dada/mail.cgi/list/dadadev
Archive:
http://dadamailproject.com/cgi-bin/dada/mail.cgi/archive/dadadev
Mailing List Powered by Dada Mail
Mailing List Powered by Dada Mail
mailto:dadadev@PROTECTED
Unsubscribe:
http://dadamailproject.com/cgi-bin/dada/mail.cgi/u/dadadev/
List Information:
http://dadamailproject.com/cgi-bin/dada/mail.cgi/list/dadadev
Archive:
http://dadamailproject.com/cgi-bin/dada/mail.cgi/archive/dadadev
http://dadamailproject.com/cgi-bin/dada/mail.cgi/what_is_dada_mail/
Post:<mailto:dadadev@PROTECTED>
Unsubscribe:
<http://dadamailproject.com/cgi-bin/dada/mail.cgi/u/dadadev/>
List Information:<http://dadamailproject.com/cgi-bin/dada/mail.cgi/list/dadadev>
Archive:<http://dadamailproject.com/cgi-bin/dada/mail.cgi/archive/dadadev>
Mailing List Powered by Dada Mail
Post:
mailto:[list_settings.discussion_pop_email]
Unsubscribe:
http://dadamailproject.com/cgi-bin/dada/mail.cgi/u/[list]/
List Information:
[PROGRAM_URL]/list/[list_settings.list]
Start a new thread, email: dadadev@dadamailproject.com
This is the developer discussion mailing list for Dada Mail.
If you are just looking for support Dada Mail, consult the message boards at:
https://forum.dadamailproject.com
Documentation for Dada Mail:
Specifically, see the Error FAQ:
https://dadamailproject.com/d/FAQ-errors.pod.html
To post to this list, send a message to:
mailto:dadadev@dadamailproject.com
All subscribers of this list may post to the list itself.
Topics that are welcome:
Dada Mail is on Github:
https://github.com/justingit/dada-mail/
If you would like to fork, branch, send over PRs, open up issues, etc.
This Privacy Policy is for this mailing list, and this mailing list only.
Email addresses collection through this mailing list are used explicitly to work within this email discussion list.
We only collect email addresses through our Closed-Loop Opt-In system.
We don't use your email address for any other purpose.
We won't be sharing your email address with any other entity.
Unsubscription can be done at any time. Please contact us at: justin@dadamailproject.com for any help regarding your subscription, including removal from the mailing list.
All mailing list messages sent from us will include a subscription removal link, which will allow you to remove yourself from this mailing list automatically, and permanently.
All consent to use your email address for any other purpose stated at the time of the mailing list subscription will also be revoked upon mailing list removal.