Skip to content

fix(core): the offset for paginated data now adjusts according to the total count of filtered data

Description

fix(core): the offset for paginated data now adjusts according to the total count of filtered data

  • There was a bug related to the requested offset from client when the amount of the filtered data found according to the all given filters were lower than this offset.
  • Now the offset adjusts to this use-case and is set to the last possible page (considering the page size).
  • All paginated methods were rewritten to work correctly (members, users, blocked logins, sub/groups, applicaitons and audit messages).

How to test

Check automated tests, deploy on devel and try it with the related MR on FE.

Author's checklist

  • I have followed the contribution guidelines
  • This MR has been tested or does not change functionality
  • I have added relevant merge request dependencies (if this MR has any)
  • I have added the correct labels
  • I have assigned reviewers (if any are relevant)
  • I have edited the documentation (if the changes require it) or I have noted the need for the change if I do not have access to the documentation
  • I have marked all introduced BREAKING CHANGES or necessary DEPLOYMENT NOTES in the commit message(s)

Reviewer's checklist

  • This MR has been tested or does not change functionality
  • This MR has correct commit message format

Other information

This implementation was chosen to follow the Angular client-side pagination.

I am not sure if this implementation will work correctly for audit messages since there is the total count just estimated. If the estimate will be always lower then the real last page, then it is ok, but if it can be also higher, then it can be a problem (and I am not sure about it).

Related issues

re STR-1211

Edited by David Flor

Merge request reports