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

CRM-21316 Additional fix. Set default provider when creating SMS. #11628

Closed

Conversation

JKingsnorth
Copy link
Contributor

@JKingsnorth JKingsnorth commented Feb 5, 2018

Fix a regression in CRM-21316 whereby the recipients for a mass SMS are not build correctly. This is because the SMS provider is not set when the getRecipients function is called.

As discussed in #11558


@JKingsnorth JKingsnorth force-pushed the CRM-21316-default-sms-provider branch from 7fab0bc to 3a2a1b3 Compare February 6, 2018 10:10
@JKingsnorth JKingsnorth changed the title [DNM] Crm 21316 default sms provider CRM-21316 Additional fix. Set default provider when creating SMS. Feb 6, 2018
@JKingsnorth
Copy link
Contributor Author

@eileenmcnaughton @monishdeb As discussed in #11558 this is the last fix for the regressions in the mailing tool.

@eileenmcnaughton
Copy link
Contributor

@monishdeb do we need this in the rc?

@monishdeb
Copy link
Member

monishdeb commented Feb 8, 2018

Yeah, actually this is a regression as explained in the 3rd point of this comment where due to refactoring we don't pass any $mode = sms/mailing parameter to fetch recipients. Now the only decisive factor that tell BAO function, about its mode is the $mailingObj->sms_provider_id

However, as per the patch is concern, I differ a bit. Since now sms_provider_id is a crucial attribute to fetch recipients, why can't we make this field required and move the set-default code from postProcess to setDefaults ?

So I will be going to create a 4.7.31-rc PR for this.

@eileenmcnaughton
Copy link
Contributor

@monishdeb branching has not happened yet - got late & tim will do in the morning so depending on timing / confidence it will be master

@monishdeb
Copy link
Member

cool .. then let me submit a PR shortly against master :D

@monishdeb
Copy link
Member

I have submitted a PR #11656 with alternative solution. Please have a look

@eileenmcnaughton
Copy link
Contributor

@JKingsnorth @monishdeb the alternate was merged - do we still want this one?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants