Use the max_results env value in the paginator #10797
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is a small change, and while it's gross to mix PHP and javascript, it was previously setup a little confusing. If you don't have this set, it will default to 500 - but the bootstrap-tables results list (10, 20, 50, 100, 200, etc) would go up to 1000 - but since this setting exists, it wouldn't actually return 1000, and the export wouldn't actually export higher than 500 rows at a time.
This isn't a flawless solution - and generally speaking if you're returning over 500, you're gonna have a bad time - not because Snipe-IT can't handle it, but because jamming that much stuff into any browser's DOM is going to be sloooooow - but at least now it doesn't show an option that shouldn't be shown.
snipe-it/config/app.php
Lines 40 to 50 in 3e2fe10
Down the line, we probably want to create a helper method that sanely walks through increments a little better and just use that to determine what the page amounts should be, but this fixes the issue for the vast majority of use cases.
Fixes SC-17768 and FD-24875.
Signed-off-by: snipe snipe@snipe.net