Hello @LeonidS,

Thank you for checking. I want to clarify the issue more precisely, because I think the problem may not be the normal on-site notification display, but specifically the push notification recipient generation/privacy check for posts created in a private group context.

My setup:

• UNA site: Scrubdin
• Group module: private/secret group
• Posting method: native Create Post (Context) block inside the group page
• Post type creates notification events as:
• bx_notifications_events.type = bx_timeline
• action = post_common
• owner_id = 61
• owner profile type = bx_groups
• object_owner_id = 3
• object_privacy_view = -61
• Group profile ID is 61.
• The post author profile is 3.

The problem:

When a new post is created inside the private group, push notifications are only sent to the admin/post author, not to the other group members who are subscribed to the group and have push notifications enabled.

We confirmed:

1. The affected users are subscribed to the group context profile:

SELECT *
FROM sys_profiles_conn_subscriptions
WHERE content = 61
ORDER BY initiator;

This returns members/subscribers including:

initiator 3    content 61
initiator 51   content 61
initiator 220  content 61
initiator 1709 content 61

1. The notification handler for timeline posts exists and appears enabled:

SELECT *
FROM bx_notifications_handlers
WHERE alert_unit = 'bx_timeline'
  AND alert_action = 'post_common';

This returns handler:

id = 1280
group = bx_timeline_object
alert_unit = bx_timeline
alert_action = post_common

1. Notification settings for handler 1280 are enabled for site/email/push and personal/follow_member/follow_context:

SELECT *
FROM bx_notifications_settings
WHERE handler_id = 1280
ORDER BY id;

This includes enabled rows for:

site  personal
site  follow_member
site  follow_context
email personal
email follow_member
email follow_context
push  personal
push  follow_member
push  follow_context

1. The affected users have active settings for this handler:

SELECT *
FROM bx_notifications_settings2users
WHERE setting_id IN (
    SELECT id
    FROM bx_notifications_settings
    WHERE handler_id = 1280
)
ORDER BY user_id, setting_id;

For example, user/profile 1709 has active settings for all rows.

1. Cron is running and notification events are being processed:

SELECT name, value
FROM sys_options
WHERE name IN ('bx_notifications_processed_event', 'sys_cron_time');

The processed event value advances after running cron.

1. The key issue appears to be the notification privacy check.

When testing the notification privacy object directly for a notification event where:

event_id = 13409
owner_id = 61
object_privacy_view = -61

this test:

$oPrivacy = BxDolPrivacy::getObjectInstance('bx_notifications_privacy_view');

foreach ([3, 1709, 220] as $userId) {
    $result = $oPrivacy ? $oPrivacy->check($eventId, $userId) : null;
    echo "User {$userId}: " . ($result ? "ALLOWED" : "BLOCKED") . "\n";
}

returns:

User 3: ALLOWED
User 1709: BLOCKED
User 220: BLOCKED

However, if the same notification event is manually changed from:

object_privacy_view = -61

to:

object_privacy_view = 3

and the notification event is reprocessed, then recipients are generated and push queue rows are created for the other subscribed members. This suggests OneSignal and cron are working; the issue is that the notification privacy check blocks subscribed group members when the notification event privacy is -group_profile_id.

My question:

Is this expected behavior for private/secret group context posts, or is it a bug?

My understanding is that a post created inside a private group should remain private to the group, but notification delivery should be allowed to group members/subscribers of that group context. In other words, for a notification event with:

owner_id = 61
owner profile type = bx_groups
object_privacy_view = -61

users subscribed to profile/context 61 in sys_profiles_conn_subscriptions should pass the notification privacy check.

Possible fix we are considering, but I would prefer UNA guidance before changing module code:

Add an override in:

modules/boonex/notifications/classes/BxNtfsPrivacy.php

so that BxNtfsPrivacy::check() first runs the parent check, but if the parent check blocks the event, it allows the notification when:

1. the notification event owner profile is bx_groups or bx_spaces,
2. object_privacy_view equals negative owner/context profile ID, for example -61,
3. the viewer is subscribed to that context profile in sys_profiles_conn_subscriptions.

Conceptually:

if(parent::check($iObjectId, $iViewerId))
    return true;

if($eventOwnerType is bx_groups or bx_spaces
   && object_privacy_view == -owner_id
   && viewer is subscribed to owner_id in sys_profiles_conn_subscriptions)
    return true;

Would this be the correct place to fix it, or is there a built-in setting/configuration that should make group members pass bx_notifications_privacy_view automatically?

Also, should this logic apply to both bx_groups and bx_spaces context posts?

Thank you.

@LeonidS @Alex T⚜️