Redmine

Thank you for working on this.

The members and groups management pages really need pagination on large installations.

I rebased the change onto the current trunk (the attached patch is based on 5.1 and no longer applies cleanly) and split it into two commits — one for the project members list and one for the group users list. Apply 0001 first, then 0002.

Two notable differences from the original patch:

• Members with several roles. `Member.sorted` orders by `roles.position` and therefore joins the roles table, so a member with N roles produces N rows. Applying `LIMIT`/`OFFSET` to that scope paginates join rows rather than members, which can list a member twice or skip one. In the members commit I collect the sorted, de-duplicated member ids first (keeping the lowest role position) and then load only that page, so pagination counts members. The group users list is ordered by name (no such join), so a plain `limit`/`offset` is fine there.
• No controller concern. I kept the pagination in helpers (`paginate_members` / `paginate_group_users`), next to the existing `render_principals_for_new_members` / `render_principals_for_new_group_users`, instead of adding an `app/controllers/concerns` module (Redmine has no controller concerns yet). The partials are rendered from several controllers, so a helper keeps it in one place without duplicating across actions.

Like the original, a dedicated page parameter (`members_page` / `users_page`) is used so it doesn't clash with the `page` used by the add-member / add-user modals.

Tests pass on the current trunk.

I found a few things to improve in the patches I attached in note-1, so here is an
updated pair, rebased onto the current trunk. Apply 0001 (project members list)
first, then 0002 (group users list).

Improvements over the previous patches:

• Fixed the list showing "No data" when an out-of-range page is requested.
• Added spacing between the list and the pagination controls, matching the other
  list screens.
• Trimmed the code comments to the single non-obvious point.

Measured on the project members settings page of a project with ~4000 members
(development, SQLite, warm):

• Members tab: ~4.9 s -> ~0.33 s
• Members list partial alone: ~4.5 s -> ~0.04 s
• 25 member rows loaded per page, no N+1.

These are development-mode figures; production is faster. Screenshots attached.

Project members list (Settings -> Members)	Group users list (Groups -> Users)

Both patches committed, thanks for the nice work!