Related / Inherited Memberships: Custom fields not filled with data

[kainuk]

Overview

In CiviCRM, a membership can be for a group of contacts that are connected by relationships. For example a household, or cooperation. One of them has a master membership. The membership of the others is derived from the master membership. Any change in the master membership must be copied to the other memberships. Unfortunately, this does not for custom fields. This issue is described on https://lab.civicrm.org/dev/core/issues/1365

Before

On updating the custom fields of the master membership are changed in the update, the others are left behind.

After

The custom fields of every membership follow the master, as expected.

Technical Details

In the code, there is an effort to do all the custom fields. Part of the strategy was to unset the technical keys of the custom field. But the custom field was stored in an array instead of a single value. So that is corrected.

[civibot]

(Standard links)

• If this is your first pull-request for CiviCRM, please browse CONTRIBUTING.md for information about the development and testing processes.
• If you are reviewing this pull-request, you may wish to consult the test sites and the Review Standards (long template, short template).

[jaapjansma]

We (Betty and I) have tested the following:

1. Create a membership type with a related membership (in the test environment we used the General)
2. Create a custom group at the membership General and add a custom field to this group
3. Create a household
4. Create a new individual and link this to the household
5. Create a new General Membership at the household and at a value at the custom field
6. Check at the head of household membership the custom field of the membership is filled: OK
7. Go to the household and change the custom field at the membership
8. Check at the head of household membership the custom field of the membership should be changed: Failed

Our advice is that this PR should also fix the issue mentioned in step 8.

@kainuk are you able to fix this as well?

[jaapjansma]

Betty and I are reviewing PR's and we checked it again with @kainuk and we could not reproduce the steps above.

• General standards
  • Explain (r-explain)
    • PASS : The goal/problem/solution have been adequately explained in the PR and in the issue.
  • User impact (r-user)
    • PASS: The change would be intuitive.
  • Documentation (r-doc)
    • PASS: The changes do not require documentation.
  • Run it (r-run)
    • PASS: We have tested it and it works
• Developer standards
  • Technical impact (r-tech)
    • PASS: The change preserves compatibility with existing callers/code/downstream.
  • Code quality (r-code)
    • PASS: The functionality, purpose, and style of the code seems clear+sensible.
  • Maintainability (r-maint)
    • PASS: The change is trivial enough that it does not require tests.
  • Test results (r-test)
    • PASS: The test results are all-clear.

@mattwire or @eileenmcnaughton are you able to merge this PR?