次のシナリオがあります。
問題は、ViewsBulkOperationsがノードのアクセス許可を尊重することです。編集者にはその許可が与えられていないため、編集者はノードを削除できません。VBOでそのアクションを実行しているときに、エディターが（sudoのような）より高い役割のユーザーになる方法はありますか？あるいは、このアクションのノードアクセスを無視するようにVBOに指示する方法はありますか？
これが主流の要件であると確信していますが、解決策を見つけることができないようです。
プログラミングを伴わないソリューションが優先されます。
単純ですが、それほどクリーンではない方法は、すでに行ったルートですが、それを支援するための追加の小さなモジュールがあります。
my_module_can_delete($user)に返す関数があります。 TRUEFALSEhook_form_alter()node_editフォームのボタンを変更および削除するための 実装my_module_can_delete($user)hook_form_alter()/ node /％nid / deleteで呼び出される確認フォームを変更し、そこにメッセージを追加してユーザーに通知するように実装しますmy_module_can_delete($user)。このフォームを無効にすると、ユーザーはこのフォームを通過できなくなるため、これで十分です。FORM-APIがそれを処理します。ただし、他の削除モジュールをキャッチするために、より堅牢にすることができます。
hook_nodeapi()、$op == 'delete'削除アクションをキャッチして停止します（を呼び出すdrupal_goto()か、呼び出しdrupal_access_denied()てユーザーエラーを強制します。リファラーが上記のdelete-confirm-formの場合にのみ、delete-actionsをキャッチします。または、より安全に、VBOアクションをホワイトリストに登録します。他のすべてのリファラーではfalseを返します。リファラーは、に渡された$nodeを読み取ることで見つけることができますhook_nodeapi()。A、私見、はるかにクリーンですが、おそらくより集中的な代替手段は、すべての削除アクションでバッチ/アクションが呼び出されることを確認することです。
モジュールでは、すべてのVBO構成を回避し、すべての追加削除アクションをそこから除外することで、これを行うことができます。hook_nodeapi()次に、そこからすべてのクリーニングアクションを実装して呼び出すモジュールを作成します。そうすれば、任意のノードのすべての削除アクションで削除アクションが確実に呼び出されるようになります。明らかに、いくつかの条件をhook_nodeapi（）に追加して、特定の場合（ノードタイプ、ユーザーロール、権限など）でのみモジュールを呼び出すことができます。
ええと、特定の極端な状況を除いて、実際には、編集者の役割のユーザーに削除させたくない設定があるように思われます。これが私の提案です：
1）フラグモジュールをインストールします。編集者の役割の担当者のみが割り当てることができる「削除予定」フラグを作成します。
2）まだ調べていませんが、「削除予定」フラグが割り当てられている場合にノードを非公開にするルールまたはトリガー/アクションの組み合わせがあると確信しています。これにより、ノードがカジュアルビューから削除されます。 。
3）次に、cron実行アクティビティ（トリガー/アクションまたはルール）を設定して、「削除予定」フラグが設定されているノードを削除するか、より高い権限を持つ別のユーザーがときどき入ってフラグ付きアイテムを削除します。
このように、実際には権限システムをバイパスしていませんが、それでもサイトから物事が削除されています。
「actions_permissions」モジュールに気付くまでしばらくの間、これに巻き込まれました。これを有効にすると、[権限]ページで、役割ごとに特定のアクションへのアクセスを提供できます。
私には優れたコーディングなしのソリューションがなく、このソリューションを「素晴らしい」と呼ぶかどうかはわかりませんが、1つの方法は、ノード編集から削除ボタンを削除するform_alterフックを使用して単純なモジュールを実装することです。それらが構築されるときにフォーム。
一般に、ロールにはノードを削除する権限があるかどうかのどちらかであるように思われます。このようにモンキーすることは、あなたが望むほど堅牢ではなくなります。