Server-tools: [RFC] مصمم api.groups الجديد للوظيفة

أعتقد أن هذه فكرة جيدة - الأمان من خلال التعتيم (إخفاء الأزرار) لا يعمل.

السؤال هو مكان وضع هذا. لقد صنعت وحدة OCA Python بها تطبيق api.foreach ، لكن لم يكن هناك

ما زلت أعتقد أنه من الجيد أن يكون لديك مكتبة OCA API. lasley ، ما عليك سوى إنشاء الريبو باتباع الطريقة

حول هذه الميزة: +1: لإضافتها ولكن ليس مع الزخرفة add_groups وهكذا. يجب التعامل مع هذا بالوراثة: إذا أضفت أي مجموعة جديدة في المصمم بطريقة الكتابة فوقها ، فستتم إضافة تلك المجموعة إلى القائمة. فيما يتعلق بإزالة المجموعات ، يجب عليك استخدام تقنيات أخرى كما هو الحال في اللب (على سبيل المثال ، طريقة أخرى مع مجموعات أقل تستدعي الطريقة الأصلية).

مرحبا ! شكرا لإجابتك. مكتبة OCA API LGTM. فكرة عظيمة !

ولكن ليس مع add_groups المصممون وما إلى ذلك

أنت على حق ، يمكن تبسيطه بالفعل.

فيما يتعلق بإزالة المجموعات ، يجب عليك استخدام تقنيات أخرى كما هو الحال في اللب (على سبيل المثال ، طريقة أخرى مع مجموعات أقل تستدعي الطريقة الأصلية).

لست متأكدًا من أنه سيغطي جميع الاحتياجات ، لكننا سنتحدث عنها في بيان عام محدد مقابل الريبو الجديد.

lasley ، ما عليك سوى إنشاء الريبو باتباع الطريقة

lasley ، يرجى الاتصال بي عند إنشاء الريبو ، سأبدأ بعد ذلك POC وأحاول إنهاء العمل في الأيام المفتوحة (/ المغلقة) التالية.

ما زلت أعتقد أنه من الجيد أن يكون لديك مكتبة OCA API. lasley ، ما عليك سوى إنشاء الريبو باتباع الطريقة

نقطة جيدة - في ذلك الوقت لم يكن لدي أذونات للقيام بذلك. لا أجد هذه العملية في مثيل OCA على الرغم من ذلك - سأحفر أكثر قليلاً وأعيد الإبلاغ باستخدام الريبو الجديد.

حسنًا ، حسنًا ، لذلك لا يمكنني العثور على عملية لإنشاء الريبو ، لذلك كنت سأستمر في إنشاء الريبو - لكن يبدو أنه ليس لدي أذونات. pedrobaeza هل تمانع في إنشاء علاقات عامة إليه؟

👍 لوجود مصمم يقوم بذلك. خطرت لي فكرة إنشاء مصمم ديكور @privileged يقوم بنفس الشيء ويمكن استيراده من وحدة أدوات جديدة في أدوات الخادم.

ولكن قد يكون وجود مصمم الديكور جزءًا من مكتبة Pip أيضًا. لا أتساءل إلا عن اسم @ api.groups. ألن يكون هذا محيرًا لأن هذا لا يأتي من وحدة odoo api python؟

مرحبًا @ NL66278 ،

حسنًا ، بخصوص مساحة الاسم ، أعتقد أن التصادم لن يكون ممكنًا ، لأن الاسم سيكون @ oca.groups وليس @ api.groups. (أو شيئا من هذا القبيل)

legalsylvain كنت @oca.groups أمرًا رائعًا.

legalsylvain إنها فكرة جيدة!

أفضل الاحتفاظ بـ "oca" كحزمة مساحة اسم متاحة لجميع حزم oca. يمكننا تسمية هذه الحزمة الجديدة "oca-decorator". ستوفر هذه الحزمة "oca.decorator" (أو oca.xyz)

from oca.decorator import groups

    @groups(..)
    def function_name():

حول groups أفضل اسمًا أكثر وضوحًا على سبيل المثال allowed_groups .

lmi

lasley هذه هي المهمة حيث يتم تحديد عملية المستودع الجديد / PSC: https://odoo-community.org/web#id = 264 & view_type = form & model = project.task & action = 468 & active_id = 2

OMG شكرا بيدرو! لسبب ما ، بحثت في كل شيء من Project إلى Repo ، لكنني لم أفكر في تضمين "PSC". ديرب!

ما زلت بحاجة إلى بعض الحقوق الإضافية في OCA GitHub رغم ذلك - ليس لدي الزر الجديد:

