Hi,
When passing pageSize param in the api call, the size passed in the request becomes the default size, and all the subsequent calls then start honoring that size as default size. Also passed pageSize in the api becomes the default size for the entity find screen.
Thanks and Regards,
Yash
Welcome to Moqui. Thanks for joining the forum.
Is this a problem for you or do you have a question about this?
I think he’s reporting this as sort of a bug which I confirm by the way. Maybe we should at a minimum allow the page size in API to be independent from the page size in widgets. Furthermore, even in widgets in some pages we can control the page size while in others we cannot control the page size, so it feels weird to go and change the page size in some screen where the size is editable and find it reflected in another screen where the size is not editable.
So maybe the correct behavior is to have the page size be local to the end-point that triggered it instead of global to the entire framework? Alternatively, maybe make it global if no pageSize=whatever else use that page size without altering the global one and make that just a setting somewhere.
I am reporting it as a bug.
Hello,
The system is behaving as expected. Page size is treated as a user preference in Moqui, the value is saved when you change the page size in the UI or via the API with an authenticated user. You can disable this feature by commenting out ScreenRenderImpl.groovy:364.
Is there a reason why you wouldn’t want to be able to set the page size with the API?
It seems to me that setting a page size once with the API would be a feature.
Is the problem that the API and screens use the same page size for a given user?
I think sending pagination specific params in an api needs to be specific to that api and should not be set as user preference.
For example: If I want to fetch 20 product categories, then I will send pageSize as 20 for that api, but when fetching product I want to use the default pageSize(that is 100), so I will not send pageSize, but will get only 20 products which will become confusing.
I totally agree with you. An upstream change to the necessary code shouldn’t be much of a problem either.
I would create a new user preference that is specifically for an API.
@yash Do you think you could submit a PR? It should be quite small.
For what it’s worth, I implemented this based on a client request but was not (and am still not) in favor of the current approach, for UI or API. This is one of those things I pushed back and then decided to defer to the designs of others who have experience with such things… sometimes I’m wrong and I know it well! IMO, in the UI it would be better if it was a per-screen setting rather than the same for all screens. I’ve been tempted to remove this entirely as the value added by it is limited and there are enough downsides to it in some circumstances to cancel out the benefits of it.
This would be my proposal: remove it and replace it with a per-screen (and per-user) setting to remember the last page size used.
On a side note, the definition of bug that seems most useful is something that is not working as it was designed to, that results in error conditions or behaves differently from what was specified in a design. There is value in distinguishing between bugs, missing features, poorly designed features, etc. IMO this is a poorly designed feature and should be changed.
I totally agree. Some screens that have little info are likely to be useful to use with a large number of items per page, but when this same setting is used in another screen with lots of info and a large processing time, it is somewhat annoying.