Best practice forum (Archived) - Audience auto assignment to programs?

Skip to main content

Skip Create an account

Best practice forum (Archived)

Audience auto assignment to programs?

Hi everyone

Can someone help me out here. We have set up a a dynamic audience and created a rule to auto assign new users to it. That part is working just fine. We then have the audience assigned to a program. This seems to be working, but its not consistent. Sometimes people get assigned immediately and receive an email notifying them. Sometimes there is a delay of several hours before they are assigned and then they get an email. Sometimes they get assigned at some point, but they receive no email (therefore its hard to say how long the delay is). Can someone tell me what the process is for someone to get assigned to a course or program in this manner. Is it a cron? Can we control the timing? Is it something else?

thanks

Matt

Permalink | Reply

Hi Matt,

Are you sure all the users are assigned to the audience at the same time? The assignation should happen instantly, so its possible users are added as they fulfill the assignation criteria rather than all at once.

cheers,

George.

Permalink | Show parent | Reply

The folks are not getting added to the audience at the same time. Its a dynamic audience and people get added as they register to the site and also meet the criteria that the rule is based on. Folks get added to the audience right away. However, they don't get added to the program right away. The time it takes seems to vary so it would seem that getting added to the program is tied to a cron. Is this the case? If not and they should be getting added instantly, then any idea why they wouldn't be? Is there any documentation you can point me to that outlines technically how this works?

thanks

matt

Permalink | Show parent | Reply

Hi Matt,

Have you looked at the completion criteria - is it set at from "First login"? If it is they will not be added until they login.

cheers,

G.

Permalink | Show parent | Reply

Hi George, Matt

I just want to add a 'me too' to this one. I have played around with the completion settings, and also removed them completely, tried different settings and rerun the cron several times over the course of 24 hours, but some users are not getting any emails at all.

I think some documentation around this would be useful.

@Matt - did you get anywhere with this issue?

Regards
Bodo

Permalink | Show parent | Reply

Hi Bodo,

Ive submitted a Help bug with regard to better documentation. Can you send me further details?

cheers,

George.

Permalink | Show parent | Reply

For reference we are on Totara 2.2.17

These are the things I have tested.

Test: I have ensured general emails are sent by testing the 'forgot my passwod' email
- Result: Email was sent and received within seconds.
Test: I have one dynamic audience based off a custom profile field, assigned to program, with completion criteria of (first logged in) 3 of those in this audience have previously logged in, 2 have not. No exceptions present.
- Result: None of them received any emails.
  - Test: Then ran Cron manually
    - Result: None of them received any emails
Test: I have one dynamic audience based off a custom profile field, assigned to program, with completion criteria of (fixed date of completion). No exceptions present.
- Result: None of them received any emails.
  - Test: Then ran Cron manually
    - Result: None of them received any emails

After further testing on various other servers, where emails worked, I came across this setting which was different:

Enable messaging (Y/N) Should the messaging system between site users be enabled?

I switched this off because I did not want the users to be able to use the rather clunky internal messaging system, not realising that this would also disable emailing.

Can an additional warning message be shown on this setting, to warn users that disabling messaging will also disable program emails but not other emails?

Permalink | Show parent | Reply

Hey Bodo

We did eventually figure it out. There are two things that we had issues with. The first was tied to getting dynamically added to the audience based on a custom profile field. We created a pick list and based on the selection, it would add you to the desired audience. At first, this was not working. We discovered a bug tied to using capital letters in a picklist. Not sure why that was an issue, but it was. Once we made all options in lower case, it worked fine.

Next was the issue of getting added to a program. It is tied to a cron, but its a sub routine cron and not part of the main one. It runs on a timed setting, but its not consistent, in that it won't run daily at the exact same time. Once they finally get added, they then have to wait for the next "email send" cron to run in order to get the confirmation email. So, it all runs about every 24 hours, but it could vary by as much as 2 hours in either direction.

I'm not sure why its set up like this, but it isn't really a problem for our client. They just wanted to have confidence that it would run each day and it does.

Hope this helps

Matt

Permalink | Show parent | Reply

Hi Matt,

The case sensitivity bug was fixed in 2.2.17

regards,

George.

Permalink | Show parent | Reply

Hey guys,

I messed around with program emails a bit today and you're right there does seem to be something strange going on there. I'll look into it further and try get it working a bit more consistently.

Cheers
David

Permalink | Show parent | Reply

Thank you David.

I am also getting some set and program due messages at strange times, and I cannot seem to make sense of the timing of these in relation to the set allowed time and the program due date.

Some documentation on how these messages are triggered, and how its related to the set allowed time and program due date would be really helpful!

Regards

Bodo

Permalink | Show parent | Reply

Hey Guys,

It looks like program messages are working pretty much as intended. Yes turning off messaging in the advanced features tab does stop them sending emails. That is because they are treated as tasks/alerts which use the messaging system, it's not ideal and it's definitely not clear so I'll get a warning added there.

As for how program messaging works, I'll go over a few:

