Hi,
Our beta users keep running into this confusing behavior around the activity “(edited)” label that I strongly believe should be reconsidered. I had reported this some years ago, but now that Activity Topic was introduced and is also triggering a post edit, I need to follow up on this again.
Summary:
Right now, an activity post is marked as “(edited)” when:
1. The post text/content is edited (which is correct), but also when
2. Only the privacy/visibility of the activity is changed, and/or
3. Only the topic is changed,
4. Even when the “Edit Activity” feature is disabled in settings.
This means users see “(edited)” even though the content of the post has never actually been edited, and even when editing is explicitly turned off.
From a UX standpoint and trust perspective, this is very misleading and has been brought up multiple times by our test users now.
Steps to reproduce:
1. As an admin, go to BuddyBoss > Settings > Activity.
2. Disable “Edit Activity” (so members can’t edit posts).
3. Post a new activity update as a regular user.
4. Open the post options and change only:
- the visibility/privacy (e.g., from Public to Connections), or
- the topic (if Activity Topics is enabled).
5. Refresh the activity stream.
Actual result:
- The timestamp now shows “(edited)” suggesting the post itself was edited.
- This happens even though:
a) The post content was never edited.
b) The Edit Activity feature is disabled.
So changing privacy or topic alone is treated as an “edit” of the post.
Expected result:
Any of the following would be more logical and less confusing:
1. Strict version (most accurate):
- “(edited)” appears only when the actual activity content (text/media) has been modified.
- Changing visibility or topic alone should not set the edited flag.
2. Setting-aware version (respect site settings):
- If Edit Activity is disabled, then:
- Do not mark posts as “(edited)” at all, or
- Only mark them “(edited)” when an admin actually edits the content via the backend.
3. Separate markers/flags (if you want to track everything):
- Internally track:
- content_edited
- privacy_changed
- topic_changed
- Only show “(edited)” if content_edited === true.
- Optionally, provide a filter or setting so customers can decide whether privacy/topic changes should show a different label (e.g. “privacy updated”) or no label at all.
Why this is a problem (UX / trust / moderation)
- User trust: Members assume “(edited)” means the text of a post has changed. When they see “(edited)” but can’t find any actual edit, they assume:
- something is broken, or
- content was changed secretly and they can’t see what.
- Moderation and transparency: Moderators and members often rely on visible edit markers to understand whether someone has changed their words after replies/complaints. Showing “(edited)” when only privacy changed weakens that signal.
- Consistency with other platforms: On major social platforms, the edit marker is tied to content edits, not just metadata tweaks. Privacy changes usually do not show publicly as an “edit” of the post.
- Triggering a visible edit on privacy changes ironically is a privacy concern itself.
- Contradiction with settings: Disabling “Edit Activity” should reasonably mean:
- posts cannot be edited by members, and
- there are no visible “(edited)” markers for actions that the admin explicitly tried to prevent.
Right now, the behavior looks like a bug from both an admin’s and user’s point of view, even if technically it’s “working as coded.”
Requested change
Could you please consider to:
1. Adjust the logic so that the “(edited)” label is only displayed when the content of the activity item has changed (not just privacy/topic), or
2. At minimum, respect the “Edit Activity” setting:
- When it’s disabled, don’t mark posts as edited just because privacy/topic changed.
3. Ideally, expose a filter or setting to let site owners control:
- whether metadata-only changes (privacy/topic) should be treated as “edits,” and
- what label (if any) is shown for those.
This is a small change in terms of UI, but a big one for clarity and trust. Right now, the interface is effectively telling users “this post was edited” when it often wasn’t.
Thanks a lot for looking into this and reconsidering this old logic.
Jan