Skip to:
Content

Opened 3 years ago

Last modified 12 months ago

#3463 new defect (bug)

After a hidden group is made public all activity is still hidden

Reported by: modemlooper Owned by:
Milestone: Future Release Priority: normal
Severity: normal Version: 1.5
Component: Core Keywords: needs-refresh
Cc:

Description

Probably needs more testing but I had a group that was hidden then made it public all activity is hidden to all members.

Attachments (1)

3463.01.patch (688 bytes) - added by boonebgorges 2 years ago.

Download all attachments as: .zip

Change History (10)

comment:1 DJPaul3 years ago

  • Milestone changed from Awaiting Review to 1.6

Correct me if I'm wrong, but I think this is how it works on 1.2. We don't update the group's activities' hide_sitewide fields.

comment:2 modemlooper3 years ago

Even the users who were part of the group can no longer see the activity.

comment:3 boonebgorges3 years ago

hide_sitewide issues shouldn't affect whether an activity item is visible within the confines of the group (where hide_sitewide items should always be shown).

It seems unwise to switch all activity items to hide_sitewide = false when the group status is changed. That'll make the pre-public content of the group very public, when its users might not have intended it to be public at the time. (I know that making the group public allows it to be seen anyway, but putting it in the public activity stream is a whole other level of highlighting.) Seems like plugin territory to me. In any case, that would be an enhancement request.

Can someone verify whether the main part of modemlooper's report - namely, that even members of the group are unable to see previous activity after the group status is changed - is a regression from BP 1.2? If so, we should probably track it down and fix it for this release. Otherwise we should leave the milestone as 1.6 IMO

comment:4 boonebgorges2 years ago

I've been thinking some more about this, and I don't have a solution in mind, but I do have some thoughts:

One suggestion is in 3463.01.patch. Essentially, show_hidden is true when users are members of the group, even in public groups. The upside of this solution is that we don't have to loop through existing activity and set hide_sitewide (which would be a nightmare on several levels). The downside is that it makes the activity stream of a "public" group look different to members and non-members, which seems not quite "public". Of course, since most groups will start public and remain public - and thus all of their activity will have hide_sitewide = false - it's an edge case at best.

boonebgorges2 years ago

comment:5 boonebgorges2 years ago

  • Keywords has-patch dev-feedback added

Bump. Does another developer have feedback on this approach?

comment:6 DJPaul2 years ago

Not very very happy because someone could come in from a search engine, then if they realise it's on a site they have an account, and log in, the item could mysteriously disappear. But I agree, edge case. Haven't tested patch.

comment:7 boonebgorges2 years ago

someone could come in from a search engine, then if they realise it's on a site they have an account, and log in, the item could mysteriously disappear.

Just so I understand you right, you mean: a non-logged-in user comes to the group page, sees the first 20 items, and then is disoriented because after logging in he sees different items? It should be noted that this will only happen for activity items that were posted when the group was private/hidden, which is to say that it will be very, very much an edge case. I'm probably going to go ahead with this solution, but I'll sleep on it first.

comment:8 boonebgorges2 years ago

  • Milestone changed from 1.6 to Future Release

I think it's probably worth fixing this for real, instead of doing another hide_sitewide hack. See http://buddypress.trac.wordpress.org/ticket/3857. I'm going to bump this ticket to Further Release, but I'll probably close it as a duplicate once work starts on that ticket.

comment:9 DJPaul12 months ago

  • Keywords needs-refresh added; has-patch dev-feedback removed

Maybe for 1.9 ?

Note: See TracTickets for help on using tickets.