Object search in 25R1 only returns 20 results

Hello Jeremias,

A new System Parameters were introduced in assyst 25R1 to improve performance using pagination

assystWeb Default Lookup Page Size System Parameter specifies the default number of rows to be returned in a Lookups in the assyst Portal.

This should not exceed Max Paging Size System Parameter if it is in use. This last parameter defines the maximum paging size.

assyst 25R1 Release Notes

When searching for the item you should be able to see how many results are available

Then navigate using the Next/Previous page buttons available

I hope this helps.

Best Regards,

Caroline

Thank you for the feedback. We have now tried it and it is correct. The parameter influences the result set for the objects. However, I see one issue critically: the object search had always multiple pages (a different format from the pages you showed in the menu). In the result, for example, I now see 30 objects displayed. In reality, there would be over 1,000 items that should appear. I do not see any indication anywhere that the result has been limited because of the parameter. I could also work with multiple pages, but that is being prevented for me.

Thank you very much!
Jeremias

Hello Jeremias, 

Are you using assyst 25R1 SU1?
Have you tried to search for the item from different forms? incident, itet tem form ..etc? What is happening when you filtering the search, per product, ptroduct class, or ? beginning of the shortcode? then try full search again. 
If you still have this behaviour and if you have not done this already, please log an incident with our support in the normal manner so they can investigate this further for you.

            via our Self-Service portal
            or 
            via email to axios.support@ifs.com

Best Regards,
Caroline

Hello Caroline,

We are using Assyst version 25R1 SU1. Since then we have also encountered the problem. The support team closed the ticket, referring to the parameter. This is theoretically correct, because by changing the parameter we can also obtain more results. However, we can no longer achieve unlimited results as we could in the old version. Moreover, due to performance issues, it is recommended not to set the parameter too high.

For these reasons the solution makes nosense to me. It appears that a core function (object search) has inadvertently been limited by a parameter intended for performance control.

I can certainly open another ticket by the IFS Helpdesk, but I increasingly feel that everything progresses very slowly and laboriously (regardless of the topic or ticket). Therefore, in addition to contacting support, I have also asked for help in the community.

Kind Regards and Thanks for your help!
Jeremias

Hi Jeremias,

Thank you for raising this important point and for your detailed observations.

In assyst 25R1, we introduced pagination controls for object searches as part of a broader effort to enhance system performance and stability, especially in environments with high user concurrency. Previously, allowing up to 1000 results to be returned in a single query placed significant strain on the database, particularly when multiple users performed large searches simultaneously. This could lead to slow response times and degraded performance across the application.

To address this, we implemented paging functionality that returns a smaller subset of results per page. This ensures that users can still access the full result set - just in a more controlled and efficient way. Importantly, the page size is configurable via system parameters, so you can adjust it to suit your needs. However, we do recommend keeping this value reasonably low to avoid reintroducing performance issues.

We understand this change may feel like a trade-off between usability and performance. Our goal was to strike a balance that maintains a responsive user experience while protecting the integrity and speed of the platform for all users.

If you’d like to see more results per page then the system parameter is there to be adjusted, however we would suggest that the number of results per page is kept to a minimum to retain the performance of the overall system. For example having the paging value set to 50 or 100 would likely be fine, however we would not recommend 1000.

I appreciate your frustration with the situation however I hope the information above helps clarify why we made this change in the product.

Best regards,
Robert Wood
Senior Product Manager

Hello Robert, t

hank you for your detailed and reply! That's not something to be taken for granted.

Unfortunately, I have to make a slight correction. I think the introduction of the new paging function is good, useful, and practical. There is no frustration there.

However, I would like to point out a gap where the new paging function does not work, but should actually work. Because it does not work there, the result is always limited to the amount of the first page. I cannot view all the results. Not even by going on the next page. You are welcome to test this yourself. Use the object search and try to find more results than the paging value allows using a parameter. No more results will ever appear, and you cannot view them across pages:

The frustrating part is that I apparently don’t have the words to explain it properly. At the very least, the ticket was closed by the help desk and simply referred to the paging functionality. However, this functionality does not work here, and for the end user it is not really visible in the object search (because it differs from the other searches).

Best regards and many thanks!
Jeremias

Hi Jeremias, 

I’ve just had a look at the item monitor and can see exactly what you’re saying. The first page of the results are showing and there’s no option to page through the results that are on the next pages. 

Do you have a ticket reference for the support call you raised? We can get a problem record opened for this issue and have it fixed. If you have the reference number i’ll look into it for you.

Cheers,
Robert

Hello Robert,

unfortunately, I only have a ticket that has already been closed: 471802. It would need to be reopened or a new one created, and possibly additional information added, so that it remains understandable.

Thanks for your help!
Jeremias

Hi Jeremias, 

The ticket you’ve already logged should be enough for the issue above to be investigated further. I've reviewed the ticket and added some comments to it explaining in more detail the issue you’re experiencing. I’ve asked the support team to review it tomorrow morning and progress as a defect - they should be back in touch with you shortly.

Cheers,
Robert

Hello Jeremias,

We are in the process of re-opening your incident 471802, and I can confirm that a defect has been identified. One of my colleagues from the Support team will contact you shortly and provide you with the relevant problem record number. Thank you very much for your patience throughout this process.

Best Regards,
Caroline

Hello Caroline,

we have recently updated to version 25R1 and encountered the same issue. Since the original post is a bit older, I’m wondering if a bugfix has already been released for this problem.

While reviewing the bugfixes for version 25R2, I came across this entry. Does it specifically address the issue we’re experiencing?​​​​​​​

Kind regards
Ersin​​​​​​​