RBAC、何日も考えているのですが、その役割は何ですか？

RBAC では、役割があまり明確ではありません。たとえば、営業マネージャーと済南営業マネージャー、これら 2 つの概念は非常に曖昧です

1 つは営業マネージャーを指しますが、どの地域の出身であるかは示されていません

もう 1 つは済南のことを指しますが、非常に具体的です

すべての地域の営業マネージャーが同じ権限を持っているため、その役割が具体的であるか曖昧であるかを尋ねたいのですが、営業マネージャーの役​​割は、すべての地域の営業マネージャーに一律に権限を与えるために確立されています。マネージャーは 1 つの地域に設置することはできません。 マネージャーの役​​割は何ですか

役割の位置付けは何ですか?この場合、ロール権限スキームをどのように確立すればよいでしょうか?

Zhihu、http://zhi.hu/7dCn では誰も回答しませんでした

SegmentFault、http://segmentfault.com/q/1010000000650304 では誰も回答しませんでした

助けてください。 。 。 。 。 。 。 。 。 。 。 。

お久しぶりです。 。 。 。 。 。 。 。

ディスカッションへの返信 (解決策)

これはメンバーシップ権限と同じではありませんか? 権限をどのように設計するかによって異なります
タイプ 1: 営業マネージャーはどこにいても同じ権限を持ちます
次に営業マネージャー権限グループのみが必要です
2 番目のタイプ: 営業マネージャーはすべて同じ権限を持っていますが、地域が異なると異なる権限を持ちます
営業マネージャーは基本クラスのようなもので、済南営業マネージャーは営業マネージャーを継承し、他の個別の権限を派生します
データベースのデザインは二次ナビゲーションのようなものです。済南営業マネージャーの上司は営業マネージャーです

これはメンバーシップの権限をどのように設計するかによって異なります
最初のタイプ:営業マネージャーはすべて、どこにいても同じ権限を持っています
その場合、必要なのは営業マネージャーの権限グループだけです
2 番目のタイプ: 営業マネージャーは同じ権限を持っていますが、地域が異なると異なる権限を持っています
営業マネージャーは基本クラスのようなものです、Jinan営業マネージャーは営業マネージャーを継承し、他の個別の権限を派生します
データベースの設計は、済南営業マネージャーの上司が営業マネージャーです

。 。 。 。

、、許可グループ?各場所の営業マネージャーは同じ機能権限を持っていますが、データ権限は異なります

。それらがすべて継承される場合、パーティションを追加することでロールがいくつ作成されるでしょうか。 。 。

ご回答ありがとうございます。 。あはは、実は、役割、データ権限、機能権限を設計する方法を知りたいのです。

結局のところ、新しい地域営業部門を作成すると、営業マネージャーの機能権限は同じになりますが、データ権限はその地域の人々に対してのみ異なります。 。

実は、もっと深刻な問題がもう一つあります。 。 。


一人の人間が複数の部門を管理し、異なる役職を兼務しています。 。 。許可グループでは解決できないはずです

次の方法は実行可能ですか?
部門リスト - 」人事テーブルID 1 1 1 2
2管理部門2 2 1 1 3次に、管理関係テーブルに移動して、彼が管理する部門を見つけます。彼が営業部門と回収部門を管理していることがわかります。わかりました、コピーして後で見てください

1 文字だけで十分です。それが属する領域の属性を持っているだけです。

役割とは、俳優が演じる劇のキャラクターを指します。これは、人生における特定のタイプのキャラクターや、オペラ俳優間の専門的な役割分担の比喩でもあります。

RBAC の役割は専門分業のカテゴリーに属します

営業マネージャーなどの特定の役割には、特定の権限があります

これは抽象的なものです

実際には、1 人の役割を複数の人が果たすことができます。複数の役を演じることもできます
これらはプログラムとは何の関係もありません。プログラムは役だけを認識し、人を認識しません

役とは、俳優が演じる劇中のキャラクターを指します。これは、特定の種類の俳優の比喩でもあります。人生の登場人物とオペラ俳優の専門的な役割分担。
RBAC の役割は専門分業のカテゴリーに属します

営業マネージャーなどの特定の役割には、特定の権限があります
これは抽象的なものです

実際には、1 人の役割を複数の人が果たすことができます。複数の役割を果たすこともできます

これらはプログラムとは関係ありません。プログラムは役割のみを認識し、人を認識しません


