Project

General

Profile

Actions

QA #264

open

チケット画面の編集・削除・ウォッチなどのリンクを非表示としたい

Added by G Naoki over 5 years ago. Updated about 1 year ago.

Status:
新規
Priority:
通常
Assignee:
-
Category:
UI
Target version:
-
Start date:
12/14/2016
Due date:
% Done:

0%

Estimated time:

Description

■現象/要望

Redmineの運用上権限は与えておくが、編集・削除・ウォッチなどのリンクを非表示としたい場合がある。
特定のロールの場合のみ制御する方法はありますでしょうか?

■解決策

管理操作用のIDを作成する事が現実的と思われる。

誤操作予防の点では、下記順で制限強化することが考えられる。
1と4の間に、2か3を追加することになるが、3に相当するアカウントを準備しておく。

1.操作可能(画面直接)
2.操作可能(画面直接-ユーザ確認操作有)
3.操作可能(通常操作画面不可だが、裏画面/REST等で操作可能-操作依頼不要)
4.利用者操作不可、管理者/権限者に作業依頼
5.操作不可(admin含)

特定のロールの場合のみ、編集・削除・ウォッチなどのリンクを表示する。(viewcustomize利用)

複数Roleが割り当てられている場合には動作調整必要
https://redmine.tokyo/issues/264#note-7

■対応状況

未解決

■補足

 Redmineのロールによる項目非表示設定.xlsx
 システム管理者権限の有無では以下のような記載を行うことで制御可能ですが、
 管理者・報告者などのロール単位での制御としたいです。
  <% if User.current.admin? >・・・< end %>



Files

Actions #1

Updated by 奈良 裕記 over 5 years ago

目的確認ですが、
変更権限は残しておくが、誤操作回避のためにボタンを表示したくないということですか?

添付ファイルのadminの場合の例で、途中までは確認されていますので、
下記ソースなどから検索して追っていくと近いかもしれません。
こういうときはソースgrepで追っ掛けです。

このような個別対応が求められる場合があるのは理解します。(自分も。。orz)
具体的なサンプル蓄積が必要。。。

---------------------------
app/models/issue.rb

user_tracker_permission?(user,permission)

---------------------------
app/models/role.rb

has_permission?(perm)

---------------------------
lib/redmine.rb のmap.permission
requireで条件を指定します。

Actions #2

Updated by 奈良 裕記 over 5 years ago

  • Description updated (diff)
Actions #3

Updated by G Naoki over 5 years ago

奈良 裕記様

ご連絡いただき、ありがとうございます。はい、目的は奈良様のご認識どおりです。
同じロールで利用者によっては裏で直リンクでのアクセスまたは
RestAPIで編集したいケースなどの個別対応があるためです。

※事前にこちらのRedmineのバージョンをお伝えできておりませんでした。
 Redmineのバージョンは3.1系です。(Ver3.1.2)
対象のバージョンでは以下のモジュールの記載がないようですね。。

 ---------------------------
 app/models/issue.rb
 
 user_tracker_permission?(user,permission)
 ---------------------------

新規に「ロールの確認」版のソースカスタマイズが必要でしょうか??
自身はソースコードを最近見るようになったので、
あまりソースの理解ができておらず的外れな質問となっているかと思いますが、
ログインユーザが対象チケット表示時に、チケットのプロジェクトに対して、
どのようなロールが割り当てられているか取り出し、
比較するような方法はありますでしょうか?
※用途は違うかと思いますが例えば以下のような感じです。
if User.current.builtin_role=="特定のロール等々"

どうぞよろしくお願いいたします。

Actions #4

Updated by 奈良 裕記 over 5 years ago

同じロールで利用者によっては裏で直リンクでのアクセスまたは
RestAPIで編集したいケースなどの個別対応があるためです。

そこまで使いこなした上の要件だったんですね。
編集用の別ユーザとしてREST使用という方法も考えられそうです。


3.1と3.3の差異点に引っ掛かりましたか。。
3.3のTracker role-based permissionにより再設計された部分です。