حاول مرة أخرى الآن بعد أن غيرت دورك.

@ Lasleypedro لماذا python-oca ؟ هذا الاسم لا معنى له. كيف تخطط لتسمية حزمة بايثون؟

lmignon - لقد طلبت اقتراحات وكان هذا هو الأفضل. تمت تسمية حزمة python بالمثل.

ما هي فكرتك؟ أنا كل آذان صاغية.

@ Lasley شاغلي الرئيسي هو تجنب إنشاء حزمة بيثون متجانسة. إذا كان الهدف الأساسي هو توفير ديكورات متخصصة جديدة ، فلماذا لا يكون ديكور أوكا. يجب أن يعتمد الاسم على النطاق الوظيفي الذي تغطيه الحزمة أو أي شيء تريده. يجب أن يكون الاسم على الأقل ذا معنى. IMO "python-oca" واسع جدًا.

أنا جيد مع oca-decorator ، على الرغم من أننا سنحتاج إلى هيكلة الوحدة بشكل مختلف قليلاً كما أعتقد بعد ذلك لجعل المصممين من المستوى الأعلى في مساحة الاسم. أنا متأكد من أنني حصلت عليها بهذه الطريقة في الأصل ، لكننا دفعناها مرة أخرى إلى oca.helpers في LasLabs / python-oca # 1

على أي حال ، من السهل إجراء هذا التغيير ، وأعتقد أنه سيكون من الأفضل مناقشته في سياق الكود. برؤيتي أثناء إجراء الريبو ، سأرسل العلاقات العامة وتتضمن اقتراحك - ثم يمكننا مناقشته في السياق بدلاً من العلاقات العامة المختطفة.

@ Lasley يجب أن تظل مساحة الاسم oca فارغة. وإلا فلن يكون من الممكن إنشاء حزم بيثون أخرى ضمن نفس مساحة الاسم.

حسنًا ، لذلك نرغب بشكل أساسي في إعادة تسمية حزمة helpers إلى decorators ، ثم نسمي ذلك مخططنا لأشياء Python؟ مجردة على سبيل المثال oca-package-sub == oca.package.sub

نعم: سميرك: هذه هي الفكرة.

سيء جدًا ocapi مأخوذ: smile_cat:

تم تقديم

لدي سؤال حول هيكل هذا الرمز. (ربما سؤالي غير ذي صلة ، آسف)

في الأساس ، أرى طريقتين لكتابة هذا الرمز.

أ) عبر وحدة odoo كلاسيكية (في مستودع حالي أو جديد). لذلك ، لاستخدامه ، علينا كتابة بعض

from odoo.addons.my_oca_lib_in_module import my_decorator

ب) عبر بيثون ليب.

يبدو أنكم جميعاً تتحدثون عن الحل "ب" ، وهو بالطبع الحل الأنظف.
لكن من ناحية أخرى ، أخشى أن تمنع هذه التكنولوجيا بعض المستخدمين الذين ليس لديهم مهارة فنية من استخدام الوحدات التي تعتمد على برنامج oca-python lib الجديد. أعتقد على سبيل المثال للأشخاص الذين يقومون بتثبيت الوحدة عبر واجهة المستخدم ، أو غير ذلك عبر odoo.sh (وغدًا مع متجر تطبيقات OCA ، ربما!). لست متأكدًا من أن جميع أنظمة الاستضافة ستسمح بتثبيت python lib المخصص بسهولة.
سيكون من المؤسف أن بعض المستخدمين لن تكون لديهم إمكانية تثبيت وحدات OCA ، لأن هناك اعتمادًا على lib إضافي غير قابل للتثبيت لبعض الأشخاص.

لا يوجد سوى مثال واحد آخر في OCA في الوقت الحالي. ال openupgradelib. كان الرمز في البداية في مشروع OpenUpgrade ، وتم نقله إلى python-lib خارجي. بالنسبة لي ، فهي ليست نقطة حجب لـ openupgradelib ، لأن إجراء الترقية هو أمر تقني.

ما رأيك ؟

هل نعرف كيف يتعامل Odoo.sh مع تبعيات النقطة؟

IMO هذا عليهم لإصلاح المفتاح external_depencies في البيان - لدينا الكثير من الوحدات التي تستخدمه. لا أعتقد أن الوحدات النمطية التي تستخدم هذه المكتبة الجديدة ستكون مختلفة ، على سبيل المثال ، barcodes_generator_abstract التي تتطلب barcode

كي لا نقول أن Odoo.sh (أو Odoo.hs للأشخاص الفرنسيين) هو Runbot التالي. تم أخذ الرهان.

