要するに、はい、大丈夫です。
なぜなら:
1) AUTH_PROFILE_MODULE=Employee を使用すると、たとえば次のように Employee インスタンスを使用できるようになります。
def view(request):
employee_instance = request.user.get_profile()
2) カスタム権限の使用は簡単です。https ://docs.djangoproject.com/en/dev/topics/auth/#custom-permissions を参照してください。
編集:
組織に対するカスタム権限を持つことも可能です。マニュアルに記載されているように、次のようにプログラムで権限を作成するのがおそらく最善です。
content_type = ContentType.objects.get(app_label='myapp', model='Organization')
permission = Permission.objects.create(codename='can_do_something', name='Can Do something',
content_type=content_type)
これで、権限を意識した組織モデルができました。それをユーザーに割り当てるだけです。
さらに明確にするために:
Django 認証システムは一種の固定 ACL です。役割をユーザー (またはグループ) に割り当てれば、それで終わりです。Django は、特定の権限を持たないユーザーを簡単に除外するためのヘルパー ラッパー関数を提供します。実行時および/またはより一般的な方法で決定する必要がある場合は、オブジェクトに何かを行う権限があるかどうかを決定する必要がある場合は、本格的な ACL システム (および django.auth ではないもの) が必要であるか、そのような動作を自分でコーディングします。これは、ニーズと明らかにそれらのアクセス許可を管理する必要性に依存します。OPの場合、動作は修正されているため、これをコーディングするだけで満足することをお勧めします. しかし、ニーズはさまざまであり、ソリューションも異なります。Django auth は、ユーザー、グループ、または「プロファイル」オブジェクトに静的なアクセス許可を割り当てるのに適しています。それがアプリにとって何を意味するかは、最終的にはあなた次第です。
したがって、この場合、適切な解決策は、ユーザー/グループに割り当てられた「自分のドキュメントを表示できる」または「組織のドキュメントを表示できる」などの固定の権限セットを持つことです。そして、アプリはそれが何を意味するかを判断し、それに応じてドキュメントを提供する必要があります。アカウントのランタイム状態を取得するか、モデル構造を使用して、提供する適切なデータセットを決定します。