The RelatedID mapping is incredibly powerful, but also complicated. We have regular use cases where there are "incomplete" objects in Salesforce that we don't want to pull up. For example, campaign memberships for contacts that don't have email addresses. We block contacts with no emails from pulling into Drupal, but their campaign memberships try to pull up anyway. Those matching entities in Drupal can't exist without a person on the other end, so we keep writing versions of the same pullPrepull subscriber to block these records until their related item has a corresponding Drupal entity.
I'd like to be able to enable this very specific behavior with a checkbox on the field mapping.
The attached patch provides this facility, and opens the door to other field-level mapping behaviors using interfaces.
After applying this patch, you'll see a checkbox "Confirm Drupal Endpoint Exists" on RelatedID field mappings. Check the box, and any attempts to update or create Drupal records from Salesforce before the related object exists will be rejected, and a warning written to the logs.
| Comment | File | Size | Author |
|---|---|---|---|
| #10 | 3276564_relatedID_pull_disallow-10.patch | 8.23 KB | gcb |
| #9 | 3276564_relatedID_pull_disallow-9.patch | 8.57 KB | gcb |
| #8 | 3276564_relatedID_pull_disallow-8.patch | 7.99 KB | mariacha1 |
| #5 | 3276564_relatedID_pull_disallow-5.patch | 7.98 KB | gcb |
| #2 | 3276564_relatedID_pull_disallow-2.patch | 7.18 KB | gcb |
Show commandsStart within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
changes
Comments
Comment #2
gcbComment #5
gcbPatching adding schema changes and fixing tests.
Comment #6
aaronbaumanOooh, neat idea.
So, just to make sure i understand, given the example in OP:
if
- "Confirm Drupal endpoint exists" is checked for the CampaignMember.Contact mapping field
- and Contact hasn't been synced to Drupal
then:
- abort CampaignMember pull
Is that right?
I think the name is tricky.
To me, "Confirm Drupal endpoint exists" does not quite explain what is happening.
Maybe there could be a "description" text as well?
Something like "Prevent pull if the referenced record does not exist in Drupal"?
Any additional wordsmithing would appreciated.
Also a test or two would be good.
Comment #7
gcbOk, labeling improved, and also a fix for the form behavior. Tests aren't here yet but let me know what you think of this UX language!
Comment #8
mariacha1 commentedThe value of the field, when checked, is true, not "match", which is preventing the code from running.
I'm including a patch to fix that.
Comment #9
gcbRe-rolled patch for 5.0.3
Comment #10
gcbAnother re-roll against 5.0.4
Comment #11
gcbComment #12
aaronbaumanHave you been using this patch in production?
The annoying thing with "disallow pull" is that it doesn't get automatically retried, ever.
So, even if the parent SFID does eventually get created, it won't trigger another pull attempt for the child record.
This is somewhat tangential, and shouldn't block this patch, but something to consider for folks that want to use this feature.
Comment #13
gcbAre you talking about the queue item permanently being disallowed, or somehow the specific SF ID itself permanently getting disallowed? Because the latter is definitely a problem! The former doesn't seem so bad, although it would certainly be nice if it allowed some retries -- I can easily imagine cases where a retry would be likely to sync successfully. If that's the case, we could look at a different type of sync rejection. Maybe "postponePull"?
Comment #14
aaronbaumanI'm talking about the situation where a subscriber might want to postpone pull.
The "disallowPull" method doesn't support this, outside of manually forcing another pull attempt.
There's no permanent disallow that i know of...
Comment #15
aaronbaumanThis is good to go i think.
Also opened related issue #3529409: Improve pull queue exception handling and subscriber options
Comment #17
aaronbaumanMerged, thanks for your work
Comment #20
gcb@aaronbauman thanks for merging, and sorry about dropping the convo here!