Improvement:閲覧権限について

[hashiserver]

Environment

Host

item	version
OS
GROWI	3.5.24
node.js	10.17.0
npm	6.11.3
Using Docker	yes
Using [growi-docker-compose][growi-docker-compose]	yes

Client

item	version
OS	macos catalina
browser	chrome 78.0.3904.108

about

• グループについて
  グループ機能を使用して、閲覧制限をしようと思い設定しましたが閲覧権限がページごとになっているため、全てに設定が必要となっている。
  階層ごとに閲覧権限が設定できる。もしくは、閲覧権限は親階層に帰属するようになればいいなと思っています。
  理由としては、見せたくない内容があるとして閲覧権限を設定し忘れた場合表示できてしまう。閲覧権限の階層で新規ページを作成できてしまうためです。

[shield-9]

Related: #924

[yuki-takei]

ご意見ありがとうございます。権限周りは議論が尽きない箇所ですね。

#924 の「案1」のような便利機能追加の改修は今後なる早で(まずは管理画面の React 化という大仕事が終わってから)進めたいとは思っています。

一方で GROWI(前身の Crowi も)は Wiki というそもそもが自由にページや内容を変更できるシステムから出発していて、そこに「階層(カテゴリ)でグループ化」したり「タグでグループ化」したりといった切り口を加えているものになります。

階層ごとに閲覧権限が設定できる。もしくは、閲覧権限は親階層に帰属するようになればいいなと思っています。

のように、ある階層以下の情報をガチガチに当該グループが管理するようなシナリオでは、そもそもそのグループ専用の GROWI を別で立てたらどうかという案もあると思います。(一気通貫で検索したいとかそういう要望はあるのだとは思いますが)

[yuki-takei]

あとは、今投稿したコメントは考え方・管理手法に関する議論ですが、現在のデータモデルだと「GROWI の階層構造」というのは飽くまでも path attribute で階層構造チックな管理を模しているだけでファイルシステムの入れ子構造のようなものがあるわけではないので、実際設計しようとするとなかなか難しいという、実装上の壁もあります。

[tats-u]

あるページ(例: /page1)が特定メンバーにしか見れない制限がかかっているとして、次のことが実装できるとよいと思います。

• その子孫ページ(例: /page1/page2・/page1/page3/page4)は新規作成画面の時点で、デフォルトで/page1の制限を引き継ぐよう設定されているようにする(手動で変更可能) (対応済み)
• /page1 の編集画面などで、子孫ページ全てを同じ表示権限にするオプション(チェックボックスなど)を追加する

この「子孫の閲覧権限を一括変更する手段」はWindows・Linuxのファイルマネージャや、chmodコマンドの-Rオプションなどで実績があります。しかし、さらなる厳しい(または別の)アクセス制限のある子孫ページがあった時の挙動をどうするかという問題があります。解決策は次の2つです。

• まるまる上書きする (ファイルマネージャやchmodはこちらの方法)
• 何らかの方法でマージする

あるパスが自分の子孫かどうかは ${自パス}/ と前方一致するかどうかで確認できます。あとの問題は下手すると全ページ探索する羽目になることです。

[hakumizuki]

GROWI version 5 以降では、ユーザーグループに親子関係を持たせるという仕様変更に伴い、ページの親子関係とユーザーグループの親子関係が同期する仕様になりました。これにより、グループ管理されているページの子孫ページは、その大元となるページのグループより強い権限しかつけられないようになりました。

図で解説したもの：https://www.figma.com/file/6ujuY8PHtTcQKgp7C25QLa/UserGroup-V5?node-id=0%3A1