This PR adds a new field for Membership Type Configuration. The field will only appear when Membership Type Plan is set to fixed
The PR also refactors existing code that extended Membership Type, add unit tests and more details will be in Technical Details section.
Before
Annual Pro-rata calculation field did not exit.
After
Annual Pro-rata calculation field extends Membership Type
Technical Details
Previously, membership type colour field was already extended to Membership type and store the settings in civicrm_settings table. This method allows settings to be extended on each membership type without having to create another table. However, the setting key that was used membership_type_colour and it does not make sense to store additional settings (this in case we add only 1 setting) into the same key.
The new setting key called membership_extras_membership_type_settings created to use for storing new settings on each membership type. The new code and the design allow us to extend as many fields as we want in the future without having to create a new class or new setting if we would like to add more fields.
Unit tests have also been added to BuildForm hooks and PostProces hooks.
Why don't we use the new settings hook for the existing colour field?
Since the field is already exist and the client may already use this feature, in order to merge the field to the new settings hook is to migrate the data too, I would like to minimize the scope of this PR to just adding fields and decouple the code and leave the complexity of migration data to discuss in later stage
Overview
This PR adds a new field for Membership Type Configuration. The field will only appear when Membership Type Plan is set to fixed
The PR also refactors existing code that extended Membership Type, add unit tests and more details will be in Technical Details section.
Before
Annual Pro-rata calculation field did not exit.
After
Annual Pro-rata calculation field extends Membership Type
Technical Details
Previously, membership type colour field was already extended to Membership type and store the settings in civicrm_settings table. This method allows settings to be extended on each membership type without having to create another table. However, the setting key that was used
membership_type_colourand it does not make sense to store additional settings (this in case we add only 1 setting) into the same key.The new setting key called
membership_extras_membership_type_settingscreated to use for storing new settings on each membership type. The new code and the design allow us to extend as many fields as we want in the future without having to create a new class or new setting if we would like to add more fields.Unit tests have also been added to BuildForm hooks and PostProces hooks.
Why don't we use the new settings hook for the existing colour field?
Since the field is already exist and the client may already use this feature, in order to merge the field to the new settings hook is to migrate the data too, I would like to minimize the scope of this PR to just adding fields and decouple the code and leave the complexity of migration data to discuss in later stage