Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

dev/mail#11 Add pre/post hook for CRM_Mailing_BAO_MailingJob #12231

Closed
wants to merge 1 commit into from

Conversation

monishdeb
Copy link
Member

@monishdeb monishdeb commented May 29, 2018

Overview

This PR adds pre/post hook for CRM_Mailing_BAO_MailingJob

Before

  1. No pre/post hook call on CRM_Mailing_BAO_MailingJob create or delete
  2. No delete fn present
  3. Directly call CRM_Mailing_BAO_MailingJob object to save/delete mailingJob record.

After

  1. Call the pre/post hook inside CRM_Mailing_BAO_MailingJob::create()
  2. Add CRM_Mailing_BAO_MailingJob::deleteMailingJob to delete Mailing Jobs and add pre/post delete hook
  3. Replace all the DAO call with corresponding create and delete fn in the codebase.

@eileenmcnaughton
Copy link
Contributor

@monishdeb your PR conflicts with #12221 - which extends unit testing to MailingJob.

I've added your hook into that PR so assuming the tests pass on it if we can get that merged you can drop your changes to MailingJob.create from this PR

@eileenmcnaughton
Copy link
Contributor

I also added a couple of your changes in where they are in the same class & are changing from save to create

$saveJob->save();
$jobParams = array(
'id' => $job->id,
'start_date' => date('YmdHis'),
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this is wrong - but fixed in my PR where I incorporated this change (start_date vs end_date)

@monishdeb monishdeb force-pushed the dev_mail_11 branch 2 times, most recently from 4b8ce27 to 088eb27 Compare May 30, 2018 04:36
@monishdeb
Copy link
Member Author

@eileenmcnaughton I have rebased my PR, can you please check now?

*
* @return mixed
*/
public static function deleteMailingJob($id) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can see on Mailing the function is called 'del' - I think that is kind of the standard & what the api calls?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

oops that was my mistake, changed it now :)

@monishdeb
Copy link
Member Author

Thanks @eileenmcnaughton for notifying the delete function, renamed it to del

@eileenmcnaughton
Copy link
Contributor

OK - I don't have any concerns about this now - I'll go through it more carefully once the tests pass

@monishdeb monishdeb force-pushed the dev_mail_11 branch 2 times, most recently from 9eba82d to 84b65d6 Compare May 31, 2018 19:31
// Keeping former behaviour when an id is present is precautionary and may warrant reconsideration later.
'status' => ((empty($params['is_completed']) || !empty($params['id'])) ? 'Scheduled' : 'Complete'),
'is_test' => 0,
'_skip_evil_bao_auto_recipients_' => TRUE,
Copy link
Member Author

@monishdeb monishdeb Jun 1, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@eileenmcnaughton I need to introduce a new parameter here because there need to be some flag which should prevent mailingJob::create to trigger recipient rebuild, as required here.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@monishdeb arg. @totten do you think we can start to grandfather to building recipients being opt-in not opt out?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

what about we go with is_create_recipients (ideally if not set it's false, but at least a deprecated warning if not set & set in the api). I feel like we could probably find the places where MailingJob::create are currently called?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just a note - I checked the already merged changes & there is no case where 'mailing_id' is passed in our 'newly-calling create function' params - so we should be safe from any issues in the already-merged changes

* Delete Jobss and all its associated records
* related to test Mailings
* @deprecated
* Use CRM_Mailing_BAO_MailingJob::del($id)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you pull this delete part into a PR I should be able to merge that pretty quickly

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done, extracted del codes in separate PR #12275

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ok -that is merged - we can rebase this

@eileenmcnaughton
Copy link
Contributor

is this rebased?

@eileenmcnaughton eileenmcnaughton added the sig:extension support Supports being able to integrate extensions with CiviCRM label Jun 8, 2018
@seamuslee001
Copy link
Contributor

@eileenmcnaughton i think this has been rebased now and are you planing to review this one?

@monishdeb
Copy link
Member Author

monishdeb commented Oct 10, 2018

@eileenmcnaughton I have rebased it earlier, sorry for notifying late. Can you please review and merge this PR?

@seamuslee001
Copy link
Contributor

Jenkins re test this please

$saveJob->end_date = date('YmdHis');
$saveJob->status = 'Complete';
$saveJob->save();
self::create([
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

so this WILL generate a recipients list...

@eileenmcnaughton
Copy link
Contributor

@monishdeb I took another look at this - I can see a spot where recipients are being generated where they shouldn't be - I think we should figure out how to grandfather

  CRM_Mailing_BAO_Mailing::getRecipients($params['mailing_id']);

out of MailingJob ::create - given it's done by the BAO_Mailing anyway

@eileenmcnaughton
Copy link
Contributor

OK - so this WILL create unwanted getRecipient calls as it stands - unless you are excited about bringing this back to life after so long I think we should try to deprecate that getRecipient stuff for a few cycles & then remove it & then re-attempt this

@eileenmcnaughton
Copy link
Contributor

@monishdeb I'm going to close this as I think we need to deprecate that call to create mailing recipients out of MailingJob create first - I think this is the next step

https://github.com/civicrm/civicrm-core/compare/master...eileenmcnaughton:mailin_test?expand=1

@monishdeb
Copy link
Member Author

monishdeb commented Feb 24, 2019

@eileenmcnaughton can I reopen this PR after that other PR is merged? because this is a paid issue for NYSS

@eileenmcnaughton
Copy link
Contributor

@monishdeb sure - I just think this PR as is is stalled & won't really be unstalled until we resolve the other - i didn't actually turn the above into a PR but if you want to I'll merge it - it's the best approach I can think of to grandfather the other out - I think we can get to the point of deprecating the functionality for 5.12 & then in some later version resolve the rest

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
master sig:extension support Supports being able to integrate extensions with CiviCRM
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants