Register staff by admin account

[PedroBern]

Currently, we can use the REGISTER_MUTATION_FIELDS to specify which fields we want to be at the registration, but @bzhr pointed out that it can lead to some problems when we need to make sure for example to allow only admin users to create staff users.

An easy fix for this, in my opinion, would be building a new mutation, something like InternalRegister that works very similar to the Register, but for the admin users use in mind.

Some specification:

• [ ] Only admin or staff users have access
• [ ] New setting to define who has access to it (superuser or staff)
• [ ] New setting to specify behavior, for example, maybe the email verification isn't necessary for staff users.
• [ ] What else?

---

@bzhr can you work on this?

[bzhr]

@PedroBern Thanks for preparing this. Yes, I can work on this and I need this in my project. But, currently async email is more urgent feature in the project that I work on.

The specification of the feature looks good to me. The main thing is to provide an alternative register and relayRegister mutations that will include the @staff_required decorator from the jwt library.

My plan is to work on the async email feature in the next 3-5 days (if somebody else doesn't do it before me). Then I will focus on this issue, probably somewhere in the next 5-10 days.

[PedroBern]

@bzhr perfect, I did remove the v0.4 milestone so we release it soon (v0.4 is to support django-graphql-jwt 0.3.1).

@PedroBern Thanks for preparing this. Yes, I can work on this and I need this in my project. But, currently async email is more urgent feature in the project that I work on.

You are very welcome! Can I assign you for both?

The specification of the feature looks good to me. The main thing is to provide an alternative register and relayRegister mutations that will include the @staff_required decorator from the jwt library.

Yes, you are going to create a new mixin and then create the mutation and relay mutation. Although, instead of support only the @staff_required, we should support @staff_required or @superuser_required, based on a new setting. If you want, you can create a custom decorator instead of reusing from jwt, but it's your call. Or maybe would be better to use @user_passes_test and build the logic based on the settings to resolve for staff or superuser.

[bzhr]

Yes I will do both. for async email we can discuss the specifics in the relevant issue

[bzhr]

This week I will work on this issue. @PedroBern I will send questions if I have any, cheers :)

[PedroBern]

@bzhr ok! :)