Server-tools: [RFC]関数用の新しいapi.groupsデコレータ

これは良い考えだと思います。隠すこと（ボタンを隠す）によるセキュリティは機能しません。

問題はこれをどこに置くかです。 api.foreach実装を含むOCA Pythonモジュールを作成しましたが、 OCAフロントに導入する動きはあまりあり

それでも、OCAAPIライブラリを用意するのは良い考えだと思います。 @lasleyは、OCAインスタンスタスク（「プロジェクトの作成」）に配置されたメソッドに従ってリポジトリを作成し、PRを作成するだけで

この機能について、：+ 1：を追加しますが、デコレータadd_groupsなどは使用しません。 これは継承で処理する必要があります。上書きされたメソッドのデコレータに新しいグループを追加すると、そのグループがリストに追加されます。 グループの削除については、コアのような他の手法を使用する必要があります（たとえば、元のメソッドを呼び出すグループの少ない別のメソッド）。

こんにちは ！ ご回答有難うございます。 OCAAPIライブラリLGTM。 いい案 ！

ただし、デコレータadd_groupsなどは使用しません

そうです、それは確かに単純化される可能性があります。

グループの削除については、コアのような他の手法を使用する必要があります（たとえば、元のメソッドを呼び出すグループの少ない別のメソッド）。

すべてのニーズに対応できるかどうかはわかりませんが、新しいリポジトリに対する特定のPRで説明します。

@lasleyは、OCAインスタンスタスク（「プロジェクトの作成」）に配置されたメソッドに従ってリポジトリを作成し、PRを作成するだけで

@lasley 、レポが作成されたらpingしてください

それでも、OCAAPIライブラリを用意するのは良い考えだと思います。 @lasleyは、OCAインスタンスタスク（「プロジェクトの作成」）に配置されたメソッドに従ってリポジトリを作成し、PRを作成するだけで

良い点-当時、私にはこれを行う権限がありませんでした。 ただし、OCAインスタンスではこのプロセスが見つかりません。もう少し掘り下げて、新しいリポジトリで報告します。

うーん、そうですね、リポジトリ作成のプロセスが見つからないので、先に進んでリポジトリを作成しましたが、権限がないようです。 @pedrobaeza PRを送信できるように、空白のOCA / python-ocaリポジトリを作成して

👍これを行うデコレータがあることに対して。 同じことを行い、server-toolsの新しいツールモジュールからインポートできる@privilegedデコレータを作成するというアイデアがありました。

しかし、デコレータをpipライブラリの一部にすることも同様です。 @ api.groupsという名前だけが気になります。 これはodooapi pythonモジュールからのものではないので、混乱することはありませんか？

こんにちは@ NL66278 、

名前空間については、名前が@ api.groupsではなく@ oca.groupsになるため、衝突は発生しないと思います。 （または同様のもの）

@legalsylvain私は最初の使用例に反応していました。 @oca.groupsがあれば素晴らしいでしょう。

@legalsylvainそれは良い考えです！

すべてのocaパッケージで使用できる名前空間パッケージとして「oca」を保持したいと思います。 この新しいパッケージに「oca-decorator」という名前を付けることができます。 このパッケージは「oca.decorator」（またはoca.xyz）を提供します

from oca.decorator import groups

    @groups(..)
    def function_name():

groups Iは、例えば、より明示的な名前を好むallowed_groups 。

lmi

@lasleyこれは、新しいリポジトリ/ PSCのプロセスが指定されているタスクです： https ：//odoo-community.org/web#id = 264＆view_type = form＆model = project.task＆action = 468＆active_id = 2

ペドロありがとう！ どういうわけか、ProjectからRepoまですべて検索しましたが、「PSC」を含めるとは思いませんでした。 ダープ！

ただし、OCAGitHubにはまだいくつかの追加の権限が必要です-新しいボタンはありません：

私があなたの役割を変更したので、もう一度やり直してください。

@ lasley @ pedroなぜpython-oca ？ この名前は無意味です。 Pythonパッケージにどのように名前を付ける予定ですか？

@ lmignon-私は提案を求めました、そしてこれは最高のものでした。 Pythonパッケージも同様の名前です。

あなたは何を考えていますか？ ぜひ聞きたいです。

@lasley私の主な関心事は、モノリティックPythonパッケージの作成を回避することです。 主な目標が新しい特殊なデコレータを提供することである場合は、oca-decoratorを使用しないでください。 名前は、パッケージでカバーされている機能範囲または必要なものによって異なります。 少なくとも名前は意味のあるものでなければなりません。 IMO'python-oca 'が広すぎます。

私はoca-decoratorが得意ですが、モジュールを少し異なる方法で構造化する必要があります。その場合、デコレータを名前空間のトップレベルにする必要があります。 元々そのようにしていたことは確かですが、LasLabs / python-oca＃1でoca.helpersに戻しました。