Enrolment:
So you enrol an individual or audience with a set completion. When you click save Totara will immediately send enrolment messages to everyone, or generate exceptions for them. The fun example however is a dynamic audience with a completion based off of first log in. So you have an audience of 5 users, 2 of which have logged in before, 3 of which have not. You click save and the 2 who have should get a welcome message, the three who havent are 'future enrolments' and aren't actually added untill they have logged in once and the programs hourly cron runs, but the message won't be sent till the daily cron runs. A sixth person who has enrolled before qualifies for this audience, they are also not enrolled untill the next programs daily cron run.

Unenrolment:
This should always occur when you click save.

Due:
Say you have given them 2 weeks to do the program, and set this to send when they have 1 week remaining. This will send on the programs daily cron that runs after the condition is met. So this could potentially lead to it being sent with 6.01 days remaining (worst case).

Overdue:
The same goes for overdue, imagining the same scenario with the message set to send when 1 week overdue it is possible in the worst case for it to send 7.99 days after the program is due.

If you want to make these send more often you can move the messaging function from daily to hourly in totara/program/cron.php ~line 124 "Program_cron_send_messages();"

Hope that helps, let me know if I've missed something or been unclear.
David

Permalink | Show parent | Reply

Thank you for the detailed explanation. I have been testing this out however the times the emails are sent do not follow the logic you have described above:

Here is my test case for the 'program due' email reminder:

I have a program with a fixed due date of 31st Jan 2014
I have one course that needs to be complete each month until the end of the program. E.G a June course, a July Course, Aug course....
I have program due emails setup for each month, I.E 2 months before the due date, 3 months before due date etc... and each email corresponds to the course that is included in that month. I.E users should get a email on the last day of the month reminding them or the next months course.
- Expected result: Users should be getting an email once a month either on the last day or the first day of the month depending on when the cron runs.
- Actual result: I receive the email on the 6th of the month

Here is my test case for the 'course set due' email reminder:

Using the same program as above, I have a program due date for the program of the 31st of Jan 2014,
I have a number of courses, each in their own set and each with a 1 month minimum time.
I then have three course set due reminder emails setup: one for 15 days before the course set is due, one for 7 days before the course set is due, and a third for 2 days before course set is due.
- Expected result: Users should be getting an email 3 times a month, the first at about the 15th, the 2nd at about the 22nd and the 3rd at about the 28th.
- Actual result: I have not run a full month of tests however I just received the email that should be sent on the 15th on the 2nd of the month.
Additional Question: how do course set due email reminders work, and what is the logic behind these?

Permalink | Show parent | Reply

Hmmm, I was looking at program due/overdue. I'll have to have a look at the courseset completion messages, though your expected results do sound like how it should be working. I'll get back to you after I've had a rummage around in the code.

Though I should mention, 1 month is always 30 days. So it could throw you off a day or two sometimes (not 5-6 though).

Permalink | Show parent | Reply

Ahh, the answer to the first half of your post actually is the always 30 days thing. If you have a program spanning 1 year and are sending a message 6+ months before due, then each month that is actually 31 days it will put you off your expected date by another day.

Permalink | Show parent | Reply

Great that does make sense if months are 30 days.

Solution to the program due email: Therefore instead of having the messages based on months E.G 3 months before Due date, ill use days, I.E 92 days before due date. that should work.

I look forward to the course set information.

Regards
Bodo

Permalink | Show parent | Reply

Hi David,

In addition to the information you are pulling together about the Course set Due messages and how they work, can you also explain if the messages will be sent even if the user has completed the Course Set before the reminder is sent.

E.G I have already completed the courses in the course Set and I still received a reminder message for that set, is this intended?

Regards
Bodo

Permalink | Show parent | Reply

Hi Bodo.

David isn't on support at the moment so he asked me to look into this. I'm fairly new, so it took a bit to figure it out. Here's the observations that I've made relating to Course Set Due messages.

Once a course set is complete, the user will be enrolled in the following course set after the nightly cron. The due date for this new course set is set to the specified duration after the course set begins, not relative to when the previous course set would have ended. An example should make things clearer (assume one month = four weeks):

We have two course sets. Each course set has a one month minimum time required. This means that the user must be allowed at least two months (eight weeks) to complete the program. We set up a course set due message to trigger one week before each course is complete (so we would expect them to be delivered at the end of weeks three and seven). We also set up a course set overdue message for one week after they are due. A user is assigned to the program on the first day of the first month and we allow them two months (eight weeks) to complete the program. The user completes the first course after two weeks. They will be enrolled in the second course set during the next nightly cron, so the next day they can start the second course. Five weeks after starting the program (three weeks after starting the second course) they receive a course set due message, letting them know that the second course set is due in one week. Two weeks later (after a total of seven weeks) they receive a one week overdue message.

I think this could be enough to explain what happened in your test case for course set due email reminders. If you created two one-month course sets, enrolled a user at the start of the first month, jumped to day 16 and got the 15 day email warning, completed the first course set, jumped to day 2 of the second month and received another 15 day warning (with no other warnings in between).

I'm pretty sure that this is how it works, but I could be wrong. If you observe something different then please let David and I know and we'll try to work out what's happening.

Nathan

Permalink | Show parent | Reply

Hi Bodo,

The first login date only counts after assignment.

Have you checked that the audience is actually being populated under the "members" tab?

What are the alert setting is set to on this page message/edit.php?id=8?

If the email isn't ticked for when I'm offline/online it may not send the email.

hope this helps,

George.

Permalink | Show parent | Reply