Feature #43355
open
Add pagination support for members and groups management views
Description
When assigning hundreds (or thousands) of users to a project or a group, the project settings page and the groups page have become very slow.
I added pagination to optimize performance. Page load times with 1000+ users dropped from over 5 seconds to around 1.5 seconds.
This feature is based on the stable 5.1 branch.
I added tests.
However, a double-check wouldn’t hurt.
Files
Updated by Takenori TAKAKI 11 days ago
- File 0001-members-pagination.patch 0001-members-pagination.patch added
- File 0002-groups-pagination.patch 0002-groups-pagination.patch added
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.