Permit multi-record custom field sets to extend any entity (in theory) #27549
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
🤖 Thank you for contributing to CiviCRM! ❤️ We will need to test and review this PR. 👷 Introduction for new contributors...
Quick links for reviewers...
|
colemanw
commented
Sep 21, 2023
Comment on lines
-334
to
-341
| if ($extends == 'Relationship' && !empty($this->_subtypes)) { | ||
| $relationshipDefaults = []; | ||
| foreach ($defaults['extends'][1] as $donCare => $rel_type_id) { | ||
| $relationshipDefaults[] = $rel_type_id; | ||
| } | ||
|
|
||
| $defaults['extends'][1] = $relationshipDefaults; | ||
| } |
There was a problem hiding this comment.
This is why the PR manages to add functionality and metadata while not overall increasing SLOC. I deleted a bunch of code like this which:
- Does nothing.
- Has done nothing for over a decade.
- Looks scary so everyone was afraid to touch it.
colemanw
force-pushed
the
customFields
branch
from
c500ef9 to
70641ae
Compare
|
@colemanw this seems to mostly work. I did find one issue which is I was just testing changing the Entity type around and if I selected Participants, then elected Role or Event name or some sub. Then changed the entity to be Contacts the extends select box still shows
|
…i-record custom fields This is still only enabled for contacts, but now the switch could be flipped for other entities. Refactors the custom group form to be metadata-driven & respect the new setting (and cleanup lots of cruft).
colemanw
force-pushed
the
customFields
branch
from
70641ae to
a641291
Compare
|
Thanks @seamuslee001 - fixed now. |
colemanw
force-pushed
the
customFields
branch
2 times, most recently
from
a641291 to
0129a2e
Compare
|
ok seems to work correctly now on my local merging |
This was referenced Dec 14, 2023
colemanw
changed the title
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Overview
Permits any entity to have multi-record custom field sets, by improving the underlying metadata.
Before
Multi-record custom sets were hardcoded in multiple places as "Contact only".
Crufty form for saving custom fieldsets.
After
Metadata exists about which entities support multi-record custom sets. This is still only enabled for contacts, but now the switch could be flipped for other entities.
Refactors the custom group form to be metadata-driven & respect the new setting (and cleanup lots of cruft). UX much nicer.
Comments
The motivation was to improve metadata, but it turned into a big cleanup project.