During pull queue processing, would be useful for event subscribers to prevent a pull without throwing an exception - analogous to push allowed in salesforce_push module.

Comments

AaronBauman created an issue. See original summary.

aaronbauman’s picture

Status: Active » Needs review
StatusFileSize
new4.96 KB

Status: Needs review » Needs work

The last submitted patch, 2: salesforce-pull_allowed-3038688.patch, failed testing. View results

aaronbauman’s picture

Status: Needs work » Needs review
StatusFileSize
new7.42 KB

Fixes the failing tests

acrosman’s picture

StatusFileSize
new6.22 KB

Re-roll of previous patch to remove changes to DeleteHandlerTest.php as they appear to have been applied in commit 5754cfb3d77738204bbe32d9fa2860b7cff8b263.

acrosman’s picture

I've been using this for a bit and it is really helpful, but there are a couple challenges that make sense to me to adjust either here or as a new issue feature request.

First this functionality is not a true analog of PushAllow since this extends the PrePull event to provide the mechanism, where PushAllow is its own event. Both approaches have merit, and it might make sense to have both directions provide both options: a focused event that fires like the PushAllow does now, and a combined event that allows the behaves like the PrePull and provides for disallowing the action to continue.

The next disallow process is rather absolute, and a middle ground of re-queue to try again later would be nice. I recognize there are other ways to achieve this behavior now, but it seems reasonable to include it as an option with the allow events. Basically a "don't allow right now, try again later". At the moment it appears that once you disallow a pull or push you need to use another mechanism to re-trigger that attempt.

The use cases here would be for mappings that work with related entities like Paragraphs which are hard to get to fire in the right order and may need to wait until the parent entity has been pushed before upserting itself but in other cases could go right away (so always putting on an async queue isn't ideal). The same may be true in the reverse depending on the various delays in Drupal's cron runs and mapping timings that a child object would be discovered for pull before the required parent has arrived.

  • AaronBauman committed 2486ee8 on 8.x-3.x authored by acrosman
    Issue #3038688 by AaronBauman, acrosman: Add "pull allowed", analogous...
  • AaronBauman committed f16bf66 on 8.x-4.x authored by acrosman
    Issue #3038688 by AaronBauman, acrosman: Add "pull allowed", analogous...
aaronbauman’s picture

Status: Needs review » Active

Commited this version.
Reset to "active" for additional changes.

aaronbauman’s picture

Status: Active » Closed (won't fix)

8.x is no longer supported

Now that this issue is closed, review the contribution record.

As a contributor, attribute any organization that helped you, or if you volunteered your own time.

Maintainers, credit people who helped resolve this issue.