Django management command to migrate existing users

[PedroBern]

We could add a django management command to handle user verification/status creation for old users when the dev team opts to use this package at mid-project. Also would be helpful having a specific flag for superuser and staff, making it easy to create a new staff or superuser without needing to verify by email or hardcoding on django shell.

[ulgens]

I agree on the need but i think we also need an option to disable verification completely.

[PedroBern]

I agree on the need but i think we also need an option to disable verification completely.

Yes, I agree, I mean handle the verification by overpassing it for old users. Maybe it will require a new field in the UserStatus model, something like "skiped_verification", a boolean field, so we can know which user was verified and which one was not. All along with other options, like disable verification completely as you said, in case if the verification process is not used at all.

[bzhr]

I am using this library in a project that is in development and this project has a custom admin, from which new admins are created with is_staff=True.

Maybe should be in a separate issue, but when allowing the is_staff variable for register mutation the variable is:

• String, should be boolean
• Any non-empty string resolves to True and empty string "" resolves to false.

Let me know if this needs to be in a separate issue, I'll create it.

Settings:

'REGISTER_MUTATION_FIELDS': ['email', 'first_name', 'last_name', 'is_staff']

[PedroBern]

Hi @bzhr String is the default behavior, you should check the dynamic fields basics and use the REGISTER_MUTATTION_FIELDS as a dict, like this:

'REGISTER_MUTATION_FIELDS" : {
    # ...
    "is_staff": "Boolean"
}

Maybe should be in a separate issue

Yes, but it's ok, this can be solved easily (shown above). Please if you have more problems with this, open a new issue.

[bzhr]

This solves this issue. Thank you.

However, connected to this, is there a pattern to constraint the register mutation with a staff_required decorator, so that only staff members can create admins?

So maybe I will use the register mutation twice, once with staff_required and once without.

[PedroBern]

@bzhr Currently not, but you can probably handle this on the client-side.

[bzhr]

@PedroBern Not urgent but probably needs to be done. I may offer a solution in the next few months. Currently I handle it on the client side, but don't feel so good when I know that an admin can be created by just passing the isStaff=true gql variable.

[lacksonmunthali]

What about tokenAuth mutation for just is_staff or is_superuser?