ここに私が達成しようとしているものがあります：
管理者がDjangoでデフォルトとして働いている間に、私のアプリケーションにカスタムユーザモデルを持たせるには？
- 管理者ページにデフォルトの方法（ユーザー名とパスワード）を使用してログインしていますか？
- パスワードの代わりに電子メールを使用するカスタムユーザーモデルを使用して、ユーザーにWebアプリケーションを登録/ログインさせますか？また、私の管理者には必要ない他のデータも関連付けられています。
- 管理者アカウントとユーザーアカウントを別々のテーブルに分けます。
私はAbstracBaseUserを拡張することにより、カスタム・ユーザー・クラスを作成する方法を確認し、私が得た結果は、私の管理者は、新しいユーザー・タイプになったということです。では、デフォルトの管理システムをそのままにして、カスタムユーザーモデルを自分のアプリユーザーに使用させることはできますか？または、私のデザインに代わる良いものは何ですか？
推奨Djangoの練習ではなく、ユーザオブジェクトを拡張するよりも、ユーザーを指しOneToOneフィールドを作成することです - あなたは（たとえば）のみ必要な新しいモデルプロパティを飾ることにより、Djangoのユーザの上に構築、このように：
class Profile(models.Model):
user = models.OneToOneField(User,parent_link=True,blank=True,null=True)
profile_image_path = models.CharField(max_length=250,blank=True, null=True)
phone = models.CharField(max_length=250,blank=True, null=True)
address = models.ForeignKey(Address,blank=True,null=True)
is_admin = models.NullBooleanField(default=False,blank=True,null=True)
class Meta:
verbose_name = 'Profile'
verbose_name_plural = 'Profiles'
掘削時間が2時間以上になると、単一のユーザーモデルを維持し、規制にアクセス許可と役割を使用することが最善の方法だと思います。
ここで説明するように、複数の異なるユーザーモデルの認証を行う方法があります。How to have 2 different admin sites in a Django project?しかし、私はそれが私の目的にとって価値がないと決めました。
これは非常に説得力のある理由がありますか？ – e4c5
@ e4c5私はちょうど2つが違っていると感じ、混乱してはいけません。しかし私は私の個人的な偏見の他に本当に魅力的な理由はないと思います。私は標準的なデザインに行くと思います。 – Doge
標準的な設計は正当な理由があります。 2つのオブジェクトが類似している場合、それらは同じモデルでなければなりません。それらを区別するためにフラグまたは 'タイプの'列が必要です。そして、ユーザーモデルには既にそれがあります。実際にそのうちの2つ。 – e4c5