Repost alert

[shreyas-satish]

Hasjob introduced reposting in #212. Hasjob should go one step further and send an email alert to job posters whose job post recently expired. This would help encourage them to repost their job if the position is still available.

Caveat: Should job posts that were newly posted be shown prior to job posts that were reposted?

[jace]

Caveat: Should job posts that were newly posted be shown prior to job posts that were reposted?

This is a separate discussion in #127.

[shreyas-satish]

TODO:

• Design for the email template
• Copy for the email template
• Add the template to the repo
• Add a feedback form
• Cron job (or an equivalent) that sends the email alert
• Test the entire workflow
• Measure the number of opens, clicks, reposts and % change in monthly job inventory

[shreyas-satish]

Can an employer indicate that they have hired for that role? JobPost has a status called Closed but it doesn't necessarily imply that the role was hired for.

If the role was filled, was it filled via Hasjob? If not, what else worked? How could Hasjob have worked better for them? I think we should capture this feedback as well.

[iambibhas]

Managing celery is a pain. We can use cronjob for this. Can write a manage.py command and call it every minute.

The jobs will require a flag to show that the repost reminder mail has been sent. Any idea how to implement that?

• Add a flag on the jobpost itself repost_notification_sent=False and after 30 days, when the job expires, we send notification and set it to True. Once the job's been reposted, we set it to False again.
• Think about an elaborate way to store notification settings and history in a separate model maybe?

[shreyas-satish]

Can write a manage.py command and call it every minute.

Why does it have to be called every minute? Once a day should suffice?

The jobs will require a flag to show that the repost reminder mail has been sent.

Why is it necessary to store this notification? If there's an error, there will be an exception raised so we'll know something went wrong?

[jace]

Hasjob already has a periodic cronjob that is called every 5 minutes. Look in manage.py. Add to it.

[jace]

Why is it necessary to store this notification? If there's an error, there will be an exception raised so we'll know something went wrong?

Status must be kept. The periodic job is not guaranteed to run if there is server downtime. On every run, we query for items (a) older than a certain date (30 days) and (b) without the notification flag set.

[shreyas-satish]

If it's necessary to store the notification, I suggest adding a flag called repost_notification_sent_at which stores the datetime of when the notification was sent.

What's also important to track:

• How many job posts were reposted?
• And how often are they reposted?

I suggest adding a source_id to JobPost which will let us track these two metrics.

[iambibhas]

@shreyas-satish what is source_id?

[shreyas-satish]

id of the previous JobPost instance which is being reposted as a new job post.

[shreyas-satish]

If you have a job post X, which is being modified and reposted as Y, a source_id on Y establishes its history to X.

[iambibhas]

Ok. Got it. Can we call it original_post_id or something similar and verbose?

[jace]

See #84 for the current implementation. The alert merely sends out a link to the repost feature that #84 implemented. Any deficiencies in its implementation should be addressed by re-opening #84.

[iambibhas]

Hasjob already has a periodic cronjob that is called every 5 minutes. Look in manage.py. Add to it.

Found them. Thanks.

[shreyas-satish]

Can we call it original_post_id or something similar and verbose?

original can be mis-leading since a job post may have multiple versions, and the previous version may not be 'original'. Each job post should only store a link to the previous version, so previous_id or source_id should be okay, in my opinion.

[iambibhas]

@shreyas-satish yeah. previous_id sounds good. I'll start working on it then?

[jace]

@iambibhas Please close your other PRs before proceeding with this. This one is not a trivial issue.