Fix for #244

[73VW]

Hello @mostafa,

Here's a starting point for a fix for #244.

I am not really sure how I should implement a test for this nor if this is the best way to implement it.

Tell me what do you think about this.

Cheers!

[CLAassistant]

All committers have signed the CLA.

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.

---

Mael Pedretti seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[github-actions]

This PR is stale because it has been open 45 days with no activity. Remove stale label or comment or this will be closed in 10 days.

[github-actions]

This PR was closed because it has been stalled for 10 days with no activity.

[mostafa]

Hey @73VW,

Thanks for your contribution! Please fix the tests and address the comment.

[73VW]

Hello @mostafa,

Thank you for your reply!

This is a breaking change and I don't know if you want to merge it as is because backwards compatibility won't be ensured. Is that fine for you?

[grenbeg]

@mostafa Is it possible to progress this PR? It's causing issues in ours repos that implement the package as we're not passing email as username, so would be great to be able to have this in a new version as soon as possible.
If backwards compatibility is a concern, seems to me that the PR simply needs to pass email as a kwarg when calling create_new_user. My proposal is the only change required to fix the issue is, on line 121:

email = user.get(user_model.EMAIL_FIELD)
kwargs = {"email": email} if email else {}
target_user = create_new_user(user_id, user["first_name"], user["last_name"], **kwargs)

I believe this will be backwards compatible.

Thanks!

[mostafa]

@73VW WDYT?

[73VW]

Hey @mostafa @ben-qr,

My implementation is the following:

    for field in [
        FIRST_NAME_FIELD_NAME,
        LAST_NAME_FIELD_NAME,
        user_model.EMAIL_FIELD,
    ]:
        if field in user:
            kwargs[field] = user[field]

Which is pretty much what @ben-qr suggested, right?

I can't remember exactly why I said this was a breaking change, anyone has an idea? It's quite an old topic.

[mostafa]

@73VW The reason you mentioned it's a breaking change is that currently the trigger receives positional arguments, which you converted to keyword arguments, hence a breaking change.

I'll see how I can improve this.

[Copilot]

Pull Request Overview

This PR refactors the user creation functionality to accept a user dictionary instead of separate parameters, addressing issue #244. The change simplifies the API by consolidating user information into a single parameter while maintaining backward compatibility for field mapping.

• Refactored create_new_user function to accept a user dictionary instead of individual parameters
• Added constants for field names to improve maintainability
• Updated function call site to pass the new parameter structure

Reviewed Changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 3 comments.

File	Description
django_saml2_auth/user.py	Refactored user creation function signature and implementation to use dictionary-based user data
AUTHORS.md	Added contributor to authors list

---

_{Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.}

[Copilot]

The function signature change from create_new_user(email, first_name, last_name, **kwargs) to create_new_user(user_id, user, **kwargs) is a breaking API change. Consider deprecating the old signature first or providing backward compatibility to avoid breaking existing code that calls this function directly.

[Copilot]

[nitpick] The loop iterates over a mix of string constants and a dynamic field name (user_model.EMAIL_FIELD). Consider extracting this list to a function or making all field names consistent in their source (either all constants or all from the model).

[Copilot]

The first parameter to create_user is typically expected to be a username or email, but now user_id is passed. This could break if the user model expects the first parameter to be an email address and user_id is not email-formatted.

[73VW]

@73VW The reason you mentioned it's a breaking change is that currently the trigger receives positional arguments, which you converted to keyword arguments, hence a breaking change.

I'll see how I can improve this.

Yes you are right, sorry. I'll try to think a bit more about this.