Are you bored with copying a customized person mannequin from one mission to different ones? Use this bundle by Evrone!

Everybody is aware of that Python has a very fashionable Django framework. By default, the person mannequin there contains an electronic mail, username, and password. However there are sometimes conditions the place it’s needed to increase and change the default person mannequin.

For instance, there are conditions the place we don’t want a username, solely an electronic mail. Or we’d like a cellphone quantity as an alternative of an electronic mail, and the e-mail is just not essential. In these kinds of conditions, the default mannequin ought to be modified to a customized one which incorporates the related fields. So, the aim of the django-swap-user mission is to exchange an present mannequin with a customized one.

As well as, authorization by one-time code is now starting to realize reputation. So we accounted for this state of affairs within the library as nicely. When a brand new person mannequin seems, it has just one area—electronic mail or cellphone quantity—and a one-time passcode. There isn’t any password saved within the database, and a one-time passcode is shipped utilizing any supplier that you just join. You get a one-time SMS, which you need to use to log in.

Why did we write a whole library for this? After we begin new tasks, we frequently want a customized person mannequin. Beforehand, we copied every thing from one mission to a different, however then we realized—why always copy, when you possibly can write a library as soon as and that is it. We needed to discover a ready-made library, however all of the ready-made ones had been deserted or out-of-date. So our Python Teamlead, Artem Innokentiev, determined to jot down this wrapper himself and open-source it.

So, if you’re bored with copying a customized person mannequin from one mission to different ones—use this bundle. It can do all of it for you!

Set up

pip set up django-swap-user

Structure

Software swap_user is break up into a number of apps:

• to_email – gives person with electronic mail username area
• to_email_otp – gives person with electronic mail username area and OTP (One Time Password) authentication
• to_phone – gives person with cellphone username area
• to_phone_otp – gives person with cellphone username area and OTP (One Time Password) authentication

Why such an uncommon structure?

If we depart them in a single app, they may all create migrations and tables, resulting in redundant tables. They are going to be handled as three customized fashions throughout the identical app, which causes confusion.

With this strategy (the place there’s a frequent app which accommodates inner apps), the person can select and join solely the precise person mannequin greatest fitted to concrete enterprise logic.

We modeled this strategy after the Django REST Framework authtoken utility, referenced right here.

Using a customized person mannequin in the beginning of a mission

When you’re beginning a mission from scratch, that is the very best time to combine a customized person mannequin, because you haven’t had plenty of migrations or you possibly can simply regenerate them. Furthermore, Django’s official docs advocate that you just use a customized person mannequin, even if you’re absolutely happy with the default one. Sooner or later, will probably be simpler to increase a customized mannequin to suit your use instances.

Incorporating a customized person mannequin in the midst of a mission

Including a customized person mannequin in the midst of a mission is a more durable means of doing issues, however it’s nonetheless potential.

• Full all of the steps within the testing database and—ONLY IF all of them had been profitable—attempt to apply it within the manufacturing setting
• Please word that these steps match most instances, however in some circumstances, you might have to adapt to the state of affairs
• Create a backup of your database
• Add steady tag into your repository or save a commit hash reference
• Pray 😀
• Take away your entire migrations in each app of the Django mission
• Take away all data from django_migrations desk, for instance, with SQL TRUNCATE django_migrations
• Now you may have a “clear” state, so you possibly can change the default mannequin
• Generate new migrations for your entire functions—python handle.py makemigrations
• Now you must pretend migrate, as a result of you have already got all of the tables with information
• First, pretend the auth utility, since you are relying on this one: python handle.py migrate --fake auth
• Set up the library, comply with the directions, and apply migrations
• Then, pretend the remainder of the migrations you may have—python handle.py migrate --fake
• Run your utility!

Plans for the long run

Sooner or later, we plan to jot down higher documentation and add implementation to the mission. We are going to slowly add new authorization strategies, for instance, combined ones. There are instances the place you must do authorization both by electronic mail or by cellphone, and we wish to add this.

In the meanwhile, everybody can use this mission, and we’d love to draw members of the neighborhood to contribute and assist with the event of the mission!

And, in fact, attain out to us through the shape beneath if you must develop an open-source resolution or are in search of a group of execs to construct a mission from scratch!