Not really - just a text editor and a ton of unit tests The debugger for Perl is the Perl debugger

http://perldoc perl org/perldebug html

Also, why is the short name have such a small character limit and not allow '-' in it?

I know about the basic console debugger I guess I have gotten used to visual ones like the perl Tk debugger ( I have been using Devel::ptkdb for many years ) when executing and debugging perl scripts Was just curious if there was anything else out there like PHPED for php or eclipse for java I also tried Padre for perl and the eclipse perl plugin but none worked all that well

It's just used as a simple identifier for things like URL's and for things in the DB In your case, it looks like you're tying the short name to the List Email, but there's no such constraint that says the list shortname and the name part of your List Email have to be the same

When entering in the short name, it limits the number of characters used and limits the characters to alphanumeric only I was just curious as to the reason behind it The other reason I asked that is related to the multi-list send and potential sublists The example is that the hospital has the general medical staffing list and under that come the departments So I modified the code to accommodate multi list sending but to prevent people from sending to lists that were not subordinate to theirs by adding a regex to the routine that generates the select list of lists to send to

So an admin of a list with a shortname of 'medicine' will only see in their multi list send options lists that start with 'med' Pediatrics is medpeds ( would prefer med-peds but we can only use alphanumeric ) The admin of that list will see medicinepedsres ( residents ), medpedsatt ( attendings ), medpedser ( pediatric er ), etc It is a relatively minor code adjustment Was just wondering if there was a database reason for limiting the shortname For example, I would love to have medicine, medicine-peds, medicine-peds-res, medicine-peds-er, etc I can modify the code but I just want to be sure other things won't break

Thanks for the replies

A J

Justin J: Lead Dadaist url: http://dadamailproject com email: justin@dadamailproject com skype: leaddadaist

On Aug 7, 2013, at 3:23 PM, AJ ajfasano@PROTECTED wrote:

>

On another note and while you are watching :)

Justin, Do you use an IDE and/or have integrated debugging, or any step through type of debugging suggestions?

I ask because I created a postfix recipe for the bridge so there was no need to create an individual mailbox and pipe command for each list the inbound email for the list is @ Create a SQL virtual alias map that looks like: query = SELECT CONCAT(list, '@ internal-placeholder-domain ') FROM dada_settings WHERE setting='discussion_pop_email' AND value='%s' if the email exists, a non-existent alias is returned: 'list@internal- placeholder-domain ' "the dot at the end is essential" Even though the alias doesn’t really exist, the sql query comes back so postfix sees it as a valid alias and passes it to the transport map

The transport map then picks it up: query = SELECT 'dadabridge' FROM dada_settings WHERE setting='discussion_pop_email' AND list='%u' AND '%d' = 'internal-placeholder-domain'

Since %u is the original user name of the email, minus the domain, and equals the shortname of the email list, and assuming the list exists, it is then passed to the transport which is: dadabridge unix - n n - - pipe flags=FR user= argv=dadaroot/cgi-bin/dada/plugins/bridge cgi --inject --list ${user}

Now this works, however, I would like to step through the bridge to see if I could formally define a mailbox with an alias for each list and have that forward to the bridge, and have the bridge look at the short name, or the full To email address, in the To field and select the list to send it to

Or is this all moot, as I haven’t not had a chance to look at 6 5

Also, why is the short name have such a small character limit and not allow '-' in it?

A J

-----Original Message----- From: Justin J [mailto:justin@dadamailproject com] Sent: Wednesday, August 07, 2013 4:27 PM To: Dada Mail Developers Subject: [dadadev] Re: Big Feature Time: a show of hands on which way to go

On Aug 7, 2013, at 2:25 PM, Justin J justin@PROTECTED wrote:

Probably along the same lines, a Draft would also be saved when a test message is sent out I could also get rid of the, "Open in a New Window" checkbox That way, pressing, "Back", or revisiting the screen would always load up the saved draft

(Thinking to myself): along the same lines, why is the screen refreshed when a test message is sent out, anyways? Why not just have a little dialogue box that pops up, that says, "hey, test message is away!" instead of the worthless mailing monitor screen, that says the same thing?

--

Justin J: Lead Dadaist url: http://dadamailproject com email: justin@dadamailproject com skype: leaddadaist

