push notification private/secrete group doesn't go to all member

Thanks @LeonidS . I couldn't open the attached image you sent, can you kindly send again. And I mean the app "push" notification not sent to other members.

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⚜️

Thank you very much @LeonidS for confirming the issue and creating/fixing GitHub issue #5527.

This does appear to match what we found on our side. In our testing, new content inside a closed/secret group was creating notification events with the context as the owner, for example:

owner_id = group/space profile ID

object_privacy_view = negative group/space profile ID

However, common members/followers of that context were failing the notification/privacy check, so Email/Push notifications were only reaching the admin/posting profile.

As a temporary workaround, we modified two notification-layer files:

modules/boonex/notifications/classes/BxNtfsPrivacy.php

modules/boonex/notifications/classes/BxNtfsTemplate.php

This allowed group/space followers to pass notification privacy for private context-owned notification events and allowed push payload generation. It fixed push delivery for timeline updates, comments, discussions, and discussion comments in our tests.

Your fix looks cleaner because it appears to address the root privacy check by adding a viewer-aware space/context privacy check in:

inc/classes/BxDolPrivacy.php

modules/base/profile/classes/BxBaseModProfileModule.php

Before UNA 15 Vega is released, can you please confirm whether it is safe to manually apply this two-file fix to our current UNA 14 installation? We need this feature working now, but I want to avoid applying a patch that depends on other UNA 15 changes.

Also, can you please confirm whether this fix applies to both Groups and Spaces, and whether it also applies to other similar context/profile modules that use the same closed/secret context privacy mechanism?

If we apply your official fix now, should we revert our temporary notification-layer workaround and test using only your core privacy fix?

Thanks @LeonidS !

I followed the steps above and fixed the issue. Thank you so much.

Last question, will this also apply for the "Space Module"?