関連するリンク
コメント
ページツリー実装に必要最低限の権限の設計です
要約
- 子ページの権限は親ページと同じかそれより強いものでないといけません。
- 仮にグループ単位で見た時に groupB の権限が groupA の権限より強かったとしても、group の家系が異なれば親ページが groupA, 子ページが groupB とすることはできません
- 強いというのは、groupA (user1, user2), groupB (user1) があった時、groupB の方が権限が強いです
移動と権限の仕様
ページの grant 一覧
- GRANT_PUBLIC = 全てのユーザーに公開;
- GRANT_RESTRICTED = リンクを知っている人のみ;
- GRANT_SPECIFIED = 特定ユーザーのみ; <- 使われてないけど一応考える
- GRANT_OWNER = 自分のみ;
- GRANT_USER_GROUP = 特定グループのみ;
用語定義
-
ユーザーグループの「親グループ」「子グループ」「完全・一部排他グループ」
- GroupA: ユーザーA
- GroupB: ユーザーA、ユーザーB
- GroupC: ユーザーA、ユーザーC
- GroupD: ユーザーD
があるとする。このとき、
- GroupA は GroupB の「親グループ」
- GroupB は GroupA の「子グループ」
- GroupB と GroupC は「完全・一部排他グループ」
- GroupA と GroupD は「完全・一部排他グループ」
- GroupB, GroupC と GroupD は「完全・一部排他グループ」
-
リンクを知っている人のみ
- ページツリーの leaf node (先端のページ)に表示できないという制限のみ
-
特定ユーザーのみ、自分のみ、特定グループのみ
- グループに親子関係を持たせるにあたって、これらはまとめて考える必要がある
- grant の種類によらず、最終的に「どのユーザーが権限を持っているかという値」に換算されてページ移動の可否が決定する
-
パブリック(全てのユーザーに公開)
- 「パブリック」はいかなるユーザーグループ指定ページの配下に来ることはできない
- 逆に、いかなるユーザーグループ指定ページは子ページにパブリックページを持つことができない
- /Public、/Public/Private は存在できるが、/Private、/Private/Public は存在できない
-
「親グループ以上」のグループ
- GroupX の「親グループ以上」のグループは、GroupX を含む GroupX の親グループ群
- Group1: (user1, user2, user3) のとき、Group1 の「親グループ以上」のグループは、(user1, user2, user3), (user1, user2), (user2, user3), (user3, user1), (user1), (user2), (user3) の7つのうちどれか
-
「子グループ以下」のグループ
- GroupY の「子グループ以下」のグループは、GroupY を含む GroupY の子グループ群と「パブリック」
決定案
以下のルールを強制する
- 子ページは親ページの「親グループ以上」のユーザーグループを持たなければならない
- 親ページは子ページの「子グループ以下」のユーザーグループを持たなければならない
- メリット
- ページを移動するときなどに権限のルールがシンプルできれい
- デメリット
- マイグレーションする際、過去バージョンに存在するページで親ページと子ページが「完全・一部排他グループ」を持つ時に移動を強いられる
デメリットが発生する例1
以下のページが存在していたとする。
- /A パブリック
- /A/B ユーザーA の onlyme
- /A/B/C ユーザーB の onlyme
パターン1: 先にユーザーA が /A/B をマイグレートした場合
この時 /A/B 以下には ユーザーA の onlyme の「親グループ以上」のページしか存在できない。すなわちユーザーA の onlyme ページしか作ることができないためユーザーB は敢えなく /A/B/C の位置を変えることを強いられてしまう
パターン2: 先にユーザーB が /A/B/C をマイグレートした場合
このとき、/A/B/C より上のページには、ユーザーB の onlyme の「子グループ以下」のページしか存在できない。すなわち ユーザーB の onlyme または「パブリック」ページしか存在できないため、ユーザーA は敢えなく /A/B の移動を強いられる
デメリットが発生する例2
以下のページが存在していたとする。
- /A パブリック
- /A/B ユーザーA の onlyme
- /A/B/C パブリック
この時、/A/B/C より上にはパブリックページしか作ることができないため、ユーザーA は /A/B を別の場所に移すか、/A/B/C をユーザーA の onlymeにすることで /A/B に配置するかの2択になる
ユーザーがユーザーグループのコンフリクトを回避する手段
以下のどちらか
- コンフリクトしたページのユーザーグループが条件を満たすようにする
- ページのパスを条件を満たすように変更する
懸念点・思うこと
- そんなに多くのコンフリクトが発生するわけではないと思う
- 仮に多くのコンフリクトが起こると管理ユーザーはユーザーグループの整理をしないといけない
- ユーザーグループの仕様が大幅に変更になるのでバックエンドをシビアにテストコード書いていく必要がある(時間がかかる)
UserGroup 設計
7Vjfb5swEP5b9pDXiR+hSx5L2nWT2m1qNO3ZxRfwamxqzEj21+8MJoQQ1nZtomlDQkru89ln3/fZPnniL9L1lSJZciMp8Inn0PXEv5h4njubzvHHIJsamc2DGogVo9apBZbsJ1jQsWjBKOQdRy0l1yzrgpEUAiLdwYhSsuy6rSTvRs1IDD1gGRHeR78xqhO7isBp8Q/A4qSJ7Dq2JSWNswXyhFBZ7kD+5cRfKCl1/S9dL4Cb5DV5qfu9H2jdTkyB0E/q4NU9fhBe2MV9zUFdKVlkdoZ60yw7L1nKiUArXEmhl7bFQTtKGKfXZCMLEzbXJLpvrDCRiv1Ef8KxyUUAm5W2rPpOx2NpetoxFeTo86VZi7sH3ZB1x/Ga5LqZjeScZDm7q+ZnOqZExUyEUmuZWie7cFAa1oPZc7ecoJhBpqDVBl2aDlNLo9Wx61u7bFXhNdwnu4qYWZBYJcbbsbfhblG5RMS4hG28oBsu6EebHwjm78UiXIMSREMoC0HzXX3gn511tlClmgEF+T0FFY2CPqLPeaUhxUTc0xMmXldyUPIeFpJLhbiQtcAY53sQ4SwWaHJYmW6GOYZ78tzCKaPUjBzmGYkw3HXldjFtkVubEwNJ7L7i1dZLsCPgCGEmmdBVkoIQP0zbwnkbTAKc6wJtt7XxM+5KL6TA6RNW6QVQgSUYFYZKaqLJ3XZ/PE1s3mG1bbo8Piaufb53tdUh+nesTnusCpJCl04cxVHwUDAFtLYKwR7QfyT6RUSfnZLooEd0pAAPB3qua7Yv0BgZfRmj81MyetZjFIulSLFMMynGA/n1WHW9U9L6rkdrM1XD6HDVNpL6PFIPVFXHI3U2XH7fAifVjh3L8EfK8GkQ/GEZ7v07Zfi8pyRlBAS0PhWqQ+Lz3XdcDVbl4xnxiN5mf00l3ki0T6w5KUZeX5PXUxbezfTGwvuYjJ6y8Pb6b2mfoHwzRGGi0/Ymfh6bES7f7P1hPsuEaVgihSZmqUhW5RfvGaCvd+/Ou/fgoYvw7Fi57r86/V+5nh0t12i27891JdK+4vuXvwA=
-
C
- グループ作成
- 子グループ作成
- 既存のグループを子グループにする
- 新規でグループを作って追加する
-
R
-
U
- グループの更新
- ユーザーの追加
- 親グループ全てに追加
- ユーザーの削除
- 子グループ全てから対象ユーザーを削除
- 親の変更
- 自分の子グループ以外を親にすることが可能
- GroupB の親を GroupA に設定した時、GroupB のメンバー全員が GroupA のメンバーになる(Force update)
- この際、親グループにユーザーを追加したくない場合は force update を unable にすることができる(Unable force update)
- ユーザーの追加
- グループの更新
-
D
- 親の削除
- 子供全て削除
- 子グループの削除
- 子供全て削除
- 親のみ削除は不可能
- Github リスペクト ✨
- やりたい場合は子グループの parent を変更することで可能
- 親の削除
-
いるかどうかわからない機能
- グループの複製
その他の仕様
ページ移動による Empty ページの挙動
- Empty ページが存在していたところにページが移動された場合、その Empty ページは削除される
ユーザーグループルール早見表
TBD!
Case \ Comparable Kind | Ancestors | Target | Descendants |
---|---|---|---|
✅ | public | public | x |
❌ | owner | public | x |
❌ | user group | public | x |
✅ | public | public | public only |
✅ | public | public | owner |
✅ | public | public | user group |
XXX | public | public | mix (owner & user group) |
XXX | public | public | mix (all) |
✅ | public | owner | x |
✅ | owner | owner (same) | x |
❌ | owner | owner (different) | x |
✅ | user group | owner (belongs to user group) | x |
❌ | user group | owner (does NOT belongs to user group) | x |
❌ | public | owner | public |
✅ | public | owner | owner |
✅ | public | owner | user group |
✅ | public | owner | mix |
✅ | public | user group | x |
❌ | owner | user group | x |
❌ | user group | user group | x |
✅ | public | user group | public |
✅ | public | user group | owner |
✅ | public | user group | user group |
✅ | public | user group | mix |
Commments