とにかく、その変更を行うのは簡単です。コードのコンテキストで説明する方がよいと思います。 私がリポジトリを作成したのを見て、PRを送信し、あなたの提案を含めます-その後、このハイジャックされたPRの代わりにコンテキストで議論することができます。

@lasley oca名前空間は空のままにする必要があります。 そうしないと、同じ名前空間で他のpythonパッケージを作成できなくなります。

了解しました。基本的には、 helpersパッケージの名前をdecorators 、それをPython用のスキーマと呼びますか？ 抽象例oca-package-sub == oca.package.sub

うん：にやにや笑い：それはアイデアです。

ひどいocapiが取られます：smile_cat：

https://github.com/OCA/oca-decorators/pull/1送信

このコードの構造について質問があります。 （多分私の質問は無関係です、ごめんなさい）

基本的に、このコードを書くには2つの方法があります。

A）従来のodooモジュール（既存または新規のリポジトリ内）を介して。 だから、それを使うには、いくつか書く必要があります

from odoo.addons.my_oca_lib_in_module import my_decorator

B）Pythonライブラリ経由。

皆さんは解決策「B」について話しているようですが、もちろん、それはよりクリーンな解決策です。
しかし一方で、そのような技術は、新しいoca-pythonlibに依存するモジュールを使用する技術的なスキルを持たない一部のユーザーをブロックするのではないかと心配しています。 UIを介して、またはodoo.shを介して（そして明日はOCAアプリストアで）モジュールをインストールしている人の例だと思います。 すべてのホスティングシステムでカスタムpythonlibを簡単にインストールできるかどうかはわかりません。
一部のユーザーがインストールできない追加のライブラリに依存しているため、一部のユーザーがOCAモジュールをインストールする可能性がない場合は残念です。

当面、OCAには他に1つの例しかありません。 openupgradelib。 コードは最初はOpenUpgradeプロジェクトにあり、外部のpython-libに移動されました。 アップグレードは技術的なことなので、私にとってはopenupgradelibのブロックポイントではありません。

どう思いますか ？

Odoo.shがpipの依存関係を処理する方法を知っていますか？

IMOこれは、マニフェストのexternal_depenciesキーを修正するためのものです。これを使用するモジュールはたくさんあります。 この新しいライブラリを使用するモジュールは、たとえば、 barcodes_generator_abstract必要とするbarcode barcodes_generator_abstractと何ら変わりはないと思います。

Odoo.sh（またはフランス人の場合はOdoo.hs）が次のRunbotであることは言うまでもありません。 賭けた。

😆ええ、私の賭けがどこにあるか知って

それを使用するモジュールがたくさんあります（@lasleyによる）

確かに、しかしそれはかなり異なります。 もちろん、バーコード生成を処理するシステムが必要な場合は、バーコードライブラリをインストールする必要があります。 アスタリスクなども同様です。
しかし、これは非常に限られており、世界中の一部のユーザーは、インストールできないか、その方法がわからないため、そのようなモジュールをインストールしていない可能性があります。 しかし、代替手段はありません。 バーコード生成を使用するには、バーコードライブラリが必要です。

ここでは違います。 OCAコードソース分析を更新しました。 今日、4182のモジュールがあります。 （2つのマイルストーンに存在するモジュールは2回カウントされます）。 一方、その4182モジュールすべてで、Pythonの依存関係は274個しかありません。 したがって、OCAモジュールの94％は外部のPythonライブラリに依存しておらず、非常に簡単にインストールできます。 詳細：

明日、便利なデコレータを備えた優れた追加のoca python lib（セキュリティの問題を修正しようとするこのスレッドで説明しようとしているものなど）がある場合、ほとんどのOCAモジュールはこのlibに段階的に依存します。

OCAの目的は、OCAメンバーの活動を促進することです。 したがって、そのような決定（インストールするライブラリを作成する）が人々がOCAモジュールを使用する可能性を減らしているのであれば、当面はこの方向に進むべきではないと思います。 最初に、古典的なモジュールを使用して、小さなoca-decoratorリポジトリを作成でき

openupgradeコードは、openupgradeリポジトリに何年も存在し、最近@StefanRijnhartによって外部ライブラリに設定されました。 この変更は大したことではなかったと思います。

（*）：ホスティングと展開のシステムはここ数年で大きく変化しました。 （bzrによるコードの取得、githubによるコードの取得、ビルドアウトテクノロジーの使用、最近ではpypiのデプロイ）

@ OCA / boardがその点についてどう考えているのか聞きたいです。 それは技術的な決定であるだけでなく、戦略的な決定でもあります

https://github.com/OCA/oca-decoratorsが利用可能になったので、このRFCはそこに移動できます。

