Change Details

**Feature summary** (what you would like to be able to do and where): In Special:CheckUser queries that have too many results (due to having checked a large / busy range) fail to run. While the query can be adjusted to make it return less than the limit number of queries, no results are shown. In some cases it may not be possible to reduce the query size due to having to check a large range. While the limit would stay, this would instead show the results up to the limit and then include a link which allows the next batch to be generated. **Use case(s)** (list the steps that you performed to discover that problem, and describe the actual underlying problem which you want to solve. Do not describe only a solution): CUs checking wide or busy ranges may see no results on a check, which results in a guessing game of which combination of changes to the parameters will end up with a check that can run. This would allow these CUs to still see a subset of the results and then if needed get the next batch. **Benefits** (why should this be implemented?): This will reduce the guess work that is needed if a range is too wide or busy to check, making CU checks faster to run. If implemented right this would also reduce the amount of code needed in the extension as the results page and queries for any checks that are too large would no longer be needed (as these pages would never be used as a subset of the results would be shown). **Extra info** Discussed on checkuser-l as a feature wanted for the CheckUser extension.

**Feature summary** (what you would like to be able to do and where): In Special:CheckUser queries that have too many results (due to having checked a large / busy range) fail to run. While the query can be adjusted to make it return less than the limit number of queries, no results are shown. In some cases it may not be possible to reduce the query size due to having to check a large range. While the limit would stay, this would instead show the results up to the limit with some kind of paging mechanism like Special:Contributions that allows generation of results that were truncated. **Use case(s)** (list the steps that you performed to discover that problem, and describe the actual underlying problem which you want to solve. Do not describe only a solution): CUs checking wide or busy ranges may see no results on a check, which results in a guessing game of which combination of changes to the parameters will end up with a check that can run. This would allow these CUs to still see a subset of the results and then if needed get the next batch. **Benefits** (why should this be implemented?): This will reduce the guess work that is needed if a range is too wide or busy to check, making CU checks faster to run. If implemented right this would also reduce the amount of code needed in the extension as the results page and queries for any checks that are too large would no longer be needed (as these pages would never be used as a subset of the results would be shown). **Extra info** Discussed on checkuser-l as a feature wanted for the CheckUser extension.

**Feature summary** (what you would like to be able to do and where): In Special:CheckUser queries that have too many results (due to having checked a large / busy range) fail to run. While the query can be adjusted to make it return less than the limit number of queries, no results are shown. In some cases it may not be possible to reduce the query size due to having to check a large range. While the limit would stay, this would instead show the results up to the limit and then include a link whichwith some kind of paging mechanism like Special:Contributions that allows the next batch to be genergeneration of results that were truncated. **Use case(s)** (list the steps that you performed to discover that problem, and describe the actual underlying problem which you want to solve. Do not describe only a solution): CUs checking wide or busy ranges may see no results on a check, which results in a guessing game of which combination of changes to the parameters will end up with a check that can run. This would allow these CUs to still see a subset of the results and then if needed get the next batch. **Benefits** (why should this be implemented?): This will reduce the guess work that is needed if a range is too wide or busy to check, making CU checks faster to run. If implemented right this would also reduce the amount of code needed in the extension as the results page and queries for any checks that are too large would no longer be needed (as these pages would never be used as a subset of the results would be shown). **Extra info** Discussed on checkuser-l as a feature wanted for the CheckUser extension.