Adds permission to edit and delete issues by role/tracker (#285).
http://www.redmine.org/projects/redmine/repository/revisions/15466/diff/trunk/app/models/issue.rb

Tracker role-based permissioning
http://www.redmine.org/issues/285

部分的に3.1に取り込むのは、関連変更内容を眺めると心配です。
3.3へのアップデート含め検討された方が良いかもしれません。
http://www.redmine.org/projects/redmine/repository/changes/branches/3.3-stable/app/models/issue.rb


※用途は違うかと思いますが例えば以下のような感じです。
if User.current.builtin_role=="特定のロール等々"

気持ち判りますが、回答持ち合わせていません。orz
Roleを含むかで判断するとは思いますが。

Actions #5

Updated by 奈良 裕記 over 2 years ago

  • Description updated (diff)
Actions #6

Updated by Kawai takashi over 2 years ago

ログインユーザが対象チケット表示時に、チケットのプロジェクトに対して、どのようなロールが割り当てられているか取り出し、比較するような方法 ===>

View Customize Pluginで取得できると思いますが、これを使用できませんか。

パスのパターン:/issues
挿入位置:全ページのヘッダ
種別:JavaScript

$(function(){
  var role = ViewCustomize.context.project.roles[0].name;
  console.log(role); 
  if (role == "管理者"){
    alert(role + "です");
  }
})

Actions #7

Updated by Kawai takashi over 2 years ago

特定のロールの場合のみ、編集・削除・ウォッチなどのリンクを表示する。

パスのパターン:/issues/[0-9]+
挿入位置:全ページのヘッダ
種別:HTML

<style>
a.icon-edit, a.icon-del, a.icon-fav-off {
  display:none;
}
</style>

<script>
$(function(){
  var role = ViewCustomize.context.project.roles[0].name;
  //console.log(role); 
  if (role == "管理者"){
    $("a.icon-edit, a.icon-del, a.icon-fav-off").show();
  }
})
</script>
Actions #8

Updated by 奈良 裕記 over 2 years ago

ありがとうございます。

CSSでデフォルト非表示、Role指定で表示なら、当初希望通りになりそうですね、
ただ、roles0.nameだと、PJ内で複数Roleが割り当てられていた時に引っ掛かりませんか?

Actions #9

Updated by Kawai takashi over 2 years ago

roles[0].id

にしたら解決できますかね?ですが、同じ権限名称は登録できないようになっているようですので、名称のほうを使っても重複はしないです。

PJ内で複数Roleが割り当てられていた時 ===> そのユーザーがプロジェクト内で、複数の権限を割り当てられている場合ということですか?
この場合は、最高の権限を取得しているようです。何にしても、希望通りの動作にするためには、「管理者」「準管理者」のような権限を作成して、切り分けることが必要ですね。

Actions #10

Updated by 奈良 裕記 over 2 years ago

PJ内で複数Roleが割り当てられていた時
===> そのユーザーがプロジェクト内で、複数の権限を割り当てられている場合ということですか?

そのケースを想定しています。
ユーザIDにより、割り当てられたRoleが異なれば、
roles[0]に割り当てられるRoleが異なり、人によって動作差異が発生するかと。

Actions #11

Updated by Kawai takashi over 2 years ago

この例だと、role0だとkanagawaさんとy503unavailableさんの権限は「開発者」として取得されますね。
ですので、希望のようなことをしたければ、開発者・savequery・role1の権限をredmineの設定上は同じにしておき、view customize pluginで画面上のボタン表示・非表示によって、できることを変えるということになると思います。
kanagawaさんの最高権限をsavequery、y503unavailableさんの最高権限をrole1に設定する。

実際にはrole0, role1....などすべて取得はできますが、「ある権限を含む」という条件にするとうまく制御できないので、やはり与えられている最高権限で判断するようにするしかないと思います。

Actions #12

Updated by 奈良 裕記 over 2 years ago

  • Description updated (diff)

Roleは複数機能の権限(直接の大小関係無)の割り当てなので、最高権限という用語は違和感あるのですが。。
どこかですれ違っている気がします。

Actions #13

Updated by Kawai takashi over 2 years ago

そうですね、運用方法はそれぞれ異なると思うので、一概には言えないですね。この件は、単にプラグインでroleが取得できるので、希望の動作にするのに利用できるのではないかということを提案してみただけで、実際には運用方法に合わせて熟慮する必要があると思います。各ユーザにどのような権限を与えて運用するかという詳細な情報がないと、具体的にはどのようなscriptにすれば良いかは判断できないですね。

私の運用だと、権限の高いロール(ロールと権限の設定で一番多く権限にチェックが入っているロール)から順に若いidを割り振っています。上位のロールには、下位で与えられている権限全てを含むように設定しています。ですので、そのユーザーの「最高権限(この呼び名違和感があるということで、すいません)」をrole0で取得して、画面項目の表示・非表示に利用できると思いました。

ですが、良く試してみたら、role0が必ずしも、一番若いidを取得するわけではないようです。

$(function(){
  var roles = ViewCustomize.context.project.roles;
  for (i in roles) {
    role = roles[i];
    roleid = role.id + ': ' + role.name;
    console.log(roleid);
  }
})

$(function(){
  var roleid = ViewCustomize.context.project.roles[0].id;
  console.log('roles[0]: ' + roleid);
})

このようにしたところ、結果は以下のようになりました。
4: 開発者
3: 管理者
5: 報告者
6: 翻訳者
roles0: 4

また、奈良さんのような運用(ロールには上下関係はなく、役割として割り振る)では、確かにroles0を取得して判断するような方法は使えないですね。そのユーザーに付与されているロール全てを取得して、「ある権限を含む」場合の処理としなければならないようですね。この場合は、「CSSでデフォルト非表示、Role指定で表示」ではなく、「初期表示はすべて表示、Role条件指定で非表示にする」で実現できないでしょうか。

ここでの目的は、「同じロールで利用者によっては画面項目の表示内容を制限する」ということだと思うので、
1.権限内容は同じ権限内容のロールを複数用意して(例:管理者1、管理者2、管理者3)
2.各ユーザーにいずれか1つのロールを割り振る(複数与えてはいけない: 複数与えても処理としては通りますが、運用的に良くないと思います。)
という設定にすれば実現できるのではないかと。

var roleidarray = [];
var role1 = 3;
var role2 = 4; 

$(function(){
  var roles = ViewCustomize.context.project.roles;
  for (i in roles) {
    role = roles[i];
    roleid = role.id;
    roleidarray.push(roleid);
  }
  if (roleidarray.indexOf(role1) >= 0){
    console.log("対象ユーザ1");
    $("a.icon-fav-off").css("display", "none"); 
  }else if (roleidarray.indexOf(role2) >= 0){
    console.log("対象ユーザ2");
    $("a.icon-edit, a.icon-del, a.icon-fav-off").css("display", "none");   
  }else{  
    console.log("非対象ユーザ");
  }
})
Actions #14

Updated by 奈良 裕記 over 2 years ago

Redmine標準のロール(管理者/開発者/報告者)は、実質的に権限の上位関係で設定されていますが、
それだけでは運用上無理があるというのが自分の認識です。
この辺は、実際の各組織内人員構造に依存しますね。

手元の環境では、基本的な業務権限を上位関係をベースとしたロールに設定し、特定業務の管理権限等を個別のロールとして追加しています。(例:テンプレートの編集)
前者を個々の権限単位でロール設定すれば運用が標準化できませんし、後者は実際の担当者が直接作業可能にする必要がありますから。

この辺、下記資料の、「4.2.1 ロール設定の OR ルール」が参考になります。
CODA: JSS2の運用・ユーザ支援を支えるチケット管理システム –Redmineの事例と利用のヒント–
https://repository.exst.jaxa.jp/dspace/handle/a-is/557146?locale=ja

Actions #15

Updated by 奈良 裕記 over 2 years ago

note-13 で提示頂いた様に、role割当内容を一旦全部確認する処理が必要そうですね。
「初期表示はすべて表示、Role条件指定で非表示にする」対応で賛成です。
(すみません。まだ動作確認できていませんが。)

あと、 projects.rolesは、rolesテーブルの内容が反映されているものと思います。

[redmine]> select id,name from roles;
+----+-------------------+
| id | name              |
+----+-------------------+
|  1 | Non member        |
|  2 | Anonymous         |
|  3 | 管理者            |
|  4 | 開発者            |
|  5 | 報告者            |
|  7 | readonly          |以降はユーザ追加分
|  8 | savequery         |
|  9 | managepublicquery |
Actions #16

Updated by Kawai takashi over 2 years ago

View Customize Pluginで制御する権限は、 ロール設定の OR ルールのほうで与えられた権限に対して行うようにしなければいけないですね(共通で持たせている権限のほうではなく)。

例:管理者、開発者共通、開発者1、開発者2、開発者3

管理者:USER1
開発者共通:USER2, USER3, USER4
開発者1:USER2
開発者2:USER3
開発者3:USER4

*View Customize Pluginで画面項目の表示制御する権限は、開発者1、開発者2、開発者3とする。

この理解で正しいですか?

Actions #17

Updated by 奈良 裕記 over 2 years ago

確かに機能単位のロールで利用する場合が多いと思います。

ただ、特定のPJの開発者共通ロールに対して、
本来権限のある編集操作のボタンを非表示にするような利用法も考えられますね。

Redmineのロールによる操作権限の割当は、通常権限追加方向になりますが、
この機能を使えば特定条件で通常操作困難に出来る訳で、今までと別の設計が可能になります。

Actions #18

Updated by 奈良 裕記 about 1 year ago

  • Description updated (diff)
Actions

Also available in: Atom PDF