Skip to content

Conversation

@konac-hamza
Copy link
Contributor

No description provided.

Copy link
Collaborator

@gtema gtema left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

no, this is not the way how the provider should be implemented. You can extend the existing UserListParameters with the dedicated user type and pass it down to the regular listing function. Otherwise the provider interface is simply going to explode.
Whether on the API level it make sense to expose it as a separate endpoint is a different question (which I am not able to answer as of now). For sure such new API will not go under the /v3

@konac-hamza konac-hamza force-pushed the feature/extend-identity-api branch from 332d931 to d75b9c7 Compare December 17, 2025 19:44
@konac-hamza
Copy link
Contributor Author

konac-hamza commented Dec 17, 2025

no, this is not the way how the provider should be implemented. You can extend the existing UserListParameters with the dedicated user type and pass it down to the regular listing function. Otherwise the provider interface is simply going to explode. Whether on the API level it make sense to expose it as a separate endpoint is a different question (which I am not able to answer as of now). For sure such new API will not go under the /v3

Could you review implemented UserType enum, please? If it looks ok, i'd like to start backend implementation.

Copy link
Collaborator

@gtema gtema left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Problem with adding this in v3 is that for the user/client there is absolutely no way to figure out whether it is supported or not. When request goes to python keystone it will silently ignore it.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is fine

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this is fine in the concept, but we are not going to expose this in the api v3 (so far). I suggest first you focus only on the backend/provider part. In the separate PR you can then start relying on that, but only in the v4 api (or at least we can have a separate discussion in the dedicated PR)

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

please remove this part of the change - no api changes for now

@konac-hamza konac-hamza force-pushed the feature/extend-identity-api branch from d75b9c7 to 8477676 Compare December 21, 2025 20:44
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

please remove this part of the change - no api changes for now

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

let's not duplicate the logic. This is something what we can integrate into the main listing method

use crate::identity::types::*;

/// Prepare the paginated query for listing local users.
fn get_list_query(
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I strongly discourage from adding this in this change - you make the change bigger and harder to review

#[serde(default, rename = "type")]
pub user_type: Option<UserType>,

/// Page marker.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

let's not add anything about the pagination in the scope of this change

@konac-hamza konac-hamza force-pushed the feature/extend-identity-api branch from 34bd711 to 4a434aa Compare December 23, 2025 21:50
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants