Skip to content

adds sso_identifier to /admin/users#6491

Open
Katzenkralle wants to merge 8 commits intodani-garcia:mainfrom
Katzenkralle:sso_identifier
Open

adds sso_identifier to /admin/users#6491
Katzenkralle wants to merge 8 commits intodani-garcia:mainfrom
Katzenkralle:sso_identifier

Conversation

@Katzenkralle
Copy link

@Katzenkralle Katzenkralle commented Nov 24, 2025

Includes sso_identifier in JSON return of /admin/users

Fixes #6413

@Timshel
Copy link
Contributor

Timshel commented Nov 27, 2025

I had added it only to /users/overview since it's the only one neeeded for the admin table.

But it would probably make sense to return the same json object in all of /users/overview, /users, /users/by-mail/<mail> and /users/<user_id> ?

@Katzenkralle
Copy link
Author

Sure, all paths now return the same object

@BlackDex
Copy link
Collaborator

BlackDex commented Feb 2, 2026

Looking at this right now.
And i think we should not change the response key format, so that should be kept camelCase.
This does mean we need to adjust the template to match, else those will break, but since everything else is in camelCase we should stick with that and definitely not mix them.

Further, I also do not like that get_user_or_404 now always returns a tuple with two items, while only one function call is really using this.

I think it's more idiomatic and less error prone to create a new function, something like get_sso_user() and call that separately at the only location where this is needed.

What do you think @stefan0xC?

@stefan0xC
Copy link
Contributor

I am not really the person to ask when it comes to idiomatic Rust as that is not my area of expertise but I agree that this can probably be improved and simplified.

With regard to the change of the response key format I think it would also be fine to adapt the templates. Maybe we could mention it in the release notes that the templates have changed and/or that they will break for users that have customized them?

Comment on lines 530 to 540
pub async fn find_by_uuid(uuid: &UserId, conn: &DbConn) -> Option<(User, Option<Self>)> {
db_run! { conn: {
users::table
.left_join(sso_users::table)
.select(<(User, Option<Self>)>::as_select())
.filter(users::uuid.eq(uuid))
.first::<(User, Option<Self>)>(conn)
.ok()
}}
}

Copy link
Contributor

Choose a reason for hiding this comment

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

I think this can now be simplified to just return the SsoUser entry?

Copy link
Author

Choose a reason for hiding this comment

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

Sure, I originally had it keep returning User for all other find_by_XXX calls of SsoUser returned it, so I thought it might be beneficial for future use.

src/api/admin.rs Outdated
Comment on lines 307 to 310
async fn get_sso_user(user_id: &UserId, conn: &DbConn) -> Option<SsoUser> {
SsoUser::find_by_uuid(user_id, conn).await.and_then(|user_and_sso| user_and_sso.1)
}

Copy link
Contributor

Choose a reason for hiding this comment

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

This function would become obsolete if SsoUser::find_by_uuid were to return an Option<SsoUser>.

src/api/admin.rs Outdated
usr["lastActive"] = match u.last_active(conn).await {
Some(dt) => json!(format_naive_datetime_local(&dt, DT_FMT)),
None => json!(None::<String>),
None => json!("Never"),
Copy link
Contributor

Choose a reason for hiding this comment

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

I think that it would probably be cleaner to return nothing here and have the template render Never if that is possible. That way the Admin template can also be translated.

src/api/admin.rs Outdated
#[get("/users")]
async fn get_users_json(_token: AdminToken, conn: DbConn) -> Json<Value> {
let users = User::get_all(&conn).await;
async fn get_users_property(users: Vec<(User, Option<SsoUser>)>, conn: &DbConn) -> Vec<Value> {
Copy link
Contributor

Choose a reason for hiding this comment

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

Just as an idea but maybe we could rename the function so it's clearer what it does? E.g. enrich_users_json or something like that.

Copy link
Contributor

@stefan0xC stefan0xC left a comment

Choose a reason for hiding this comment

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

Seems to work okay:
Image

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.

"SSO Identifier" not returned from /admin/users API

4 participants