営業マネージャーは抽象的ですが、済南地区営業マネージャーはどうですか?それも抽象的？

この種のシステムは設計できません

すべての営業マネージャーが機能に分割されている、つまり、彼らが管理する領域にアクセスできないということは、役割によって解決されますか?

たった 1 人のキャラクターが、それが属する地域の属性を持っているだけです。

キャラクターに地域属性を追加しますか? ?

? ?では、ユーザーの役割をどのように設計すればよいのでしょうか? ? ? 、、

次の方法は実行可能ですか?
部門リスト - 」人事テーブルID 1 1 1 2
2管理部門2 2 1 1 3次に、管理関係テーブルに移動して、彼が管理する部門を見つけます。彼が営業部門と回収部門を管理していることがわかります


これは機能しません。 。

システムには営業マネージャーのみが存在し、済南地区営業マネージャーは存在しません
いわゆる済南地区営業マネージャーは、済南地区に登録されているユーザーの営業マネージャーとしてのみ表示されます
役割が設定されていますビジネス ニーズに応じて、誰か (特定の人) が特定の役割を果たすことを指定する必要があります

役割「リージョン マネージャー」を作成し、この役割に対応するリージョンへの動的リソース アクセス権を割り当てます。次に、ユーザーを追加するときに、「地域マネージャー」と「営業マネージャー」の役割を同時に与えるだけです。

役割と権限に関する問題。

【使用例】

システム管理者がユーザー A のアカウントを作成した後、彼に営業マネージャーの役​​割を設定し、「特定の地域のデータを表示する」権限を付与しました。地域が誕生しました。

もちろん、さまざまな地域の営業マネージャーの役​​割に多くの共通点がある場合は、営業グループを設定し、共通の権限を持つ営業役割をそれらに割り当てることができます。他の地域の営業マネージャーがシステムに参加する場合、営業グループに参加するだけで済み、管理者の構成がより便利になります。

役割と権限に関する問題。
【使用例】
システム管理者がユーザー A のアカウントを作成した後、彼に営業マネージャーの役​​割を設定し、「特定の地域のデータを表示する」権限を付与しました。地域が誕生しました。

もちろん、さまざまな地域の営業マネージャーの役​​割に多くの共通点がある場合は、営業グループを設定し、共通の権限を持つ営業役割をそれらに割り当てることができます。他の地域の営業マネージャーがシステムに参加する場合、営業グループに参加するだけで済み、管理者の構成がより便利になります。

あまり意味がありません、ありがとう、モデレーター、記事を読ませてください、後半の意味を理解するのを手伝ってください、私にはわかりません

http://kb.cnblogs.com/page/44144/

リズ、私のアドバイスを聞いて、落ち着いてよく考えてください。 権限の設計はシンプルであるほど良いです。

役割管理、機能管理、および上司と部下の管理の権限を分離できれば最善です。 。これは、たとえ彼が単なる低レベルの営業マンであっても、役割のために調整できなくなることなく、いつでもすべての機能を自由に利用でき、多数の組織を管理できることを意味します。

リズ、私のアドバイスを聞いて、落ち着いてよく考えてください。権限の設計はシンプルであるほど良いです...

役割管理、機能管理、上司と部下の管理の権限があれば最善です分離することができます。これは、たとえ彼が単なる低レベルの営業マンであっても、役割のために調整できなくなることなく、いつでもすべての機能を自由に利用でき、多数の組織を管理できることを意味します。

ねえ、あなたの言ったことは本当に良いことです。私はそれについて何日も考えています、笑

lz、あなたのアドバイスを聞いて、落ち着いて考えてください。権限の設計はシンプルであるほど良いです。

役割管理、機能管理、上司と部下の管理の権限を分離できれば最善です。これは、たとえ彼が単なる低レベルの営業マンであっても、役割のために調整できなくなることなく、いつでもすべての機能を自由に利用でき、多数の組織を管理できることを意味します。

まさにその通りです！
実際に使ってみると、色々な変なニーズが必ず出てくるので、シンプルで柔軟な方が良い
権限は思っているほど複雑ではありません

1. データモデルに関する限り、再帰ツリーそれだけで十分です
2. ビジネスに関する限り、必要なのは、権限をすばやく抽出し、ツリー内のノードをユーザーに割り当てることだけです

ご講演ありがとうございました。この問題について詳しく勉強します