On Aug 7, 2013, at 2:25 PM, Justin J justin@PROTECTED wrote:

>

On Aug 7, 2013, at 2:13 PM, "AJ" ajfasano@PROTECTED wrote:

>

Not sure if this is relevant

I wrote an application that medical resident use to keep notes on their patients They wanted a similar thing What I did was use a jquery autosave library to take the form, asynchronously post it to a backend routine which serializes the data into a kind of draft object and stores it in the db with the patient identifier

Whoa - yeah, we'll def do the, "Auto save in the background" song and dance Good point raised That's a BIG big big part of all this Def fits in with keeping things simple, and adds a ton of capability

Probably along the same lines, a Draft would also be saved when a test message is sent out I could also get rid of the, "Open in a New Window" checkbox That way, pressing, "Back", or revisiting the screen would always load up the saved draft

Man, this will def turn into the, "Why wasn't this in the app 10 years ago" feature

--

Justin J: Lead Dadaist url: http://dadamailproject com email: justin@dadamailproject com skype: leaddadaist

On Aug 7, 2013, at 2:13 PM, "AJ" ajfasano@PROTECTED wrote:

>

Not sure if this is relevant

I wrote an application that medical resident use to keep notes on their patients They wanted a similar thing What I did was use a jquery autosave library to take the form, asynchronously post it to a backend routine which serializes the data into a kind of draft object and stores it in the db with the patient identifier Then, if they get disconnected, or just leave the form, and don't save it, the next time they access the edit screen for that patient, the first thing the app does is check to see if there is any 'draft' data If so, it takes the cached object, un-serializes it, and updates the fields with the unsaved data On save, it deletes the serialized object There is also a 'cancel' button which will wipe out the autosaved draft without updating the record and a 'continue later' that will leave the object there so they don’t have to use the back button and an event listener that will pop-up a box asking if they really want to leave if they happen to use the back button

Kinda of like the various webmail providers when you are entering an email

-----Original Message----- From: Justin J [mailto:justin@dadamailproject com] Sent: Wednesday, August 07, 2013 4:01 PM To: Dada Mail Developers Subject: [dadadev] Re: Big Feature Time: a show of hands on which way to go

Thanks for everyone's feedback! Looks like, "Save as Draft" is the winner here To address some of the questions/comments:

On Aug 6, 2013, at 10:43 PM, H E Weenink | Aristo Advies & Internet h.e.weenink@aristo-internet nl wrote:

I vote for #1 (I now use the scheduled mailing as a workaround, but saving as a draft is better) PS: Some suggestions/ideas on the draft: - Use archived mailing as a draft for new mailing - Use a draft as starter for a scheduled mailing - Use a draft in more then 1 mailinglist (example: custumor of us, has 8 lists in different languages We make a starter in 1 language and copy/past to other lists, and then edit the language) - Save more then 1 draft (they may be used as templates for new mailings)

I never thought of "Save as Draft" as being a place to save a starter for a new message, but that seems to be a good idea How do people perceive that workflow? Right now, the idea is,

• Start creating your message (and get interrupted, whatever), click the, "Save as Draft" button
• Message gets saved
• Later on, revisit the, "Send a Message" screen and get prompted, "You have a saved draft, continue?" [Yes/No]
• Click yes, message gets loaded, and you can continue

Once a message is sent, it seems that that Draft would go away, since it isn't a Draft anymore, it's Completed

I don't want to do this idea:

• Use archived mailing as a draft for new mailing

Since parsing an archived message is messy, and lossy (i e : things will NOT appear 100% the way the did) and won't work 100%, leading to all sorts of trouble I AM open to the idea of having messages in some sort of draft form that can be loaded back in the, "Send a Message" screen, that can then be edited The difference is, archived messages are saved as basically the source of an mail messages, a draft can be saved in any way that makes sense, complete with metadata

On Aug 7, 2013, at 8:26 AM, Bruce Harper bharper@PROTECTED wrote:

Pretty much our sole use of Dada Mail is through Scheduled Mailings, so if that plugin were to get a little bit of attention, it would be helpful If nothing else, please move or add the link from the mailing configuration page back to the schedule index page

Wait, what's going on?

On Aug 7, 2013, at 8:49 AM, Mary Ann Kelley maryann@PROTECTED wrote:

