Change Details

The results will be displayed using a TablePager, with the query performed via the service. For this to work, the service should be reorganised to do two queries. The first should query the CentralAuth database for the username, wiki and registration date. Pagination will be done on this query (see e.g. IndexPager::buildQueryInfo). The offset, limit, sort by column, etc will differ depending on UI interaction; the service should accept these as input. The second should query each local database for the user edit count, blocked status and group information, for each row in the page results. The results could be returned as a numbered array of rows, to be wrapped in a FakeResultWrapper in the pager.

The results will be displayed using a TablePage. The first should query the CentralAuth database for the username, wiki and registration date. Pagination will be done on this query (see e.g. IndexPager::buildQueryInfo). The second should query each local database for the user edit count, blocked status and group information, for each row in the page results.

The results will be displayed using a TablePager, with the query performed via the service. For this to work, the service should be reorganised to do two queries. The first should query the CentralAuth database for the username, wiki and registration date. Pagination will be done on this query (see e.g. IndexPager::buildQueryInfo). The offset, limit, sort by column, etc will differ depending on UI interaction; the service should accept these as input. The second should query each local database for the user edit count, blocked status and group information, for each row in the page results. The results could be returned as a numbered array of rows, to be wrapped in a FakeResultWrapper in the pager.