We don't make any particular distinction between private and public status updates.

Commons has separate Rules for private and public updates. This is confusing, unnecessary, creates an additional maintenance burden, and also opens the possibility that unsuspecting administrators could create Rules that would accidentally make private messages public. A better solution would be to dynamically filter activity messages for private status updates. This could be done either when the status is saved (by saving it as visible only to the sender and recipient) or maybe when building the view of activity messages.

Comments

ezra-g’s picture

ezra-g commented

Weighing the two approaches here:

A) Filter out private statuses in activity log when displayed by Views (and in Digests):

Drawbacks:
- Total # of items isn't consistent with Views pager when private items are removed(But this is a known bug that we should fix anyway)
- There's not an efficient way (that I know of) within the Views query to connect an activity log message to the private/public status of a status update. This could potentially involve a schema change or re-architecture per: #1259306: Re-architect activity message visibility

Benefits
- Would respect the "view all private status updates" permission so that administrators could view all status updates

B) Assign to specific audience (Viewer and sender):

Benefits:

- Consistent with current approach to message visibility. Doesn't require a schema change.
Drawbacks:
- Would not respect "view all private status updates" permission: Even users with this permission wouldn't see private status updates because they wouldn't explicitly be specified as the audience to the status update. However, this seems like it's part of the fundamental architecture issue at #1259306: Re-architect activity message visibility rather than a drawback of this specific use case. It's also a better result than the current situation, which is that even private status updates are visible to everyone in the activity log.

Based on those factors, I'm inclined to go with option B) and keep this use case in mind if/when message visibility is re-architected.

ezra-g’s picture

ezra-g commented

Related issue: #1307948: In some conditions, status privacy is incorrectly loaded.

icecreamyou’s picture

icecreamyou commented

I was thinking of (B) when I created this issue. IMO disrespecting the "view all private status updates" permission isn't a big deal -- it just treats the permission as a permission but not a guarantee. What it really means is that private status updates only show up to the sender and recipient in activity streams, but administrators can still monitor them through a separate view of private status updates if they want.

You're also correct that #1259306: Re-architect activity message visibility should make this problem irrelevant.

icecreamyou’s picture

icecreamyou commented
Status: Active » Needs review

Committed an (untested) change that should solve this (patch started by ezra-g). Marking as "needs review" until the fix is confirmed even though it's already committed

ezra-g’s picture

ezra-g commented

Thanks, @IceCreamYou.

I've tested this with private status updates between 3 users with uids 1 3 and 4.

Private status updates seem to be properly restricted for users 3 and 4, but user 1 can see all private status updates. Since all 3 users have the "view all status updates permission" already, I'm not sure whether there is some uid-specific logic coming into play for user 1.

In general, this seems like the right fix.

[edit: Leaving this open so that another person can verify with additional functional testing.]

icecreamyou’s picture

icecreamyou commented

Ezra, can you clarify what you did and the result you got? That seems like pretty unexpected behavior if I'm understanding you correctly.

icecreamyou’s picture

icecreamyou commented
Status: Needs review » Fixed

Assuming this is fixed.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

sgdev’s picture

sgdev commented
Status: Closed (fixed) » Active

Can confirm that this is not working with 6.x-2.x-dev. Here is the use case I found that it did not work (all of the users are basic authenticated users):

1) User #1 (not uid=1, just "1st user") posts a private status message on the activity log of user #2's profile page.
2) Log out, log in as user #3, and visit user #2's profile page.
3) When visiting the page, user #3 can see the private message that was shared between user #1 and user #2.

I also noticed in other tests that if I add the "@" indicator for a user (such as @user2), the private status message will also show up on the person's status thread. Now obviously, I wouldn't expect someone to add "@user2" if they didn't actually want it to be put on the other person's activity log. However if a status message is truly private, then all parts of it should be private -- regardless of what a user does.

icecreamyou’s picture

icecreamyou commented
Status: Active » Closed (fixed)

ron_s: Your issue is different. If you need help, please open a new support request. Include whether you are using Acquia Commons or not, what your settings are for the relevant permissions, and any custom Activity Log rules or customizations of the default Activity Log rules.

sgdev’s picture

sgdev commented

Ok, that's fine, but I'm going to open a ticket with the exact same title, regarding Commons, the default Commons Activity Log rules, and Activity Log 6.x-2.x-dev.