Package: django-swap-user
Django-Swap-User (Beta)AboutIf you are tired from copying one custom user model from one project to another ones - use this package.
This will do all for you.Installationpip install django-swap-userBasic usageChoose one of models that suits for you and copy related settings from the table:Application nameUsername fieldDescriptionINSTALLED_APPSAUTH_USER_MODELReplacedjango.contrib.admintoto_emailemailUser withemailusername"swap_user", "swap_user.to_email","swap_to_email.EmailUser"not requiredto_email_otpemailUser withemailusername, withoutpasswordand OPT authentication"swap_user", "swap_user.to_email_otp","swap_to_email_otp.EmailOTPUser""swap_user.to_email_otp.apps.SiteConfig"to_phonephoneUser withphoneusername"swap_user", "swap_user.to_phone","swap_to_phone.PhoneUser"not requiredto_phone_otpphoneUser withphoneusername, withoutpasswordand OTP authentication"swap_user", "swap_user.to_phone_otp","swap_to_phone_otp.PhoneOTPUser""swap_user.to_phone_otp.apps.SiteConfig"Add corresponding app toINSTALLED_APPS:INSTALLED_APPS=[..."swap_user","swap_user.to_email",...]ChangeAUTH_USER_MODELto corresponding:AUTH_USER_MODEL="swap_to_email.EmailUser"If required replacedjango.contrib.admininINSTALLED_APPSto something.Apply migrations:pythonmanage.pymigrateswap_to_emailArchitectureApplicationswap_usersplit into 3 apps:to_email- provides user withemailusername fieldto_email_otp- provides user withemailusername field and OTP (One Time Password) authenticationto_phone- provides user withphoneusername fieldto_phone_otp- provides user withphoneusername field and OTP (One Time Password) authenticationWhy so unusual architecture?Because if we leave them in one app, they all will create migrations and tables - such approach leads us to redundant tables.
They will be treated as 3 custom models within the same app, which causes perplexing and cognitive burden.With such approach (when there is a common app which contains internal apps) - the user
choose and connect only the specific user model which suits best for concrete business-logic.I have found such approach at Django REST Frameworkauthtokenapplication and decide to use it - reference ishere.Providing User model at start of projectWhen you are starting a project from zero or scratch - this is a best moment to provide custom User model.
Because you have't a lot of migrations or you can easily regenerate them. Moreover, Django'sofficial docsrecommend to provide custom User model even if you are fully satisfied with default one - in future it will be easier to extend custom model that fits into your business cases.Providing User model at mid of projectThis is a harder way of doing things, but it is still possible to do:Do all the steps at testing database and ONLY IF all of them was successful - try to apply at production environmentPlease note that these steps arecommon- they fit in most cases, but in some circumstances you need act on situation.Create a backup of your databaseAdd stable tag into your repository or save a commit hash referencePray to the heavensRemove all of yours migrations in every app of Django's projectRemove all records fromdjango_migrationstable, for example with SQLTRUNCATE django_migrationsNow we have a "clean" state, so we can change default modelGenerate new migrations for all of your applications -python manage.py makemigrationsNow we need tofake migratebecause we already have all the tables with dataFirst fake theauthapplication because we are depending from this one -python manage.py migrate --fake authInstall this library, follow instructions and apply migrationsThen fake rest of migrations we have -python manage.py migrate --fakeRun your application!