問題タブ [django-users]

カスタムフィールドを使用してユーザーモデル（Djangoの認証アプリにバンドルされている）を拡張するための最良の方法は何ですか？また、（認証目的で）ユーザー名として電子メールを使用したいと思います。

私はすでにそれを行うためのいくつかの 方法を見てきましたが、どれが最良であるかを決めることはできません。

ログインを持っていないユーザーのサブセットを作成したいと思います... 基本的に、その人に関連付けられた本格的なアカウントを持たずに写真家フィールドを写真に追加する方法として (多くの場合、彼らは実際にサイトにログインすることはありません)。注意点は、後でそれらのアカウントを有効にできるようにしたいということです.

したがって、UserProfile を使用して User テーブルを実際に拡張せずに、User テーブルに関連付ける「People」テーブルを設定する最善の方法は何かという問題になると思います。

Django CRUD 管理サイトのユーザー リストにサブスクリプションの日付を追加したいだけです。どうやってやるの ？

ご協力ありがとうございました

作成したカスタムマネージャーで現在ログインしているユーザーにアクセスしたい。これを実行して、結果をフィルタリングして、アクセスできるオブジェクトのみを表示できるようにします。

実際に渡さずにこれを行う方法はありますか？request.userを実行できるビューでの動作と似ています。

ありがとう

標準のDjangoAdminを使用しないマルチテナントアプリケーションを作成しています（すべてのテナントにアクセスできる内部使用を除く...これは非常に簡単です）。独自の認証システムを作成しようとしていますが、標準のユーザーモデル（または組み込みアプリケーションのモデル）を使用することに興味がありません。私のアプリケーションにはアカウントがあり、各アカウントには管理者がいます（名前の衝突のために管理者とユーザーを使用する必要がありました）。それらのユーザーは、私自身の完全にカスタムのシステムを使用して認証します。これはすべて間違っていますか？独自のカスタムインターフェイスを使用するマルチテナントの状況で、Djangoの認証システムを引き続き使用する必要がありますか/できますか（前述のように、アカウント所有者がデフォルトの管理インターフェイスを使用することを許可しません）。

多くのDjangoは、独自の管理者でマルチテナントSAASソフトウェアを構築するのではなく、管理インターフェースを使用するという考えに基づいて構築されているように思われます。私はこれをすべて間違っていると思っていますか？

私は SAAS を開発していて、自分以外の何かに「ユーザー」を使用する必要がある理由について頭を悩ませています。理由はわかりませんが、ソフトウェア全体の開発者/管理者として、(Eye of Sauron のように) 完全な Django 管理者アクセス権を持つ私が、"アカウント" 所有者の "UserProfile" が持っています。なぜこれが必要なのかを理解するのを手伝ってください。

例：

ビルトインの管理者機能とアカウント所有者のユーザー機能を混ぜ合わせているような気がします。これは、request.user などの要素を再利用するためだけのものですか?

私は大規模な顧客ベースを持つdjangoサイトを持っています。カスタマーサービス部門に、パスワードやメールアドレスの変更など、通常のユーザーアカウントを変更できるようにしたいと思います。ただし、組み込みのauth | user | Can change user権限を誰かに付与すると、そのユーザーはis_superuserフラグを設定できるようになります。アカウント、自分自身を含む。（!!!）

スーパーユーザー以外のスタッフがこのオプションを削除するための最良の方法は何ですか？サブクラスdjango.contrib.auth.forms.UserChangeForm化して、すでにカスタムしているUserAdminオブジェクトにフックする必要があると確信しています...どういうわけか。しかし、これを行う方法についてのドキュメントが見つからず、内部を十分に理解していません。

ユーザー オブジェクトをカスタム フィールドで拡張するには、Django ドキュメントではUserProfilesの使用を推奨しています。ただし、1年ほど前のこれに関する質問に対するこの回答によると：

モデル API での Django の継承コードのリファクタリング以来、django.contrib.auth.models.User の拡張もより適切に機能するようになりました。

また、このような記事では、ユーザー モデルをカスタム フィールドで拡張する方法と、利点 (.get_profile() ではなく、ユーザー オブジェクトから直接プロパティを取得する) について説明しています。

したがって、この問題についてコンセンサスがあるかどうか、またはどちらか一方を使用する理由があるかどうか疑問に思っていました。それとも、Django チームは現在何を考えているのでしょうか?

デフォルトを外部キーとして使用するclass UserProfile定義があります。user今、別の人class Aはへの外部キーを持っていますUserProfile。
したがって、クラスAのインスタンスを保存するには、userprofileオブジェクトを指定する方法を教えてください。

また、まだ使用されており、他のテーブルにすぎないclass UserProfile平均を作成しますか？ ユーザープロファイルの作成を処理する必要があるため、これを知る必要があります。したがって、何がどこに保存されるかを知る必要がありますか？ class userclass UserProfile

- 混乱している

Model タイプの関連リストを取得するために、Django のデフォルトの User モデルに新しい関数を追加したいと考えています。

そのようなFooモデル：

.........

これはどのように達成できますか？