@ legalsylvain-ライブラリとして作成する前に、最初にapi.foreachモジュールを送信しました。 このPRを見ると、なぜこの戦略を放棄したのかがわかります。

60〜70文字のインポートパスを考慮し始めると、APIの使用はほぼ不可能になり、各インポートの周りにtry / exceptを配置する必要があります。 これにより、モジュールの採用は基本的にゼロになります。インポートはレコードループよりも困難です。

興味深いことに、try / exception戦略はデコレータで惨めに失敗しますが、それはまったく別のトピックです。 繰り返しになりますが、Odooがexternal_dependenciesキーを修正してくれることを願っています。

@ dreispt-この既存のディスカッションを別のリポジトリに移動する良い方法はありますか？ ここには、流動的に持ち越されるかどうかわからない点がたくさんあります。

60〜70文字のインポートパスを考慮し始めると、APIの使用はほぼ不可能になり、各インポートの周りに試行/例外を設定する必要があります。

そのソリューションでの必要性を除いて、try /が何であるかを理解していません。

oca @ foreachデコレータを使用するには、oca_apiライブラリまたはモジュールで定義します。 ：

Libソリューションの影響
デプロイ：

• pipインストールまたはビルドアウト経由。 Saasの制限。

マニフェストファイル：

'external_dependencies': {'python': ['oca_api']}

Pythonファイル：

from oca_api import oca

モジュールソリューションの影響
デプロイ：

• ピップインストールまたはダウンロードして、UIまたはビルドアウトを介してインストールするか、アドオンファイルにモジュールを追加します。 Saasの制限はありません。

マニフェストファイル：

'depends': ['oca_api'],

Pythonファイル：

from odoo.addons.oca_api import oca

それとも私は何かを逃しましたか？ はいの場合は訂正してください。

敬具。

そのソリューションでの必要性を除いて、try /が何であるかを理解していません。

try / exceptionは、コアOdoo以外のものをインポートするときに実行する必要があるため、代わりに次の例になります。

try:
    from oca_api import oca
except ImportError:...

try:
    from odoo.addons.oca_api import oca
except ImportError:...

しかし、ええ、あなたのモジュールの命名に関しては、それは私のものほど悪くはありません。

これの多くは、モジュールがDBにインストールされておらず、ほとんどのモジュールのように環境にカプセル化されていないという事実に関係していると思います。 これは、モジュールが明示的にインストールされていない環境に機能を提供していることを意味し、問題（セキュリティまたはその他）と見なされる可能性があります。

@lmignonは、 https： //github.com/OCA/webhook/pull/3#issuecomment-336935193で上記と同様の議論を公開しました。 これらは並行した会話だと思います。基本的に、このような機能セットを提供する方法に沸騰しています。

私は個人的に@lmignonがここにあると感じており、これをlibとして提供する必要があります。 IIRCのアドバイスが、 foreachデコレータをモジュールから移動した主な理由でもありました。

こんにちは@lasley。

どうもありがとう！ モジュールに依存関係を作成することで、モジュールが存在すると想定するのに十分だと思いましたが、すべてのOCAコードをrgrepして、あなたが話していることのサンプルをたくさん見ました。 （report_xls、およびコネクタ用にたくさんあります）。

モジュールが原因で、セキュリティの問題を理解するスキルがありません。 私の場合、モジュールがインストールされていない場合、oca_apiのモジュールのコードを呼び出すべきではありません。 しかし、多分私は間違っています。

よろしく。

モジュールに依存関係を作ることで、モジュールが存在すると想定するのに十分だと思いました。

詳細については、 https：//github.com/odoo/odoo/pull/14850をご覧ください。

私の場合、モジュールがインストールされていない場合、oca_apiのモジュールのコードを呼び出すべきではありません。

そこに問題があります。 これは当てはまりません-Odooはaddonsパス内のすべてのモジュールをメモリにインポートします。 このため、依存関係が実際にインストールされているかどうかに関係なく、モジュールへのインポートはどのモジュールでも成功します。

これはOdooの中核であり、現実的には回避策はありません。 これが、OdooSAと同じように顧客を共同ホストしない理由でもあります。 彼らがOdoo.shでこれを解決できたかどうか知りたいのですが、SaaSで時限爆弾を手にしているのではないかと思います。

このすべての説明に感謝します。 odoo / odoo＃14850が受け入れられないのは残念です。
外部ライブラリに依存して多くのOCAモジュールを作成すると、これらのモジュールの使用が確実に制限されると思います。 しかし、まあ、モジュールは確かに解決策ではないようです。
よろしく、あなたの洞察力に感謝します。

この問題を閉じます。 （https://github.com/OCA/oca-decorators/issues/7に移動）
よろしくお願いいたします。