Justin's Personal TODO List == DADA TO DO: ------------ Key: [ ] To-Do. [-] Working. [x] Done. [*] Naw... [?] Someday * Embed Subscription Form. Options for various frontend frameworks + tabled-based HTML (shutter), flexbox? (advanced) show required form fields, so that people can make their own forms "You Are Already Subscribed" email needs HTML equiv. MUCH larger notification about new versions available New CKeditor 4.6.smeting config.uploadUrl = 'http://dancingindigochild.local/cgi-bin/dada/goodjob.cgi'; config.imageUploadUrl = 'http://dancingindigochild.local/cgi-bin/dada/goodjob.cgi'; }; Add previous plugins - was anyting specifically importnant? What's up with KCFinder? Update TinyMCE? Make the CPAN SMTP unbundled and put into Bundle::DadaMail - hook up the better TLS support Put check for domain for sendmail - is the list owner/admin the same as the installed domain? VCard availability? Put "redirect" URL in modal window, make integration into website much easy - one line of Javascript? Screencast ideas (all the new features) reCAPTCHA setup * Save draft message until mass mailing has completed (or forever?). Maybe allow editing of a message during mass mailing? KEep track of state of mailing to restart? * Maybe save where we aer on a mailing (we already do htis?) and have that as an option restart at, * that would be easy to save in a draft... * Work on build script, and docs on build script * Double-check commadn line works correctly, and add ALL options to command line * Double check PSGI docs are up to date, * and make new tutorial on working with Dada Mail in a container https://robn.io/docker-perl/ * Blog Using Tracker to figure out if messages are sending correctly Make some sort of dupe message stopper. Hash accepted messages, perhaps, save hash, compare to messages coming in, and reject messages that match the hash, after x times? Read in message, save hash of BODY (only body) and Message-ID (Which should be uique) Test: see if there are three messages stored that have the same hash, OR Messge-ID. If so? Test FAILS HOUSEKEEPING: Get rid of records that are x days old (60?). Since we're only saving the hash, this should be a BIG tabe CREATE TABLE IF NOT EXISTS dada_bridge_message_dupe_trove ( id INT4 NOT NULL PRIMARY KEY AUTO_INCREMENT, list varchar(16), body_hash VARCHAR(225) NOT NULL, content_id VARCHAR(225) NOT NULL, ); CREATE INDEX dada_bridge_message_dupe_trove_all_index ON dada_bridge_message_dupe_trove (list, body_hash, content_id); Core5Filemanager replacement: https://github.com/servocoder/RichFilemanager * Make using Email::MIME::CreateHTML an option if available - and maybe the dfault, unless NOT available, * make slight tweak so that LWP resolver doesn't die with unfound resource - just a warning is just fine... Other things we may want to look for, for embeddignn images? 'bgsound' => {'src'=>1}, 'body' => {'background'=>1}, 'img' => {'src'=>1}, 'input' => {'src'=>1}, 'table' => {'background'=>1}, 'td' => {'background'=>1}, 'th' => {'background'=>1}, 'tr' => {'background'=>1} Send a Webpage ourselves (Love to inline all linkned stylesheets beforehand - MIME::Lite::HTML takes care of that - AND inlining images, grr!) Grab Webpage Apply Template? - do we just take the content? - want this as its own "filter" - or, attempt to inject our own css into the page (we need our own css...) - but template now comprised both a and a so results are goign to be WEIRD - vote for taking just content from body... BUT: - We can also make it an option: - Apply template (using only the of the template...) - do NOT apply template (use this for Send a Webpage screen, as well...) - and then we can have > 1 templates too choose from: the all-encompassing template, and a bare bones template, that just has unsub/pysical address information. THEN make into multipart/related mime message WHATEVER we do, we probably need to a preview button, that also allows you to send a test message out? (or two buttons, whatever - next to the template picker?) * So mailing list mssage content: Inject stylesheet into start of , or right before body, or if there's o body, well, you gotta make one ,inlinify (removing stylesheet) - if CSS::Inliner isk available, then add to already inlined template. Sigh! Guess we'll have to figure out a policy on what to do with the full HTML document, if we're just taking what's in the body tag? Should CKEdit have the stylesheet already loaded in? What happens if you edit the underlying HTML? * Does format_headers_and_body with -msg param. still... work? why is the bridge plugin sched job taking so much processing time, when all the lists are using mail fowards?! Problems w/Safari in the Membership >> View screen. Add SES support to the CL installer... pull msg from rss feed Can the encrypted password be exportable (and also importable?) Lt's double-check the new index I've made is gooder. for the rate limit stuff. be prtty sweet to view to-be moderated messages in the web admin, yeah? and/or after x days, messages are automatically approved/denied, are images found embedded in HTML messages saved that way, when they're archived? If so, they should't be... Make prntng out delivery prefs optional Make exported CSV something that you ca easily import (timestamp at the end, then?) I WANT TO SEE THE DIGEST PREFS (AND PERHAPS IMPORT THAT) BRIDGE: Tag for original From: header Tag View of profile fields? [ ] Syntax check for (at least) email message templates. Already a, DADA::Template::Widgets::validate_screen method to use Take subscription size into consideration when making auto adjut batch seding speed thing Update CKEditor for the drag n drop image feature. new branch! [ ] My bet is that I'm not the only impatient list admin out there and that there a lot of admins who would like to see (maybe even expect) the names to disappear off the bounce list as soon as the manual deletions are done. I haven't checked the existing SQL, but I would think that should be possible. I see your point: it would make more sense for the score to be more related to the subscription of the address, rather than how it is, now. I think this is just a historical artifact, when Dada Mail supported a more simple backend, that didn't allow for such meta information. I'll make a note to integrate the bounce scorecard with the actual subscriber's data. Show sending prefs in View List Screen (only if digests are enabled) Switch from list owner to root from within the list control panel easily. - a setting to allow you to choose which screen comes up on login. F Well, that could certainly be made per-list (easily) Membership >> View - inline ediing of data in table cells (guh - duh!) QR codes that people can point their cell phone at and sign up automagically. - kinda interesting idea... Perhaps save drafts in a way that are archived (but, uh, not in the archive, or are, just not in th same way) Anways- a way to pull up the message, to send again. Yeah. New Core5 Filemanager only sending part of the URL? no domain? (unconfirmed...) Hey, you know what? I can make my own inliner super service! Agreement step on subscription (by checking this box, you agree to the following, yadda yadda) email list owner about new list being created. Broke KCFinder too?! Installer - create cli args when setting up DM in web installer, save those are in .dada_config file, along with date of configuration creation and v. of app that created it. Bridge - email list owner if message over Had limit is sent - say something like, "too big to even open" and perhaps where to change this setting, [ ] Some IP Addresses for opens/clickthroughs are from datacenters of the mail service (gmail, hotmail) - is there a way to get the original ip? [] Ability to set defautl draft message for new messages is bounce handler set as default admin email? [] Maybe an email about when a mass mailing starts? [] global option to enable/disable modal menu on subscription form? [ ] Things for CGI::App migration: Perhaps figure out forking stuff, first? [] list-specific upload directories, rather than a shared one [] remove MIME::Lite completely (ongoing process) [] Add, "Frequency of email messages" [] ability to share stationery messages. [ ] A way to set an alternative path to perl [ ] Keep tmp subscriber list fresh in mass mailing metadata. That basically means make the tmp subscribe list right before sending, as mass mailings get queued. [] Are strange attachment names still working? [ ] Bounce Handler should know about vacation messages, and forward them to the list owner, if it receives one. __cfduid [ ] Upgrade KCFinder, we're a few years out of date. [ ] write about caching - no one really understands [ ] It may be nice to have a preview of what the header will look like, for p.p. mode, as the default is a little complicated. [x] Timestamp - pick two dates BETWEEN X AND Y [ ] Tests - what happens if one of the dates is not filled out? [ ] Also work on advanced search, and saving advanced search, pickable inview screen, as well as partial sending, so you can save an advanced search and a draft, w/partial sending w/that advanced search, which will be dynamica. Hooyh. [ ] All the (new) stuff in the view list screen needs to have the ability to be turned on/off by root for the List... [ ] It would be nice to be able to have a custom error message ready, for when the field is left blank. [ ] Explain that hidden fields that are required, are not required by users, who have no way to fill them out! [ ] New Cols in subscriber table [ ] col to describe how the subscriber was subscribed [ ] confirmed [ ] unconfirmed [ ] Perhaps this is an entirely new table, describing the type of subscription [ ] UID, IP, timestamp, by whom (role), and subscription table just has relation to UID in the current subscription [ ] Oh, boy another table to update when a subscription is made. [-] Need ability to: [x] send complaints to list owner, [ ] log complaints, [x] track complaints in tracker plugin Need to finish: [ ] Fleshing out copy for all the screens, emails [ ] logging complaints... todo for ver. after? [ ] Integration w/StopForumSpam Here's some discussion: https://dadamailproject.com/support/boards/viewtopic.php?flavor=9&t=4066&p=14868 http://stopforumspam.com [ ] Voting widget (thumbs up/down) on newsletters Lists will need to have two ways of opereation: [ ] SES: Get list of verified senders - warn! (somewhere if list owner/list admin is NOT a verified sender, and perhaps have some sort of fallback, so that mail just doesn't stop. [ ] Amazon SES Bounce Notification [ ] Amazon SES Bounce/Complaints via SNS, instead of the Bounce Email address. Ability to log COMPLAINTS! Good! (*) Automatically unsubscribe complaints ( ) Alert list owner about complaints Embed Message ID in From: header via VERP-ish behavior (listowner+MESSAGEIDHERE@example.com) Just need to figure out the subscribe stuff. Maybe the Appliation URL is something like: http://example.com/cgi-bin/dada/mail.cgi/plugins/bounce_handler/sns/list_name [ ] Seond step of add an address, "These addresses are already subcribed to your list" - should be tweaked for specific sublist [ ] Bridge Global defaults - add option to enable open discussion lists, etc [ ] Fancy Template things: for Global User Template, have option to just use a "blank" page (or any page, really), and: [ ] Allow you to inject the needed default template in BOTH the head and body, [ ] We can either look for a specific div id, or just take everything out between the tags [ ] Option to Embed js and or css? [ ] I would need to rename a lot of the css stuff, so it doesn't get in the way with a page's already existing stuff, [ ] and perhaps even seprate out form, and presentation css (do people do this, anymore?) [x] HTML::LinkExtor and image maps? [ ] Permission Reminders http://blog.sendgrid.com/permission-reminders-affect-email-deliverability/ [ ] List Information: need some sort of form validation - was there some? What happened to it?! [ ] Bridge: gotta state the message size limits on the admin screen - people have no idea. [ ] Installer - it'd be nice if the guess fo the.dada_fiels loc looked for the saved PROGRAM_URL - if it seems not to be the same loc as where we're installed - DON'T use it! [x] Installer - more easily set up CAPTCHA stuff (reCaptcha, etc) [ ] total_processed log, in case you cut a mass mailing short. [ ] Map to go along with Physical Address [ ] Template checker for HTML/Email Templates [ ] RSS to email [ ] Pagination on the public archive screens [ ] bounce handler - weekly reports? [ ] ARF reports? [ ] Complaint Tracking? [ ] Bounce Handler - ability to substract x from all scored addresses [ ] Ability to act upon all addresses in scorecard [ ] Perhaps another email protection scheme - just break the email address. [ ] Also: The act says, “Recipients of commercial electronic mail have a right to decline to receive additional commercial electronic mail from the same source.” So, unsub link is one-click w/embedded address, but encoded somehow. Encoding broken? Give manual instructions Put in one-step unsub form, with partially decoded address (MD5?), asking you to re-enter your address. Does not match up? Show an error message, describing what may be going on. Constant Contact: Oops. The email address you entered doesn’t match. Don’t remember signing up? If a friend forwarded you the email from The John D'oh Corporation, you were never on the mailing list. If you no longer wish to receive these emails, make sure to tell your friend to stop forwarding them to you. [] Ability to SEE other sublists... [ ] Ability to see other sublists (already invited) (Subscription Confirmation...) [ ] Screencast on how to install CPAN modules you may just need. [ ] Docs on moving from "Basic Mailing List" to Dada Mail !!! [ ] Rss to email converter? [ ] Thank you, quick question, is there a way for DadaMail to pull recent information from an RSS feed to do regular mails of recent posts? MailChimp does this and its handy for automated emails. [ ] - Beatitude - needs to be able to read RSS/Atom Feeds http://search.cpan.org/~btrott/XML-Feed/ [] Revist docs on Bridge - update. Now that I have some time, maybe the best thing to do is have such links bring the user to a screen that says something like, "link expired, try that all again, sorry about that: (show sub/unsub form)" [x] Revist docs on Bridge - update. [ ] Look for JSON modules - not there? "install" them ourselves (renamed JSON-remove[..] files/directories. [ ] Stil have to figure out why I'm calling JSON::PP, and not just JSON (?) [ ] There should be a test in the PlaiNText -> HTML message changer to make sure the template is still valid. And if it isn't, abort the change! [ ] Template and Template Tag checkers - is it a valid template? Warn if it ain't! [ ] Look at date on messages, if that's realistic. Option to deny messages that are too old. why doesn't the mailing monitor show STALE mass mailings? THe hell is an, "inactive" mailing? [ ] Sending a test message should pull up profile info, if the email address that you send a test message to, is the list owner. [ ] Oh, also, I notice that even if I, as the Pro Dada Root user, hide the Mass Mailing section so that list admin log-ins won't be able to see it, the program still defaults to showing them the Mass Mailing >> Send a Message screen when they first log in. That seems less than secure... [ ] Invite mailings should probably use tmp lists in then db, since if anything goes wrong before that list is removed, your next invite gets all screwed up. And what about multiple invite mass mailings going at one time?! [ ] Manual in ePub format [ ] Docs on moving/migrating from MailMan to Dada Mail [ ] Markdown support - Write "PlainText" messages in TextTile, and have them formatted when shown in messages, etc - option to turn into HTML when sending? Power user option! [ ] ReWrite Digest stuff - make a digest list a sublist, allow subscribers to subscribe to either, "list" or "sublist" (or change that in the profile screen) digest members not allowed to post to list. For now. Cronjob can be same as Dada Bridge cron, just extra step - time to run the digest? What messages get sent out? Make the digest (RFC of format? Different options?), send 'er out. Or maybe not a sublist, but just a pref? That would make it easier went administrate. So: Every Message Every Day of Messages No Messages...? AND EXISTS ( SELECT * FROM dada_profiles_settings WHERE dada_subscribers.email = dada_profiles_settings.email AND dada_profiles_settings.setting = 'digest' AND dada_profiles_settings.value = 1 ) [ ] Always archive messages, but don't always show the archived message. Meaning, there's a new field, Called, "visibility" (or, whatever), that you can set to 1 or 0 - If it's 1, it's shown, if it's 0, it's not. [ ] - Ability to set a custom Feed URL (ie: Feedburner) [ ] Ability to have a, "I see your email has changed - want to change it in Dada Mail?" functionality in the list control panel. (I don't understand this idea, anymore...) [ ] Ability to NOT distribute messages to users (so for example if I'm using Mail Merge to create labels, I can clear those people I want to NOT print a label for). [ ] Bounce Handler- a way to pull up the original, offending message to view [] SpamAssassin plugin config for Dada Bridge? Just so it's easier to pass custom parameters to SpamAssassin, in Dada Bridge (just whatever is needed in new()) filter_subscribers enhancements it would be nice if, during the, "Add/Invite screen, you're allowed to see which subscribers you're trying to import have already gotten a subscription request - and if so, not allow them to get another invite/whatever. Just another hook into, "Limit Subscriber Confirmation" stuff. I think. [ ] Simple Subscribe/Unsubscribe by email mechanism in bridge.cgi message just has, subscribe or unsubscribe If so, Dada Mail just goes through the usual DADA::App::Subscriptions::subscribe|unsubscribe methods - except, anything that needs a HTML screen is handled by email - if it can be. (That feature has to be fleshed out - not too much more to go) Also, this is an optional feature - can be disabled. This can also - randomly be a way to work with Dada Mail's subscription process for outside scripts. Uh, maybe good idea? List Invitation Verbiage Sucks, maybe something more like, Subject: You've been Invited to Subscibe to, "My List" The List Owner of, "My List" (myemail@example.com) has invited you to Subscribe! Here's a brief description of the mailing list: Blah blah blah * To automatically subscribe, click here: (You can always remove yourself from the mailing list, at any time) * Visit the Mailing List Page: * To never receive these requests for this mailing list again, click here: <- that'll be some new features - subscribe to black list stuff. Ugh! Maybe it'll work liek this: * The request will look for a sub_confirm entry, if not -ERROR * The pin will be just like a sub/unsub confirm entry - if not there, ERROR - * The error will just be a form to ask to be removed from this list again, * New confirmation sent, done and done. * No way to override this, text, whatever. * Terse copy, right to the point. * Privacy Policy: Blah Blah Blah * Physical Address: Blah Blah Blah The, " To never receive these requests for this mailing list again" stuff should also be stated upon unsubscribing - maybe the subscriber should know they're listed as not-to-be-fucked with, again Along those lines, it would be a good idea to say that, "Hey, if *you* want to subscribe again, get your jollies off!" And make sure subscriptions remove the subscriber from the black list, cause that makes sense. Ugh, but only when subscriptions are made by themselves. Discussion List stuff List Email needs to be noted on the List Page (How can it not? Makes no sense) The "You're Subscribed now!" email And Mailing List Messages - as long as it's a disussion list. That's an if statement away Profile Stuff If profiles are enabled, this also needs to be on all outgoing mass emails Subscribe/Unsubscribe pages And other stuff, I can't think of. Feedback Form Upon Unsubscribing - This gets sent to the list owner This could be the easiest way for people to vent about abuse of the list, to the list owner, and let the just-removed subscriber feel that they're doing something How to stave off abuse of this feature? Email/Pin thing... maybe? CAPTCHA? [ ] Move the perllib directory? It's kind of in a funky spot, currently. Would be better a little more out of the way [ ] This could also be a GREAT place, esp. with unsubs to have a form, for "write a message to hte list owner about why you're ditchin't he list" or options to, "unsub me from all lists on this domain" or, whatever. [ ] Sub would be nice to have a, "Subscribe" or a, "Subscriber and login into my profile" type of thing. [ ] TWO more valid email checks need to be done: [ ] Maybe it's time to put a check, for the list owner/list admin - NOT allowed to subscribe to a site. [ ] There's a small bug in the email verification thingy - if the email address is longer than the SQL field, it'll get concatenated, and you'll have an invalid address subscribed. [ ] The sub/unsub log really needs updating - with an SQL version. Some fields that would be nice. An easy way to view this information. An easy way to export this information email, list, action, origin of action, date.... what else? action: subscribe, unsubscribe, disable, enable, move...? there are all verbs origin of action - from the subscriber, or the list owner? [x] Bounce emails are getting out of control. It may be time to use that, "active" field that's in the subscription table, that's currently dormant, to, instead of removing email addresses, we simply, "disable" the address from being used. This'll stop subscription lists from going to hell, if there's a problem on the mail server of our side (and the problem is, it's bouncing our own messages) [ ] The user can re-enable their subscription through the profile dealy-do. Brilliant! [ ] I also like the idea of the list owner or SUBSCRIBE being able to enable/disable a subscription at-will. For example: vacation messages [ ] This is a good idea for the approval system: https://dadamailproject.com/support/boards/viewtopic.php?flavor=25&t=2082&p=7931#p7931 Since the "Subscription requests approving/denying (experimental)" is asking for feedback, I would suggest that the "white list" email addresses can bypass the manual approval process, and be seen as a "pre-approval" list, or that there be an option under this feature to "pre-approve white listed email addresses without sending an approval email". [ ] How about a place in the "Change lIst INfo" that shows the bounce handler addrss and a little button to allow you to make THAT your list admin? [ ] How about a message count in the bounce handler/dada bridge, without having to actually check the messages? [ ] Perhaps think of replacing Crypt::CipherSaber with something a little more modern... Had another problem with this - Crypte::CipherSaber wasn't working - thinking it may be the encoding stuff? Crypt::CBC could possibly be a better candidate - or at least give the user a choice as to which one to use. [ ] On one installation we only send to people on a fixed mailing list but t here are three or four different types of message some of which have virtually the same text at each mailing. Can we have a means of having multiple templates where we only have to add in a short additional message or different attachment. Selection by meanas of a tickbox would been good. [ ] One central login for all lists. [ ] It would be great if the Send the Newest Archived Message to All New Subscribers in the Archive Options section would have a checkmark for sending the latest message to users that are added by the admin. [ ] API. As Frans said, it is very useful to be able to use Dada Mail from other programs. Maybe it could even get to the point that the Administration pages use the same API, instead of actually having code in them, so that we have built in API documentation. [ ] Profile Fields Make it possible to define other profile fields like a checkbox, radio buttons, text area and select list. Besides public and hidden fields (those starting with an underscore) add another category "read-only": these are showed publicly but cannot be changed by a subscriber, e.g. by adding attribute "disabled" to the corresponding tag. [ ] API to login from other software Currently I am using the following code in main.cgi (sub login) to login from a CMS, enter a specific admin screen (f=send_url_email) and pass another parameter (url=https://dadamailproject.com/ used by my modified "send_url_email"): require DADA::App::Session; my $dada_session = DADA::App::Session->new(); # login by means of a url: http://www.domain.com/cgi-bin/dada/mail.cgi?flavor=login&admin_password=password&admin_list=listname&auth_state=1&admin_option1=f=send_url_email&admin_option2=url=https://dadamailproject.com/ $referer = "$DADA::Config::S_PROGRAM_URL?".$q->param('admin_option1') if($q->param('admin_option1')); $referer .= '&'.$q->param('admin_option2') if($q->param('admin_option2')); $referer .= '&'.$q->param('admin_option3') if($q->param('admin_option3')); logout(-redirect => 0) if($q->param('admin_option1') && $dada_session->logged_into_diff_list(-cgi_obj => $q) == 1); Would be nice if this kind of functionality can become part of the official dada code. [ ] Language files To make it easier to translate at least the public part of dada. If we can can agree about how to do this I am willing to do the coding like putting the english texts into language file(s) and replace them with variables. So when somebody wants to use a different language he "only" needs to translate these language files, besides the (public) templates of course. Currently we have to translate inside the Perl source code in main.cgi, error.pm etc. [x] 1. Installer It would be great to have it more like Wordpress or Piwik where it will notify you of updates and 'upgrade itself' quite happily (making database changes, downloading and installing new versions etc.). I know to start this process is probably a lot of work, but you might want to involve some of the rest of us with this to help with the burden as once it's done, it will work great. [ ] 2. Plugins Wordpress (notice the theme here :-)) plugins are a great concept. Anyone can write them, and they can be enabled/disabled and for example we could install our own Clicktracker we have written as a module rather than having to have it 'sit outside' of Dada. Which brings me to... [ ] 3. Clickthrough Tracker We've had to disable the Dada one as the open rate works fine (1 pixel transparent gif) however we need to track sales conversions so need to know 'where' on an email someone clicked and that they were part of our marketing list that generated the sale. Sounds like you're having similar thoughts (we use MD5 hashes to anonymise any information etc.) [ ] 4. Tiny URL style links We're MD5 hashing our links, but it would be great to have the ability in Dada to do similar. We use this for double opt-ins and it works well. [ ] 5. Mail Chimp Not sure if you've used this, but a number of our smaller clients have moved over to this, rather than 'take on' Dada as they find it much easier and simpler to use. Yes you have to pay for it, which obviously is a disadvantage and it's not open source, so you can't change everything, but they all think the UI is pretty intuitive whereas many find Dada just 'too tough'. If we could borrow some of the best bits from this for Dada then that would be good :-) [ ] 6. Widgits Agree with your thoughts below and if you get a chance have a look at the way Piwik (http://piwik.org/) works with its UI. Pick up any window, drag it to a different place, it really is as easy as pie! [ ] 7. Analytics integration Getting Dada to talk to other programs is difficult - we tend to roll our own code and put it into the emails. If we could, for example, have a call-out API where Dada could talk to Google Analytics and update that with Goal/Funnel conversions or something like that, that would be pretty cool. Hope this helps! [ ] How about a, "Download" subscribers button?, instead of, "Open it in a new window!" Wouldn't that be easier? [x]2. The migration tool worked fine, but had to use it without instructions as the link to the documentation page gives me a "Forbidden" error. It's pretty much self-explantatory though so wasn't a problem. [ ] 5. In the HTML Message template, the is getting wrapped with

