redmine.tokyo » Unofficial Redmine Cooking

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

添付ファイルの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で条件を指定します。

奈良 裕記様

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

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

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

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

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

同じロールで利用者によっては裏で直リンクでのアクセスまたは
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を含むかで判断するとは思いますが。

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

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

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

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

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

パスのパターン:/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>

ありがとうございます。

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

roles[0].id

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

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

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

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

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

ですが、良く試してみたら、role⁰が必ずしも、一番若い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: 翻訳者
roles⁰: 4

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

ここでの目的は、「同じロールで利用者によっては画面項目の表示内容を制限する」ということだと思うので、
１．権限内容は同じ権限内容のロールを複数用意して（例：管理者１、管理者２、管理者３）
２．各ユーザーにいずれか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("非対象ユーザ");
  }
})

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

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

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

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 |

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

例：管理者、開発者共通、開発者１、開発者２、開発者３

管理者：USER1
開発者共通：USER2, USER3, USER4
開発者１：USER2
開発者２：USER3
開発者３：USER4

＊View Customize Pluginで画面項目の表示制御する権限は、開発者１、開発者２、開発者３とする。

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

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

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

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