-
-
Notifications
You must be signed in to change notification settings - Fork 825
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/core#905 Separate contribution_recur status_id option group from contribution option group #14343
dev/core#905 Separate contribution_recur status_id option group from contribution option group #14343
Conversation
(Standard links)
|
@eileenmcnaughton don't we need the updated generated_data.sql? |
@seamuslee001 good question - I guess I run setup.sh? |
@@ -241,7 +241,7 @@ | |||
<import>true</import> | |||
<add>1.6</add> | |||
<pseudoconstant> | |||
<optionGroupName>contribution_status</optionGroupName> | |||
<optionGroupName>contribution_recur_status</optionGroupName> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
need to run ./bin/setup -g
to update the DAO
99e56ab
to
e6279dd
Compare
Cool done. |
test this please |
@eileenmcnaughton Thoughts added to the gitlab issue. Summary: Yes, but we need more thought on the options we provide before merging. |
test this please |
e6279dd
to
70e12d9
Compare
@mattwire I've altered this to NOT add the new status. I feel like this would be better merged as a PR that just adds the group & I can follow up & add the statuses. I think we have agreed on them but it feels like a separate PR would be cleaner |
70e12d9
to
6c2643f
Compare
Good idea, for reasons already well noted, and I support the implementation strategy. I'm only confused about the note about removing the "In Progress" status - are you talking about removing that from the non-recurring payment status? |
@adixon when I wrote that I believed that 'In Progress' was relevant to pledges & recurring contributions - but not actual contributions. So I thought that with neither of those entities sharing the contribution status option group anymore it would not be needed in that group (I have seem it cause some confusion). However after doing some other stuff in BAO_Contribution yesterday I realise it IS referenced in there for contribution handling so I think I was wrong |
@@ -1 +1,11 @@ | |||
{* file to handle db changes in 5.15.alpha1 during upgrade *} | |||
--dev/core#905 Add contribution recur status option group | |||
INSERT INTO `civicrm_option_group` ( `name`, {localize field='title'}`title`{/localize}, `is_active` ) VALUES ('contribution_recur_status', {localize}'{ts escape="sql"}Contribution Recur Status{/ts}'{/localize}, 1); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Contribution status option group has is_reserved and is_locked to TRUE, should this option should have same value for those fields?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@pradpnayak yes, thank you - I will fix!
@@ -212,6 +212,7 @@ VALUES | |||
('wysiwyg_presets' , '{ts escape="sql"}WYSIWYG Editor Presets{/ts}' , NULL, 1, 1, 0), | |||
('relative_date_filters' , '{ts escape="sql"}Relative Date Filters{/ts}' , NULL, 1, 1, 0), | |||
('pledge_status' , '{ts escape="sql"}Pledge Status{/ts}' , NULL, 1, 1, 1), | |||
('contribution_recur_status' , '{ts escape="sql"}Recurring Contribution Status{/ts}' , NULL, 1, 1, 1), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Label is different here v/s in upgrade script.
…contribution option group As we did earlier for pledge status this separates out the option groups - on the basis we have different statuses for the 2 things. In order to ensure we don't break anything existing the values we give the new option group the exact same values as the old one> However, I HAVE added one more value - Processing - which is intended for the period between when a new contribution starts to be added and when it has been added. This would normally be a few seconds but when there is an error it would be left in this state - warding off future attempts. For new sites I have left off some statuses that I think would not be relevant - Refunded, Partially Paid, Chargeback, Pending Refund
2794852
to
0dc36ab
Compare
@pradpnayak thank you ! I think I've fixed those now |
Tested this PR on fresh install and upgrade. On upgrade - New recurring contribution status option group is created with options of Contribution status copied over. The options doesn't match on Fresh install v/s upgrade since on fresh install it creates 6 options while during upgrade it creates 10 options(by default contribution statuses). This does make sense inorder to keep the consistency of option.value. Good to merge. |
test this please |
2 similar comments
test this please |
test this please |
@eileenmcnaughton : the tests have all passed. |
@yashodha I think it's good to merge - I kept all the stuff that might need discussion for a follow up PR - which I'll do once this is merged |
Overview
No user impact, splits contribution recur status option group from contribution
Before
One option group shared
After
Two separate ones
Technical Details
As we did earlier for pledge status this separates out the option groups - on the basis we have different statuses for the 2 things. In order to ensure we don't break anything
we give the new option group the exact same values as the old one
For new sites I have left off some statuses that I think would not be relevant - Refunded,
Partially Paid, Chargeback, Pending Refund
Comments
@mattwire @monishdeb @pradpnayak @adixon input welcome!
A couple of follow up notes
https://lab.civicrm.org/dev/core/issues/905