Skip to:

Opened 13 years ago

Closed 10 years ago

#3463 closed defect (bug) (duplicate)

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

Reported by: modemlooper's profile modemlooper Owned by:
Milestone: Priority: normal
Severity: normal Version: 1.5
Component: Core Keywords: needs-refresh


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 13 years ago.

Download all attachments as: .zip

Change History (12)

#1 @DJPaul
13 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.

#2 @modemlooper
13 years ago

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

#3 @boonebgorges
13 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

#4 @boonebgorges
13 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.

#5 @boonebgorges
13 years ago

  • Keywords has-patch dev-feedback added

Bump. Does another developer have feedback on this approach?

#6 @DJPaul
13 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.

#7 @boonebgorges
13 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.

#8 @boonebgorges
13 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 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.

#9 @DJPaul
11 years ago

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

Maybe for 1.9 ?

#10 @boonebgorges
10 years ago

  • Milestone changed from Future Release to 2.1

The approach in 3463.01.patch seems good to me. Let's look for 2.1.

#11 @boonebgorges
10 years ago

  • Milestone 2.1 deleted
  • Resolution set to duplicate
  • Status changed from new to closed

Going to mark this as a duplicate of #2014, which was fixed in r8404 (along the lines of 3463.01.patch).

Note: See TracTickets for help on using tickets.