[SOLVED] Mailer plugin logic for birthday mail

I have used a birthday wishes mailer (see image for setup) for a couple of days and triggered it manually each day, just to see that it worked as it should. It worked really well and our members are really happy for the mail!

Yesterday I set up a cron job for this mailer. Before, however, I changed my own birthday to yesterday's date and ran the cron url to see if it would send a mail to me, despite the fact that I triggered it for the other birthday guys earlier. I got the mail as planned and changed my birthday date again - now to today's date, to be able to confirm that the cron job would do its work this morning.

The others with a birthday got the mail this morning, according to the "Sent mail" log, but I didn't. What may the reason be?

Is it the fact that I already got the mail yesterday, based on the "old birthday date" and if so, what will happen next year for the birthday wishes mail, for all members that got their mail this year?

I guess it's the wording for some of the settings that makes it a bit difficult for me to really understand the logic behind, e.g. "Relative to this date of the plans below" and "Order Date of the order wanting to use this promotion".

Thanks,

You need to compare against the current date. As is I believe you're comparing to the order date of their subscription. The below should work to provide what you're wanting.

Date A, Field A or Value A: Following CB field
CB Field A: Your Field
Date B, Field B or Value B: Constant Value or String (CB substitutions can be used)
Value B: [cb:date format="Y-m-d" /]
Condition 1 (> for Dates): Birthday function: Date A Matches Month and Day but not Year of Date B

The above will ensure the birthday field is always comparing against the current date. You can find more information on substitution usage below.

www.joomlapolis.com/support/tutorials/107-use-cases/18353-using-substitutions-throughout-cb

Thank you so much for your swift replies - not just this one

I actually followed the instruction in the manual, even though I wondered if it was right. Figures 250-252 in the manual illustrate my initial setup.

So, for a "vanilla" birthday wishes mail, the setup would be:

Yup, that configuration looks correct now. Please let me know if it doesn't work properly this time, but you should be good to go.

Same thing happened today - all the others got their mail but not me, as the test person, where I changed the birthday date to today.

As I said earlier, I got my first mail after changing my own date and running the cron url "manually" a couple of days ago.

Is it the fact that it's the second and third mail for the same user?
Maybe a flag being set somewhere?

Strange :huh:

andor wrote: Same thing happened today - all the others got their mail but not me, as the test person, where I changed the birthday date to today.

As I said earlier, I got my first mail after changing my own date and running the cron url "manually" a couple of days ago.

Is it the fact that it's the second and third mail for the same user?
Maybe a flag being set somewhere?

Strange :huh:

We discussed this internally with Beat and this is a summary of status:

Each mailer will only be sent once per matched triggering condition
conditions tab is just an additional condition to the trigger

so in this case, as soon as registration date changes, another mail will be sent
but not if birthday changes after first mail has been sent out

the sent mails table is used for that check

to do the birthdays usecase, or any other CB field (other than registration date), we would need to extend the triggering condition's setting

implementation for handing user table is already there

--

So in summary, as things are now you cannot have a single mailer to send every year birthday emails.

To redo your test with same user you would need to manually find and remove the first sent email row from the table.

You cannot have a single mailer for birthdays that is useful for more than one year.

Once solution would be to manually replicate the initial mailer item once a year.

We intend to improve this with CB 2.0 functionality.

Hope this is helpful.