😆 نعم نحن نعلم أين يكمن رهاني على ذلك

لدينا الكثير من الوحدات التي تستخدمها (بواسطة @ Lasley)

في الواقع ، لكن الأمر مختلف تمامًا. بالطبع ، إذا كنت تريد نظامًا يتعامل مع إنشاء الباركود ، فيجب عليك تثبيت lib الباركود. نفس الشيء بالنسبة لعلامة النجمة ، إلخ ...
لكن هذا محدود للغاية ، وربما لا يقوم بعض المستخدمين في العالم بتثبيت مثل هذه الوحدات لأنهم لا يستطيعون أو لا يعرفون كيف يفعلونها. لكن لا يوجد بديل. لاستخدام توليد الباركود تحتاج مكتبة الباركود.

هنا ، الأمر مختلف. لقد قمت للتو بتحديث تحليل مصدر كود OCA. اليوم هناك 4182 وحدة. (يتم حساب الوحدة الموجودة في مرحلتين مهمتين مرتين). من ناحية أخرى ، في كل تلك الـ 4182 وحدة ، لا يوجد سوى 274 تبعيات للبيثون. لذا فإن 94٪ من وحدات OCA لا تعتمد على

إذا كان هناك غدًا أوكا بيثون ليب إضافي جيد مع ديكورات مفيدة (مثل الذي نحاول وصفه في هذا الموضوع الذي يحاول إصلاح مشكلة أمنية) ، فإن معظم وحدات OCA ستعتمد على هذا lib ، خطوة بخطوة.

الهدف من OCA هو تعزيز عمل أعضاء OCA. لذلك ، إذا كان هذا القرار (لإنشاء lib للتثبيت) يقلل من إمكانية استخدام الأشخاص للوحدات النمطية OCA ، أعتقد أنه لا ينبغي لنا السير في هذا الاتجاه في الوقت الحالي. يمكننا أولاً إنشاء مستودع صغير لتزيين محيط العين ، مع وحدات كلاسيكية . وإذا كانت ناضجة خلال عام ونصف ، وإذا كان نظام النشر والاستضافة أكثر نضجًا أيضًا (*) ، فسيكون من السهل جدًا وضع كل التعليمات البرمجية في lib خارجي.

كان كود openupgrade موجودًا خلال سنوات في مستودع Openupgrade وتم تعيينه في lib خارجي مؤخرًا بواسطةStefanRijnhart. أعتقد أن هذه التغييرات لم تكن مشكلة كبيرة.

(*): لقد تغير نظام الاستضافة والنشر كثيرًا خلال السنوات الماضية. (الحصول على الكود عن طريق bzr ، والحصول على الكود عن طريق github ، واستخدام تقنية buildout ، ونشر pypi مؤخرًا)

أود أن أسمع ما يفكر فيه @ OCA / board حول هذه النقطة. إنه ليس قرارًا تقنيًا فحسب ، بل هو أيضًا قرار استراتيجي

الآن بعد أن أصبح https://github.com/OCA/oca-decorators متاحًا ، يمكن لهذا RFC الانتقال إلى هناك.

legalsylvain - لقد قدمت في الأصل وحدة api.foreach قبل إنشاء هذه كمكتبة. ألق نظرة على هذه العلاقات العامة وسترى سبب تخلينا عن هذه الاستراتيجية.

كان استخدام واجهة برمجة التطبيقات أمرًا شبه مستحيل عند بدء احتساب مسار استيراد يتراوح من 60 إلى 70 حرفًا ، وتجربة / باستثناء ذلك يجب وضعه حول كل من الواردات. سيؤدي هذا إلى جعل اعتماد الوحدة صفرًا بشكل أساسي - الاستيراد أصعب من حلقة التسجيل.

ومن المثير للاهتمام أن إستراتيجية المحاولة / الاستثناء الخاصة بنا فشلت فشلاً ذريعًا مع مصممي الديكور ، ولكن هذا موضوع مختلف تمامًا. مرة أخرى ، أتمنى أن يقوم Odoo بإصلاح مفتاح external_dependencies .

dreispt - هل هناك طريقة جيدة لنقل هذه المناقشة الموجودة مسبقًا إلى ريبو آخر؟ هناك الكثير من النقاط التي تم الكشف عنها هنا والتي لست متأكدًا من أنها ستنتقل بسلاسة.

كان استخدام واجهة برمجة التطبيقات أمرًا شبه مستحيل عند بدء احتساب مسار استيراد يتراوح من 60 إلى 70 حرفًا ، وتجربة / باستثناء ذلك يجب وضعها حول كل من الواردات

