Re: Profile fields, partial list sending, and upgrading

 
From: "AJ" <ajfasano@PROTECTED>
Date: March 25th 2013

Dunno! That's sort of just what I picked I doubt it would hurt things, if you changed for your install (barring any charset conversion problems) I can't say I know the difference between the two on the top of my head Since Dada Mail supports 3 different (SQL) backends, and all the backends are a little different, their schemas are also a little different So, for example, the PostgreSQL doesn't set a charset for any of the tables, 'cause (I think) ya don't, in PostgreSQL - rather you set the charset for the database itself

[[ AJ ]] Makes sense and it is good to know that there is no specific reason for using that particular collation Ill change it and see what happens

Def plans - but am not currently working on it Commissioning a feature is the fastest way to get a feature in, otherwise it's on my whim and fancy, and I've got a stout TODO list, and it's also my job to keep maintenance of the app (a usually thankless job), as well as everything else My main drive to add features, after commissions is "what will make people want to use Dada Mail?" and, "What's the fastest to implement?" Expanding Profile Fields is def wanted and a nice feature that many will enjoy, but it would take a good time to start and finish There's a ton of features like that, from internationalization, to moving to a mature web app framework - lots of things People all have their own favorite feature ;) My (messy) TODO list can be found at:

[[ AJ ]] I completely understand the 'thankless job' My side company provides a medical app I coded and it can get crazy with all the requests from the different hospitals/programs It would be nice to get a thank you from my partners once in a while for fixing issues as opposed to an order to fix it :)

Custom template is the way to go My hope for expanding profile fields is to set the type of field, as well as the widget that is shown, as well as doing things like requiring fields, as well as what exactly the field needs to have in terms of data

[[ AJ ]] Works for me

No That's why there's >1 branches - one for bug fixes, and one for features When I make up v6 3 0, I'll most likely merge branch bugfixes-6_2_2, features-email_tracking and features- password_protect_directories_additions into a new branch (6_3_0-dev, or something) and merge that with the master branch, when things have settled It's painfully easy to do in git If we wanted to get fancy, I could release v6 3 0 and v6 2 2, but it's only me, and releasing versions is time- consuming (to get right)

[[ AJ ]] I really need to start spending more time with Git Unfortunately, I am still mainly stuck in the subversion world with a little Bazaar thrown in Do you have any basic procedures for merging in the email tracking? I have quite a bit of experiencing coding in perl so you should not have to 'dumb it down' Just, as I said, not a Git developer yet

Also, I ran into an interesting issue The main app we have is a php app and I decided to make DaDa Mail 'look' like it is written in the same language using a little apache configuration foo like adding the cgi script handler to the dada location for php extensions, renaming mail cgi to index php, and, of course, changing the dada_config Also, using a little rewrite, the app can function with clean urls quite nicely However, I noticed that accessing plugin and extension urls didn’t quite work Granted, probably no one has ever actually done this and it is probably a completely unsupported configuration, however, I can't help it :)

Basically, in the mail cgi, regex is used to compose the plugin, extension, tracker urls, etc You could probably simplify things by using something like PROGRAM_BASE_URL which is the PROGRAM_URL minus the mail cgi, and something like PROGRAM_ENTRY_SCRIPT which would be the mail cgi ( or whatever anyone names it ) The app could then instantiate the extra urls from the BASE_URL instead of applying/maintaining a regex every time the app needs to compose its additional URLs Sure, adding the extra config variables might initially be seen as complicating things but then you could remove all the lines of code in the app where it is repeating the same regex Also, it might make adding functionality easier Just a thought

Thanks for responding so quickly and frankly!

A J

On Mar 24, 2013, at 1:40 PM, AJ ajfasano@PROTECTED wrote:

This looks like a very nice app and I just purchased a lifetime subscription with the hopes this can facilitate a service we provide and I have some questions If I am asking questions that have already been answered, please forgive me

I was experimenting with profile fields and partial list sending and noticed that the search was case sensitive I looked at the schema sql and the table is explicitly created with the utf8_bin collation Why not set it as utf8_general_ci?

I noticed there is no support for required profile fields beyond the email address Looks like this could be handled fairly easily through a custom template and javascript, however, are there any plans to support this natively?

Is there a way to set a profile field as a select list natively? Again this seems like something that can be done via a custom template

Now I have a question about upgrading The version I have is pro 6 2 1 I noticed that there was a post about email tracking The service we run is used by a hospital group to send out transactional and relational email to their employees regarding policy, CME, etc… Granted, if the email is opened in text only the tracking will not work, however, I would like to test the email tracking feature out I noticed on Git that there is a branch for this as well as for 6 2 2 The email tracking branch has older timestamps Does the 6_2_2 contain that? To upgrade, do I follow the same procedure used to install or simply extract the 6_2_2 branch over the existing install? And if I do, will that downgrade the subscription to the GPL version?

Well, that’s all for now Excellent job and thank you for your consideration

A J

Post: mailto:dadadev@dadamailproject com

Unsubscribe »

--

  • Post: mailto:dadadev@dadamailproject com
  • Unsubscribe: http://dadamailproject com/cgi- bin/dada/mail cgi/u/dadadev=
  • This mailing list is a public mailing list - anyone may join or leave, at any time.
  • This mailing list is a group discussion list (unmoderated)
  • 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:

https://dadamailproject.com/d

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:

  • Constructive critiques on the program (I like, "x", but, "y" needs some work - here's an idea on how to make this better...)
  • Bug/Error reports
  • Bug fixes
  • Request For Comments on any changes to the program
  • Help customizing Dada Mail for your own needs
  • Patches
  • Language Translations
  • Support Documentation/Doc editing, FAQ's, etc.
  • Discussion of any changes that you would like to be committed to the next version of Dada Mail -

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.

Privacy Policy:

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.