Automattic\WooCommerce\Internal\PushNotifications\Notifications

Notification::should_send_to_user │ public │ WC 10.9.0

Decide whether this notification should be delivered to a user given their stored preference value for {@see static::get_type()}.

$pref_value is whatever the user has stored under this notification type's preference key, or null if they have nothing stored. The NotificationPreferencesService{} stores each preference as an object so future sub-fields (thresholds, sub-toggles) can be added without bumping the schema version — today's shape is ['enabled' => bool], future shapes might add e.g. ['enabled' => true,'min_value'=> 500] for an order threshold.

Default: read the universal enabled sub-field, defaulting to true when the value is missing or has no enabled key (so newly-added notification types are opt-in by default). Subclasses override to read richer sub-fields and to consult their own resource (e.g. compare an order total to the user's min_value).

Subclasses must keep this side-effect-free — the NotificationProcessor{} may call it once per recipient user per notification.

Method of the class: Notification{}

No Hooks.

Returns

true|false. True if this notification should be sent to that user.

Usage

$Notification = new Notification();
$Notification->should_send_to_user( $pref_value ): bool;

$pref_value(mixed) (required)

The user's stored preference value, or null.

Changelog

Notification::should_send_to_user() Notification::should send to user code ^{WC 10.9.4}

public function should_send_to_user( $pref_value ): bool {
	if ( null === $pref_value ) {
		return true;
	}

	if ( is_array( $pref_value ) ) {
		return (bool) ( $pref_value['enabled'] ?? true );
	}

	// Defensive fallback for unexpected scalar values; the service
	// always normalises stored prefs to the array shape above.
	return (bool) $pref_value;
}