CUNY Academic Commons

Apologies for leaving production with uncommitted changes, Boone.

I think commit 462e7bc isn't necessary since I've worked around those core bbPress mods in the following commits:

• https://github.com/cuny-academic-commons/cac/commit/bb4b5aa3dc306b6c2929083ef71d0ae210d62a03
• https://github.com/cuny-academic-commons/cac/commit/77268fc2d403d0afab216b95510e647da95b0684
• https://github.com/cuny-academic-commons/cac/commit/527a3ac800e0b63258b0f4affa1508bf2b2b3f82. Regarding this fix, please take a look at what I mentioned here -- https://redmine.gc.cuny.edu/issues/25718#note-17 -- to see if the logic is sound. I opted to always check all available post statuses for the 'forum' post that is connected to a group, but we could restrict the 'private' or 'hidden' post status check only if the group is private or hidden.

I did leave production uncommitted because commit 462e7bc included changes to the 'participate' to 'exist' caps, which I didn't make and wasn't sure if you were still doing some debugging with that.

To be clear, the original cac-bbpress-2.6.17.diff is still needed for 2.6.19, but the upcoming bbPress 2.6.20 might not need it as JJJ has made some adjustments here. We will need to test to be sure though.

Thanks, Ray. No apologies necessary - obviously I left things a mess myself with my 'exist' tests.

Regarding those unstaged changes, I understand how I can discard the bbp_include_all_forums part (and I think that your workaround in https://github.com/cuny-academic-commons/cac/commit/527a3ac800e0b63258b0f4affa1508bf2b2b3f82 is a fine fix for this), and I understand that I can get rid of the participate/exist checks. But what about the super-sticky stuff? That's covered by https://github.com/cuny-academic-commons/cac/commit/77268fc2d403d0afab216b95510e647da95b0684?

It appears that John has cleared out the 2.6.20 milestone, and it looks like it includes extensive changes https://bbpress.trac.wordpress.org/query?milestone=2.6.20&status=accepted&status=assigned&status=closed&status=new&status=reopened&status=reviewing&order=priority&col=id&col=summary&col=status&col=milestone&col=owner&col=type&col=priority Like you said, we're going to have to spend energy to test and merge our customizations when 2.6.20 is released, so perhaps we should just skip the 2.6.19 upgrade for the time being, in case that release is imminent. Let's hold off here and circle back in a week to see where things stand.