Issue #3369035: Notification entity conditions can not rely on other template configuration

[Kingdutch]

Problem

Entity conditions are executed in ActivityLoggerFactory::createMessages before some of the other checks are evaluated. This can cause an entity condition that may only be usable on specific bundles to be called on other data.

Solution

We re-order the checks so that we check for matching properties first and only at the end execute the more expensive entity condition plugins. This also makes it easier to move the conditions into a database query when we move into a different configuration structure in the future.

Note: a nicer solution would be to make the conditions a more cohesive whole, but that's too big a change for now, so we just change the evaluation of conditions from generic (e.g. bundle) to specific (condition on data of the entity) to make our developer lives easier.

Issue tracker

https://www.drupal.org/project/social/issues/3369035

How to test

Discovered and covered with #3384

• Create a new ActivityEntityCondition plugin that assumes it receives an entity of a specific bundle
• Create a notification that applies to that specific bundle in activity_bundle_entities and uses the condition in activity_entity_condition
• Trigger any notification

Without the change you'll see that the ActivityEntityCondition plugin you created crashes the notification process because the condition is executed for entities it won't care about

After the change the condition is only called if the other fields on the notification template matches.

Definition of done

Before merge

• Code/peer review is completed
• All commit messages are clear and clean. If applicable a rebase was performed
• All automated tests are green
• Functional/manual tests of the acceptance criteria are approved
• All acceptance criteria were met
• New features or changes to existing features are covered by tests, either unit (preferably) or behat
• Update path is tested. New hook_updates should respect update order, right naming convention and consider hook_post_update code
• Module can be safely uninstalled. Update/implement hook_uninstall and make sure that removed configuration or dependencies are removed/uninstalled
• This pull request has all required labels (team/type/priority)
• This pull request has a milestone
• This pull request has an assignee (if applicable)
• Any front end changes are tested on all major browsers
• New UI elements, or changes on UI elements are approved by the design team
• New features, or feature changes are approved by the product owner

After merge

• Code is tested on all branches that it has been cherry-picked
• Update hook number might need adjustment, make sure they have the correct order
• The Drupal.org ticket(s) are updated according to this pull request status

Release notes

For developers: EntityCondition's for notifications are no longer checked if any of the other conditions of a template does not apply.

[mergeable]

Thanks for contributing towards Open Social! A maintainer from the @goalgorilla/maintainers group might not review all changes from all teams/contributors. Please don't be discouraged if it takes a while. In the meantime, we have some automated checks running and it might be that you will see our comments with some tips or requests to speed up the review process. 😊

[ronaldtebrake]

Given it's covered in #3384 i'm happy to see this go in already! 🙏