IMHO the needs to be solved in the backend before the pagination is done. This would require JpaIdentityProviderStorageProvider to return a list already sorted via the GUI order.

Doing this change, the GUI order would be used also to list the IDPs in the Admin UI.

Unfortunately the GUI order is not a table column, but a value in the attribute. I wonder what the Keycloak IAM team thinks about this, if the GUI order should be converted to a regular column and the existing data migrated. Having an attribute with is CLOB is difficult to handle in JPQL for sorting.

@keycloak/core-iam - can you please comment?

@ahus1 Thanks for your comment but can you please provide more details on your below statement:

"As long as there are only 10 IDPs, this is fine. Once there are more, this will lead to wrong results"

Since I tested it with more than 10 IDP's and it is working fine. I Even tested rendering 5-5 IDP's on page even when API returns more than 5 and they were rendered with correct GUI order only.

I see that the pagination is by default 5, so my comment should have been "As long as there are only 5 (unlinked) IDPs, this is fine."

@Ekamdeep3044 - looking at the following code that retrieves the unlinked IdPs, you see that it retrieves the first page of data, which will be 6 items given the default pagination of 5 items per page:

When analyzing this, you see that the items are returned ordered by the IDP alias, as specified in

https://github.com/ahus1/keycloak/blob/900c496ffe19b7413fab07130926bfc4465a1322/model/jpa/src/main/java/org/keycloak/models/jpa/JpaIdentityProviderStorageProvider.java#L294

Assuming the pagination of 5 items per page, and that your IDPs with aliases a,b,c,d,e have the display order 10,11,12,13,14,15, and the IDP aliases f,g,h,i,j have the display order 1,2,3,4,5.

The expectation would the to see on the first page f,g,h,i,j and on the second a,b,c,d,e

The current behavior is a bit more complicated as the page is retrieving the pagination size + 1 item. With your code change code change it will sort those 6 items, which will put the 6th item first as that one had the order 1, so you would see on the first page f,a,b,c,d.

Looking at the backend code you will also see that the linked accounts are already sorted in the backend (although a bit inefficiently as it will retrieve all items from the backend before sorting them), while the unlinked accounts are not sorted.

This is my analysis given the current code. Please give an example of both IDP aliases and display orders that you tested with.

@ahus1 Got it. Thanks..

Lets see what @keycloak/core-iam team says about having guiOrder as a column in IDP. That would be more convenient.

I generally agree with @ahus1 on this one. Not long ago we've made some improvements to IDPs and we've essentially given them their own provider to improve scalability along with some other tweaks. The initial plan was to keep the schema changes to the minimum so we didn't rework the guiOrder to promote it to a first-class attribute of the IDP (it currently exists as a config in a generic name-value table). Also, IIRC the login screens don't rely on pagination - they fetch every available IDP and sort them using the guiOrder in the UI, so we decided to leave that as is.

At that time the account console was still being reworked, so it probably missed the sorting in the UI. However, I do agree that we should probably make this sorted at the backend, and add a param to the API when fetching IDPs to control how they should be returned (by alias or by guiOrder). So I would personally vote to get this done in the backend.

@pedroigor Perhaps something for KC 27 as it will involve DB migration to move the guiOrder into a column in the IDP table?

However, I do agree that we should probably make this sorted at the backend

I think we have two options here for the account console:

• Do the proper JPA change and pagination, or
• fetching all IDPs that can be shown in the account console, sort them, and then return the relevant page to the user.

We never show IdPs that are linked to an organization, so would it be safe (enough) to assume that there are never that many IdPs in the account console that it would matter much? The pagination might be more relevant to the admin UI?

So we can do the sorting now, and the refactoring with the new column later.

BTW, we can do those JPA changes in any minor release (still) except when it leads to Java API changes (which might be the case, or or maybe not, I don't know yet).