...

tags which are spoiling my footing layout. This doesn't happen with 3.0.x. [ ] I've removed the line actually wraps lines in paragraphs and removed the option in HTML::FromText that says, "hey treat things as lines" - although the, "hey treat these as paragraph oriented" was also enabled... I may have to revert this problem. [ ] Hey, that seemed to have worked! ------------- [ ] List Owner Confirmed subscriptions What do I have to do for this? [ ] New List subtupe 'sub_request'? [ ] New thingy in the subscription process, AFTER (or in?) the subscription process that goes "Hey not so fast, bub, we still now need to confirm this subscription with the list owner - cause this list be CLOSED! [ ] New interface in the list admin control panel to confirm/deny a subscripiton Seperate than the other "View" Screens, since there's a different interface going on... [ ] If it's confirmed/denied, a new email message has to be sent out! Agh! Probably not as a mass-mailing - one at a time? [ ] Anything else? [x] List Invite not working? If I try to do a list invite (and follow the confirmation link), it tells me that the pin is valid, but I didn't first ask for a confirmation. Weird! And then, when I go through the confirmation process, the password sent to the address doesn't work. When I look and see what's up in the DB all the fields are NULL except, "email". Strange?! [x] I was using the wrong API in the code - this effects the master branch as well. Hopefully, when we merge, the problem will magically, "go away" (fix in this branch) [x] Admin menu. rearrange stuff. [x] Make sure to double-check these changes with everyone. [x] my changes are in the .dada_config file. Move over to Config.pm and example .dada_config's [ ] Double-check the changes with myself! [x] I need to perhaps make an option to that you cannot edit profile info, if you're not Dada Root. (no option, just... YOU CAN'T.) [x] Or make it clear that editing the information will deal with all lists. and/or have a way to know that a subscriber is on more than one list (and perhaps which lists?) (or a way to see a "public" profile? (turn on/off) [-] I need some basic form validation for the Profile Fields. Right now, all I have is length. The SQL stuff is properly quoted... What else?! [x] I need to change all instances of, "Subscriber Fields" to, "Profile Fields" [x] I need to make that SQL table upgrade thingy Something like: DETECT if there may be a problem. Test test test. (first get the prev. profile fields + email address) # HEY! Is there a way to do this just in SQL (find columns, EXCEPT @list_of_columns) INSERT INTO TestTable (FirstName, LastName) SELECT email, @profile_fields FROM Person.Contact WHERE EmailPromotion = 2 foreach(@profile_fields){ DELETE COLUMN from that_first_table } [x] I need to write up all these changes [x] Sigh. [ ] perhaps make a note about global unsubs in the profile? [x] You need to change the profile fields when they're listed_like_this, to be Listed Like This! [-] Profile Fields widget - is it in places where we don't want it? [ ] Some more live testing... [x] A "delete" profile function? What happens to the subscriptions? [ ]A master, "Unsubscribe me AND delete this profile" Thingy? [x] I need to merge all of the code that creates the query for the Profile Fields into ONE method, because it's getting complicated, it's being used in more than one place, AND people want to change it. A tall order, but probably, well worth it! [-] The, "Your subscriptions" thingy in the Profile thingy has to let you know, if you aren't actually subscribed to any lists. Right now, if you're not, it just looks broken. [ ] It would also be nice, that if you were the List Owner of a List, you'd also be listed as that. Special things, like that. Sigh. [x] Need a way to update an email address from the profile, and perhaps auto-merge, if the email address is already subscribed to an address. (it should probably be warned if this happens...) [x] Once the above are done, I need some major testing stuff to be made and then, we gotta wrap this up - probably make the 3.0.x to 3.1 script and call it a beta! [x] Some things to remember - the SQL needs new tables AND info has to be moved from one table to another.... sigh. [ ] Man, wouldn't it be nice to have an installer...? Sigh. [x] I need to make upgrade notes from Simple Scripts installs. [ ] The docs need to be clearer about how to work with HTML templates, and the like, [ ] double check bug fixes from 3.0.x are in 3.1.x... (3.1) [x] I need to make an option to says, "Hey that need Profile Fields info? Replace what my be there with, THIS, or, use what's there, if there's already something there, Probably per import, for now, [x] Gravatar bells and whistles in the profile screen [ ] CAPTCHA for, "hey, you've already *asked* for this damn subscription! screen - the check at the moment is too simple. [ ] Remember to move over any changes from 3.0.x to 3.1in POD docs... [x] Magic Subscription Forms - a way to turn *off*?! [x] I need to HTML-ify the list description in the profile screen. [x] I need a purge button for subscribers. [x] Currently, the following sites will be notified: is not listing anything... [ ] It would be nice to have an option that says, "Hey, that email template? Why don't we see it initially in the, "Send a Message" scrren - so, if I want to tweak it slightly - I can. The problem is, what if someone totally obliterates the, unsub info, thinking that the email template was going to be applied? Perhaps just a warning at the top, "The email template is plopped down below and won't be applied again" [ ] I'd also have to make a really really really good check, to make sure that, if there's nothing extra type, the email template isn't used. [x] Need option to turn FCKEditor off list-by-list - what if for some reason it's not working? Broken Dada Mail. [x] MIME-Tools require ver 5.8 of Perl, which I'm fine with, but we're still saying we ship needing only 5.6. MIME-Tools is having a hissy fit with IO:: stuff - so I may just ship with an older version of MIME-Tools, to get around that problem - I'll leave, MIME-Tools in DadaMail.pm, but I'll just ship with the older version (5.420) Send a Webpage: Give options on what to do with Javascript, Stylesheets: change links to embed Remove (or, if it's not too hard) Leave alone, thank you very much Also, sputter back any errors found, hooking into the MIME::Lite::HTML stuff I'll probably have to make my own parse method. Sigh. And include_js method. Stupid. Also: http://rt.cpan.org/Public/Bug/Display.html?id=36005 [x] "You may only change the Profile Fields if you are logged in to an existing list using the Dada Mail Root Password." [x] "Use underscores, instead of spaces - no funny characters, and use lower case characters instead of uppercase. Make the attachment limit somewhat flexible? Check in FCKeditor_default_value_widget.tmpl Perhaps fill in with a similar default value that FCKeditor uses, but all on one line? Will that work Have the DADA::App::FormatMessages::pre_process_msg_strings() subroutine know about the default_value that can be user-setable. Wooosh! (and that way, also, Beatitude can use this default value, yeah!) I have to update the perllib stuff, including: MIME::Parser Time Date Schedules do not get deleted, when a list gets deleted, which means, if you create new list with the same shortname, the old schedules will magically work again. Gotta update LWP - perhaps have it not "live" by default. I probably have to... I forgot :) This is more of a scratchpad, than anything else. 3.1 Change the Clickthrough Tracker to change all the URL's found to Click trackable: http://search.cpan.org/~bdfoy/HTML-SimpleLinkExtor/lib/SimpleLinkExtor.pm 3.0 [x] Probably take the send_email, send_url_email and possibly list_invite and put them into their own modules, ala DADA::App::Subscriptions, so I can call them in other modules (or, whatever) and also have it WAY easier to test with. Although, I do see where this is all going - I'm haphazardly reinventing CGI::Application. Hopefully, this'll just get the code *ready* fro CGI::Application, and I just don't keep writing silly modules, like this. But, yeah, it would *really* be nice for testing purposes... [ ] Something has to be done about error messages in the multiple subscribe script. Perhaps have a little ajax window with the error message (the same one you see in the, "there's seems to be a problem, but without the header/footer) when you click a, "Huh?" button, or something. I hates me that extension. [ ] It would be really nice to make my own include type for HTML::Template, powered simply by filters - the catch is that I want to be able to pass variables, so the tag would look something like: and the filter just looks for: And variables are parsed via: my $str = $1; my @vars = split(\s+, $str); my %named_vars; foreach(@vars){ my ($name, $value) = split(':', $_); $value =~ s/^\"|\"$//; } And then pass the vars to HTML::Template (again!) and replace the tag with what that's returned with. I'm assuming you understand how bug-ridden the above is and would not attempt to do copy/paste this. [+] Damn it: http://osdir.com/ml/lang.perl.modules.html-template/2006-12/msg00004.html [x] Probably make a module named something like, HTML::Template::MyExpr and make that like, one little change. Sigh. [x] Perhaps have two mail settings- one for mass mailings, one for everything else. # (Would make things that need to be sent, sent FAST!) [*] Talk to the reCAPTCHA CPAN guy and get 'em to distribute a Pure-Perl compatible version of his module (shouldn't be hard) [+] Talkin': http://rt.cpan.org/Public/Bug/Display.html?id=31740 [+] Meh, it ain't goin anywhere, the PP version Really really needs to be rewritten, because it sucks! [ ] Get rid of DADA::Template::HTML, since it's stupid and horribly written and being superceded by DADA::Template::Widgets anyways [ ] Add a, "wrap" parameter to DADA::Template::Widgets::screen, so that you can do the things DADA::Template::HTML does, but do it better [ ] Get rid of that option to have

tags made - that was stupod [ ] This will also get rid of the problem of these templates being, "different" than the other templates in Dada Mail. Yeah! [ ] Move DADA::Template::Widgets screen() super subroutine into it's own module, called: DADA::Template::Screen (or perhaps, HTML::Screen? - naw, how about, Screen... for now...) Make DADA::Template::Screen OO, but have the new() need no params. Break the screen() subroutine into manageable chunks - right now, it's pretty gigantic (and growing) [ ] Move DADA::Template::Widgets too: DADA::Template::Screen::Widgets And I think that would make a whole lot more sense. [ ] Move DADA::App::FormatMessages' email_template to somewhere else? (and name change) Perhaps, DADA::Template::Screen, or even, DADA::Template::EmailMessages? DADA::Template::EmailMessages would just be based on, DADA::Template::Screen [ ] Remove any screens from (the now dubbed) DADA::Template::Screen::Widgets And actually Make them *only* widgets Also, (perhaps) make a, widgets parameter for (whatever it gets named) screen subroutine (erm, now method) so there's an indirect way to call the widgets - just more syntactic sugar, I guess. (This, of course is to be done before the next alpha release. Har Har) [-] Work on Getting rid of the, "Send a List Invitaton" and moving that sort of stuff into the, "Add" Workflow. [ ] That means we need some way to have a preview of the message that's going to go out [ ] Preview also has to work for the, "Send a Message" screen [ ] Preview has to fill in tags 'n stuff. [ ] Preview is a difficult feature. OK? [-] It would be nice to have breadcrumbs, so the person going through the, "add" process knows what to expect [ ] I do need to still encode the subscription information in the, "add/verify" screen in a better way than now - currently, I'm using what looks like anonymous hashrefs or something, that's then eval() in - I'm certain you can see the problem in THAT. For 2.11 - [ ] - probably best to have a unsubscribed list - ONLY to (currently) be used to cull information from people who subscribe-then unsubscribe, then subscribe again...? - I like the idea better of a one-use pin, if you unsub and resub, the pin has to be regenerated again (and that means, you have to fill in a subscription form again) - I guess I'm going to ship, NOT having an unsubscribe list, but only have pins available for one-use. It may be the same pin, but a confirmation has to be done after a request to confirm. I guess it would be really nice to have a new sublist for just digests and have a way for a subscriber to easily move between the two (regular and digest) I'd also have to make it easy to send out digests. I'd als have to mkae it easy for subscribers to update their own information. It seems like a lot of work. [-] - Set settings for archive-> advanced for protecting email addresses. [ ] Work on 3.0 docs (Multiple Fields, Basically) * High Priority * Flesh out entire API - and that means: [ ] Perl code, [ ] perl module hierarchy, [ ] SQL Stuff [ ] Extending Backend [ ] Integration with other systems [ ] everything. Make schematics of screens used to administrate the subscriber backend and also screens used for individual subscribers. See: [ ] Work on Manage Subscribers -> Add Screen * Medium+ Priority * Currently a Time-Out problem when you have a LOT of subscribers and/or a lot of subscribers you'd like to add. [ ] Break into steps that itself are broken into bit-sized chunks, perhaps the chunks can be sized via time limit. !!! May not be needed, as the, "filter_subscribers" method has been sped up. Steps include (but aren't limited to): * Check for validity (valid form) * mx_lookup check (perchance, currently, not a part of the admin: add functions (takes too long! currently) * Check for subscription status * Check for blacklist status [ ] Work on Bounce Handler * Medium Priority * [ x] Update command line interface/docs to match bridge.cgi CLI API where features overlap. [ x] Web-based way to check/parse/score awaiting bounces for use with cronjobs [ x] Web-based way to view scorecard [ x] Web-based way to search through scorecard [ ] Web-based way to remove addresses on scorecard [ ] Work on bridge.cgi * Medium Priority * [ ] Come up with Catchy Name [ -] Update command line interface/docs to match Bounce Handler CLI API where features overlap. [ ] Flesh out (finally) extensible moderation system. Refer to: [?] Any Sponsors? [ ] work on Beatitude [ ] Update command line interface/docs to match bridge.cgi CLI API where features overlap. [ ] Work on Auto-Pickup/Mail Monitor * Medium Priority * [ ] Redesign the mess that is (at least in alpha 5) the Mail Monitor for individual screens. [ ] Test test test [ ] API Changes [*] Normalize API's for: * DADA::MailingList::Subscribers * DADA::MailingList::Settings * DADA::MailingList::Archives * DADA::Mail::Send etc, For example, they should ALL have new() method like this: my $subscriber_handle = DADA::MailingLIst::Subscibrers->new({-list => 'list'}); Another example: my $send_handle = DADA::Mail::Send->new({-list => 'list'}); Another example: my $settings_handle = DADA::MailingList::Settings->new(-list => 'list'); See what I mean? Even go so far as making a new object, called simply Dada::MailingList with the same exact API: my $mailing_list_handle = DADA::MailingList->new(-list => 'list'); And then you could say: my $list_settings = $mailing_list_handle->{settings}->get; #or, whatever. [ ] (Wishlist) Installer for Dada Mail that'll do a virgin install and also upgrade, if you're using an outside config file [-] Continued Work: Automated Testing Suite [ ] Continued Work: API Documentation For Whenever [ ] Sponsorship can be from YouCanEmailUs.com - a free email service provider for nursing homes, retirement centers, and the elderly [ ] Batch settings based on throughput - state an amount of data that can go out at one time and adjust bounce settings to work within that limit. [ ] Make general template to set various Email Header options, like Priority, charset, etc, etc, etc [*] Replace MIME::Lite::HTML (The, "Send a Webpage" thingy)( with this: http://search.cpan.org/~bbc/Email-MIME-CreateHTML/ [ ] oh! little problem, that solution is MUCH MUCH more complex. Perhaps have a way to choose. 2.11 alpha - (old to do) [ ] - Archives - need passcode. Need email address that's subscribed and/or passcode to view archived messages - This goes for rss/atom feeds as well - how do you do that? RSS uses basic username:password@somedomain.com authentication. How do you read that? - CPAN has some stuff, but it requires a *few* modules. Probably will hold out that for a bit... [-] It would be nice to have some sort of built-in connection doctor... # Added DBI debuggin' to Dada Mail [ ] Perhaps to add back maxlength for textareas: http://www.quirksmode.org/dom/maxlength.html [ ] sending a disc. message from the list control panel *still* does not append the, [list] thingy to the subject, if it's supposed to... [] add a, "resend" button to the archive editor [x] create a, "drafts" archive. [x] enable sending a message straight into STDIN from bridge.cgi (perchance) [x] add documentation about whiz-bang new FCKeditor stuff (test more) Archives have the [listshortname], etc appended to subject - used to not, need pref for that. Perhaps have a: X-Recipient_Name: X-Recipient_Domain: header, as another way of figuring out what the origin of bounced messages were (*cough AOL cough*) (mumblings) [-] Hook up Spamassassin to bridge.cgi, reject messages that score, "n" on the tests - pref to flat out reject, or bounce back. May also be good to have in the, "Send a Message" screen, so you know just how your message will be treated; Work on moderation, either a message that needs moderation is sent to one moderator randomly, or to all of the moderators - copy of the message is sent along with the explaning email, and a copy is saved on the server until it's thumb'd up or down. Explaining message has special URL with random digits, so moderators do not have to log into Dada Mail, only click the, "yes", or, "no!" links. View archives in blog-mode - messages in a list. Also by /2004/05/06 type URL's and make a little calendar view too! (hell, why not!) Consider trackbacking, although it seems, "Dead". allow replies from the archives themselves, email required - and not posted until an email confirmation is answered. [ x ] Think about making a SQL connection/disconnect object, that can be passed whenever a new instance of one of the SQL backends gets called - this should make less connections to the SQL server per run of the program. [ ] tag in Send a URL that holds the URL you're sending... [x ] add option for subscribers to not receive their own message. [x] Revist clickthrough - make work with query strings and perhaps targeted stuff? (does it break when the tag has a target in it? [ ] Cleanup routine for MIME-Tools tmp files - say remove everything that's one hour/day old? [x] reformat 7bit to take off annoying wrappage. [x] reformat text messages that are US-ASCII or quoted/printable, they have all these strange, =20 thingies - most likely to cut long lines. [x] archived messages need to have inline/attached images shown [x] as well as attachments available to download via a click. Send a Message/Send a webpage, etc need the same options, "open in a new window, I'm sure, send to multiple lists, send after email x" [] Set $SMTP_TRUSTING to zero by default or do the whole hash way, or make it a list-centric pref. ( I have to review this cause I forget what this means... :) ) [] Add new upload widgets to the advanced Send a Message form without refreshing the page and thus losing all yer message stuff (via ajax - http://books.slashdot.org/article.pl?sid=05/08/01/2019247&tid=156&tid=95&tid=6 ) [x] " Sent to the Subscription List." discuss pref on by default. [] $ENV{HTTP_REFERER} in Logs; [] Replace HTML::FromText with HTML::TextToHTML [x] Revisit Atom - either get replacement for XML::Atom::SimpleFeed or make it work with (now) .07. *sigh* Ditched XML::Atom::SimpleFeed since it's not into the 1.0 spec - replaced it with my own code and HTML::Template Template. Stole some code for Date generation and such. [x] add, "name" and "domain" parts of the email address to the tmp bulk sending file, so we can parse that in and have the correct sub/unsub URL's. [x] revisit path_info stuff. [] http://baby.com.ar/dada-2.9.1_embedding.patch Things to do for the beta [] wait up on this bug... https://bugzilla.mozilla.org/show_bug.cgi?id=80713 [x] The, "Add to whitelist" screen does not take on the look and feel of the list - dummy... [] https://dadamailproject.com/cgi-bin/yabb/YaBB.cgi?board=everything_else;action=display;num=1118782581;start=0#2 [] When using a SQL backend and trying to restore from a backup: Can't locate object method "backupToDir" via package "DADA::MailingList::Archives" at force_backup.cgi line 18, line 1. [x] Gotta put the, "new window" and, "are you sure" checkboxes for list invite, send a webpage; [x] Widgets.pm warning: warn "$PROGRAM_NAME warning: '$Templates' is not a directory!" unless -d $Templates; ANNOYING!!! [ ] I really need to make the precurser of DADA::App::FormatMessages - Something like, DADA::App::BuildMessages... (I guess, although MIME::Lite is pretty close...) [x] clickthrough: https://dadamailproject.com/cgi-bin/yabb/YaBB.cgi?board=everything_else;action=display;num=1111320574;start=0#3 [x] Note on Email Confirmation to include the list owner's email address in their addressbook/whitelist; [] why is moving from PlainText -> SQL so HARD for the subscribers?! Should be BUILT IN! [x] List Owner email message about unsubs via bounce handler? [-] All that fancy stuff in Send a Webpage? Yeah, gotta do it to Beatitude as well; [x] send to multiple lists at once [] Yay, also look into Envelop Sending - if: We're using SMTP AND We're using SQL AND!!!! There's no customization in the message, we can do some high fly'n DUDE. Gah. Apparently, RFC2821 states that sites are *required* to take in at the very least (meaning 100 flat) in an envelop sending! That's *Great!* - but: http://www.python.org/cgi-bin/faqw-mm.py?query=personalization&querytype=simple&casefold=yes&req=search Also says, "have to be careful, setting it above 50 these days" DoH! (it also says, 5's the sweet spot - weird ain't?) [-] Moderation in bridge.cgi... [] look for text/enriched to wrap dada templates in bridge.cgi? Change the Browser Sig for fetfching.... stuff. [] id per email address... - does verp fix this? Sort of - encoded in there Also the nu school unsub url's don't *really* have the email addy in there... [] s/\n/

/ for physical address, privacy policy. [-]remove Perl Modules that get d/l'd but, still aren't used? (working on this...) delete list should have to use a password too? ---------- [x] the below is a little... more non-trivial than I thought... Think about making a MIME entity viewer. For the archives - make a standalone viewer that only needs a MIME message, use MIME-Tools to parse it, use HTML::Template to provide the formatting; Then make it a part of Dada Mail - for now, we'll save the raw message within the archives themselves, and if MIME-Tools isn't available, we can fall back to the lame way we're doing it now; We'll get the raw message as a return value of Mail::Send::bulksend, like we're getting the msg id from now; Good idea? Yes? No? --- Why isn't File::Spec a part of the perllib?!