4

ワークフローの状態に基づいて、オブジェクトに異なる権限を設定する必要があります。たとえば、「マネージャーグループ」はstate =draftの場合にのみオブジェクトを編集できますが、「スーパーマネージャーグループ」はstate=validatedの場合にもオブジェクトを編集できます。

を使用することは不可能のようで、を使用ir.model.accessして実行できるかどうかを評価していir.ruleます。そうではないようです...

これを取得する方法はありofficialますか、それともこの機能を実装する必要がありますか(ir.model.access機械に条件を追加することによって)。

4

4 に答える 4

5

ir.model.accessこのパーミッション モデルは、CRUD 操作に対する単純な Unix パーミッションのように機能するように設計されており、モデルごとおよびグループごとに静的に定義されるため、デフォルトではこれは不可能です。

ir.ruleフィールド値に基づく動的なレコードごとのアクセス制御を実装するため、を使用してこのようなものを実装できる場合があります。write操作とフィールドにunlink基づいてのみ一連のルールを定義するstateことで、一部のグループが特定の状態のレコードを変更するのを防ぐことができます。常に真のルールの手法を使用する[(1,'=',1)]と、「スーパーアクセス」グループを持つユーザーに対して非グローバル ルールを緩和できます。この回答も参照してください。
ただし、このオプションには重要な注意事項があります。

  • これらのルールを に適用しないように注意してくださいread。レコードが完全に消えてしまい、通常はプロセスに大混乱をもたらすためです。
  • ルールが有効な場合、インターフェイスは読み取り専用にはなりません。フィールドとボタンを読み取り専用にしたい場合はattrs、ユーザーのグループに応じた方法でこれを指定する方法を見つける必要があります。このランチパッドの質問も参照してください。
  • UI の [保存] ボタンは無効になりません
  • 制限の場合の標準エラー報告ir.ruleはあまり明確ではないため、ユーザーを混乱させることは間違いありません (注: 7.0 で改善されています)。

ご覧のとおりir.rule、この目的でフィルターを使用することは完全な解決策には程遠いため、まず上記の問題に対する適切な解決策を見つける必要があります。

最終的には、ORM プリミティブ API メソッドfields_view_get(ユーザー グループに基づいてフィールドを動的に読み取り専用にするため) と CRUD メソッド (実際にオペレーション)

于 2012-06-12T10:32:43.153 に答える
1

Web クライアントをハッキングする代わりに別の方法があります。同じ Object に対して常に 2 つのビューを持つことができます。

  1. マネージャーグループ向け。

  2. スーパー マネージャー グループの場合。

マネージャー グループでは、attrs = {'readonly': [('state', '!=', 'draft')]} を使用できます。

または必要に応じて任意の条件。

スーパーマネージャーグループでも同じように、フィールドに彼の条件を入れることができます。

于 2012-06-12T12:36:58.647 に答える
0

同様の要件がありました...私の要件は、ユーザーがグループ「販売ユーザー」に属する場合、それ以外の場合はグループ「販売マネージャー」で編集可能な場合、sale.orderでcharフィールド(「test_123」など)を読み取り専用にすることでした。つまり、販売注文がドラフト状態の場合は誰でも編集できますが、販売注文が確認された場合、このフィールド「test_123」は「販売管理者」に対してのみ編集可能です。

私がしたことは、ユーザーがグループ「販売マネージャー」に属し、状態が「ドラフト」でない場合にTrueを返す機能フィールド(is_group_manager)を追加したことです。attrs="{'readonly':[('is_group_manager','=',0)]}" 次に、xmlビューで、たとえば属性を含むフィールド「test_123」を追加しました

<field name="is_group_manager" invisible="1"/>
<field name="test_123" attrs="{'readonly':[('is_group_manager','=',0)]}"/>

これは、openerp v6.0 でのみ機能します。多分これはあなたに役立つでしょう。:)

于 2012-06-24T04:14:37.703 に答える
0

私はこの機能を実稼働環境で動作させ、レコード ルールのみを使用しています。プロジェクト課題では、「基本ユーザー」は課題を作成およびキャンセルできますが、それらを開いたり閉じたりすることはできません。@odony が言及した GUI の制限にもかかわらず、完全に機能します。

使用される記録規則は次のとおりです: ここに画像の説明を入力:

注意が必要な特別なケースがあります: 読み取り/書き込み状態から読み取り専用状態への変更:

アクションのメソッドで、状態が他のwrite操作の後に変更された場合、ユーザーは状態を変更できます。ただし、状態の更新後に何らかのwrite操作があった場合、ユーザーは状態を変更できなくなります。

私の例では、課題を開くためのプロジェクト課題メソッドはcase_open()です。最初に状態を変更し、次にオープン日、ユーザー、メッセージ履歴の設定などの追加の変更を行います。このため、基本ユーザーは問題を開くことができません。そうできるようにしたい場合は、他のすべての操作が完了したcase_open()後に State を変更するようにオーバーライドする必要があります。write

于 2012-06-22T08:34:53.560 に答える