لا أفهم ما هي المحاولة / باستثناء الحاجة في هذا الحل.

لاستخدام مصمم oca @ foreach ، حدد في oca_api lib أو وحدة نمطية. :

تأثيرات حل Lib
نشر :

• تثبيت نقطة أو عن طريق البناء. قيود Saas.

ملف البيان:

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

ملف بايثون:

from oca_api import oca

تأثيرات حل الوحدة النمطية
نشر :

• نقطة التثبيت أو التنزيل والتثبيت عبر واجهة المستخدم أو عبر الإنشاء أو مجرد إضافة وحدة نمطية في ملف الإضافات. لا يوجد قيود saas.

ملف البيان:

'depends': ['oca_api'],

ملف بايثون:

from odoo.addons.oca_api import oca

أو هل فاتني شيء؟ إذا كانت الإجابة بنعم يرجى تصحيح لي.

أطيب التحيات.

لا أفهم ما هي المحاولة / باستثناء الحاجة في هذا الحل.

المحاولة / الاستثناء هي ما يتعين علينا القيام به عند استيراد أي شيء ليس جوهر Odoo ، لذلك ستكون الأمثلة التالية بدلاً من ذلك:

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

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

ولكن مع تسمية الوحدة الخاصة بك ، فهي ليست بنفس السوء الذي كانت عليه.

أعتقد أن الكثير من هذا يتعلق بحقيقة أن الوحدة لا يتم تثبيتها في قاعدة بيانات ، ولا يتم تغليفها بالبيئة مثل معظم الوحدات النمطية. هذا يعني أنه يوفر وظائف للبيئات التي لم تقم بتثبيت الوحدة بشكل صريح ، ويمكن اعتبارها مشكلة (أمان أو غير ذلك).

كشفlmignon للتو عن وسيطة مماثلة لما ورد أعلاه في https://github.com/OCA/webhook/pull/3#issuecomment -336935193. أعتقد أن هذه محادثات متوازية - تغلي بشكل أساسي في كيفية تقديم مجموعات ميزات مثل هذه.

أنا شخصياً أشعر أن lmignon موجود هنا ويجب أن نقدم هذا foreach الديكور من وحدة نمطية كذلك.

مرحبًا @ Lasley.

آه شكرا! اعتقدت أن جعل التبعيات على وحدة نمطية كان كافيًا لافتراض وجود الوحدة ، ولكن rgreping كل كود OCA ، رأيت الكثير من العينات لما تتحدث. (الكثير لـ report_xls والموصل).

لا أمتلك المهارات اللازمة لفهم قضايا الأمن بسبب الوحدة. بالنسبة لي ، إذا لم يتم تثبيت الوحدة النمطية ، فلا ينبغي استدعاء رمز الوحدة النمطية لـ oca_api. لكن ربما أكون مخطئا.

مع تحياتي.

اعتقدت أن جعل التبعيات على وحدة نمطية كافٍ لافتراض وجود الوحدة ،

ألق نظرة على https://github.com/odoo/odoo/pull/14850 لمزيد من المعلومات

بالنسبة لي ، إذا لم يتم تثبيت الوحدة النمطية ، فلا ينبغي استدعاء رمز الوحدة النمطية لـ oca_api.

في وهنا تكمن المشكلة. ليس هذا هو الحال - يقوم Odoo باستيراد جميع الوحدات داخل المسار addons في الذاكرة. نتيجة لهذا ، ستنجح عمليات الاستيراد على الوحدة في أي وحدة - سواء تم تثبيت الوحدة التابعة بالفعل أم لا.

هذا هو الأساس في Odoo ، ومن الناحية الواقعية لا يوجد تحايل. وهذا أيضًا هو سبب عدم مشاركتي في استضافة عملائي بنفس الطريقة التي تستضيفها شركة Odoo SA. أشعر بالفضول إذا تمكنوا من حل هذه المشكلة باستخدام Odoo.sh ، لكن أعتقد أن لديهم قنبلة موقوتة على أيديهم في SaaS

شكرا على كل هذه التوضيحات. من المؤسف أن odoo / odoo # 14850 غير مقبول.
ما زلت أعتقد أن إنشاء الكثير من وحدات OCA اعتمادًا على lib خارجي سيحد بالتأكيد من استخدام هذه الوحدات. لكن حسنًا ، لا يبدو أن الوحدة النمطية هي حل بالفعل.
تحياتي وشكرا جزيلا على بصيرتك.

أغلقت هذه القضية. (انتقل إلى https://github.com/OCA/oca-decorators/issues/7)
تحياتي وشكرًا على كل تعليقاتك.