FIX: proper handling of group memberships#3
Conversation
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| limit = (params[:limit] || 50).to_i | ||
| offset = params[:offset].to_i | ||
|
|
||
| total = group.users.count | ||
| members = group.users.order(:username_lower).limit(limit).offset(offset) | ||
|
|
||
| render json: { | ||
| members: serialize_data(members, GroupUserSerializer), | ||
| meta: { | ||
| total: total, | ||
| limit: limit, | ||
| offset: offset |
There was a problem hiding this comment.
Public group members limited to first 50
The members endpoint now always paginates (lines 22‑33) and only returns limit users (default 50) plus metadata. However, the public group members template (app/assets/javascripts/discourse/templates/group/members.hbs) still renders a static table with no paging or load‑more controls, so visitors can never see members beyond the first 50. Either the endpoint needs to revert to returning all users for non‑automatic groups, or the client needs UI/actions to request additional pages; otherwise most group members disappear from the UI.
Useful? React with 👍 / 👎.
Test 8
Replicated from ai-code-review-evaluation/discourse-cursor#8