Skip to content

Add post processor to run custom actions - #557

Open
dontub wants to merge 1 commit into
managed-entitiesfrom
custom-action-post-processor
Open

Add post processor to run custom actions#557
dontub wants to merge 1 commit into
managed-entitiesfrom
custom-action-post-processor

Conversation

@dontub

@dontub dontub commented Aug 27, 2026

Copy link
Copy Markdown
Contributor

Currently the new post processor can perform custom APIv4 calls. There can be made more types of actions possible through implementations of \Civi\Banking\PostProcessor\CustomAction\CustomActionHandlerInterface.

TODO: Documentation

systopia-reference: 32247

@dontub
dontub force-pushed the custom-action-post-processor branch 2 times, most recently from 8143e7d to cfa3606 Compare August 27, 2026 14:12
Currently the new post processor can perform custom APIv4 calls. There
can be made more types of actions possible through implementations of
`\Civi\Banking\PostProcessor\CustomAction\CustomActionHandlerInterface`.
@dontub
dontub force-pushed the custom-action-post-processor branch from cfa3606 to 5d4f506 Compare August 27, 2026 14:22
@dontub

dontub commented Aug 27, 2026

Copy link
Copy Markdown
Contributor Author

There's currently a phpstan error:

------ ------------------------------------------------------------------------------ 
  Line   CRM/Banking/PluginImpl/PostProcessor/MembershipExtension.php                  
 ------ ------------------------------------------------------------------------------ 
  458    Cannot access offset 'memberships' on array{memberships: list<mixed>}|false.  
         🪪  offsetAccess.nonOffsetAccessible                                          
 ------ ------------------------------------------------------------------------------

It's actually not a new issue. It should be checked, though I'm currently not sure what the intended behavior was when $result gets overridden with FALSE.

Another thing that I don't really understand: Strings saying a post processor might have been executed.

* NULL when it might have been executed.

return E::ts('%1 might have been executed.', [1 => $this->getName()]);

I'd suggest making \CRM_Banking_PluginModel_PostProcessor::shouldExecute() public and call it in \CRM_Banking_Matcher_Engine::runPostProcessors() before the call of \CRM_Banking_PluginModel_PostProcessor::processExecutedMatch()
and in \CRM_Banking_Matcher_Engine::previewPostProcessors() before the call of \CRM_Banking_PluginModel_PostProcessor::previewMatch(). (The latter should only be called if shouldExecute() returns TRUE.) If \CRM_Banking_PluginModel_PostProcessor::processExecutedMatch() was called then, a post processor was actually executed. This would also avoid the necessity of each implementation calling shouldExecute().

@dontub
dontub requested a review from jensschuppe August 27, 2026 14:25
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant