show who boosted content in feed

[blued-gear]

If content gets included in the feed (Combined + Subscribed + Newest), then show who of the followees boosted it.

This is currently only for the UI. If you have an idea how this info can be included in API responses, please let me know (@jwr1).

As the content-query can become white heavy when including comments, this PR also adds a setting for the admins to disable comments in the feed.

Closes #2192

[jwr1]

For the API, we could modify the existing end points to accept an includeBoosts parameter. Then I think from there we'd need to include two more properties in the response objects, one for the boosting user, and one for the boosting date time. Does that sound like it could work?

[melroy89]

@jwr1’s API point is still outstanding. The combined collection endpoints already expose an includeBoosts query parameter and pass it into Criteria, so no new request parameter appears necessary. What this PR still needs is response metadata: the current serializer converts each decorated entity into the existing response DTO and drops extendedContentProperties entirely. Since multiple followed users can boost the same item, I suggest an optional boostedBy array of records such as { user: UserSmallResponseDto, boostedAt: datetime } on each content response DTO (with OpenAPI and endpoint tests), rather than two scalar properties.

Let me try to add this directly here, while I'm at it.. So I will extend the PR with the requested API extention.

[melroy89]

Implemented the API portion in 3dd16f9. The existing includeBoosts parameter now causes each combined-feed item to expose optional boostedBy records containing the boosting UserSmallResponseDto and boostedAt timestamp. This covers entries, posts, and both comment types, with OpenAPI metadata and functional assertions. The separate 2N-query review finding remains open.

[blued-gear]

I changed the ExtendedContentPopulationTransformer so now there are at most 4 + additional queries issued.

[melroy89]

Each element added here references the same loop-local $item variable. On the next iteration, assigning a new array to $item changes every previously stored element as well, so two boost rows of the same content type become duplicate copies of the final row (and itemsToFix has the same alias). Please store distinct values/indices instead of references and add a test with at least two boost rows in one type, ideally from different users or for different content IDs.

[melroy89]

This sorts only the copied $boosts array, so the reordered value is discarded at the end of each iteration and the returned boost lists retain the database's unspecified row order. The previous implementation explicitly returned boosts ordered by time, which also determines which users survive the five-item template limit. Please iterate by reference or assign the sorted array back, and cover the ordering with more than one boost row.

[blued-gear]

As a sidenote: who in the right mind put in the PHP specification that arrays are always passed by value?!