Thanks - that will be really helpful I'll look for it Justin, could that be bundled with Dada or is there a reason you dropped it?

In re: to the multi_admin_subscribers cgi plugin, a ton of things: there's no support for profile fields, there's no real verification step, there's no option to invite, different mailing lists have different rules allowing/disallowing subscriptions via the control panel, having to deal with black list/white lists You can glaze over most all of that, and there you go: that plugin, but I'm not interested in doing that Part of my job is to promote the use of sustainable mailing lists, which means a verified list of people that want to be subscribed The plugin is too easy for someone not thinking clearly to abuse

I also just have so much mindshare/time to keep a plugin I don't like alive ;)

If you need to update an email address (to a different email address), you can do that in the list control panel now, across different mailing lists Your user, who owns the address can also update things in the Profiles

BIG ASIDE: If the reply to that is, "Yeah, but what I want is to run a PRIVATE email list, that doesn't require the facilities of a PUBLIC mailing list (subscription verification/unsubscription requirement, so on and so forth) that's a whole new different feature I can work on, that a lot of people have begged for, and it could also be in the running for the NEXT Big Feature I work on The crux on that is, how to keep people from abusing that (because, people will) The answer is going to be, you're going to have to use a third party email service that monitors such abuse (Amazon SES/Mailgun, etc), 'cause I ain't going to do that, for the love of it /END BIG ASIDE

I'm sort of surprised Scheduled Mailings is such a killer feature, so to just calm everyone down (I also get asked this, semi-frequently), the plugin won't be pulled, until a major release of Dada Mail (v7?) I would like to add a, "Schedule" tab to the, "Send a Message" screen, to allow you to schedule a mailing for a one time (non-repeating) scheduled mailing, which I think(?) will work for 99% of people who use the feature, and give you all the features and gizmos located on the "Send a Message" screen, for your scheduled mailing I've noticed that not many people have a programmed daily schedule going out, with dynamic content Rather, people are just queueing up a month's worth of messages (for example),

--

Justin J: Lead Dadaist url: http://dadamailproject com email: justin@dadamailproject com skype: leaddadaist

On Aug 6, 2013, at 8:57 PM, Justin J justin@PROTECTED wrote:

>

I'm in a good spot to work on a Big Feature in Dada Mail: I'd like to get an informal opinion on what to work on first The choices are:

• Save as Draft for the, "Send a Message/Send a Webpage" screens,
  • or -
• Features pertaining to the Profile Fields: Required Fields, different form widgets, better search capabilities (save a search result/dynamic sublists), etc

My guess is #1 would be more killer for more people - I get asked how to save a draft quite a bit ;)

What's your pick?

--

Justin J: Lead Dadaist url: http://dadamailproject com email: justin@dadamailproject com skype: leaddadaist

--

• Post: mailto:dadadev@dadamailproject com
• Unsubscribe: http://dadamailproject com/cgi- bin/dada/mail cgi/t/REMOVED/=

--

• Post: mailto:dadadev@dadamailproject com
• Unsubscribe: http://dadamailproject com/cgi-

bin/dada/mail cgi/t/ghpzOCe2fvmgXitNuurjCCSU3y6NO9sPudoaxiu2/=

--

• Post: mailto:dadadev@dadamailproject com
• Unsubscribe: http://dadamailproject com/cgi-bin/dada/mail cgi/t/REMOVED/=

--

• Post: mailto:dadadev@dadamailproject com
• Unsubscribe: http://dadamailproject com/cgi-bin/dada/mail cgi/t/REMOVED/=

--

• Post: mailto:dadadev@dadamailproject com
• Unsubscribe: http://dadamailproject com/cgi- bin/dada/mail cgi/t/ZHumWAtuiiD3bOEUzBheS2eitoq9aToTawiMItgy/=

--

• Post: mailto:dadadev@dadamailproject com
• Unsubscribe: http://dadamailproject com/cgi-bin/dada/mail cgi/t/REMOVED/=

--

• Post: mailto:dadadev@dadamailproject com
• Unsubscribe: http://dadamailproject com/cgi- bin/dada/mail cgi/t/kuUadRoY9Pceh4qbCsYEOAdacCruRduYYwrSjicU/=