Server-tools: [RFC] समारोह के लिए नए एपीआई.ग्रुप्स डेकोरेटर

मुझे लगता है कि यह एक अच्छा विचार है - अस्पष्टता से सुरक्षा (बटन छिपाना) काम नहीं करता है।

सवाल यह है कि इसे कहां रखा जाए। मैंने एक OCA पायथन मॉड्यूल बनाया है, जिसमें api.foreach कार्यान्वयन है, लेकिन OCA के मोर्चे पर इसे प्राप्त करने में कोई गति नहीं थी

मुझे अभी भी लगता है कि OCA API लाइब्रेरी होना एक अच्छा विचार है। @ टेल्स आपको केवल OCA इंस्टेंस टास्क ("प्रोजेक्ट बनाएँ") में लगाई गई विधि के बाद रेपो बनाने की जरूरत है और PR बनायें।

इस सुविधा के बारे में: +1: इसे जोड़ने के लिए, लेकिन सज्जाकारों के साथ add_groups और इतने पर नहीं। इसे विरासत के साथ संभाला जाना चाहिए: यदि आप डेकोरेटर में किसी नए समूह को एक अधिलेखित पद्धति पर जोड़ते हैं, तो उस समूह को सूची में जोड़ा जाता है। समूहों को हटाने के बारे में, फिर आपको अन्य तकनीकों का उपयोग करना चाहिए जैसे कि कोर (उदाहरण के लिए, कम समूहों के साथ एक अन्य विधि जो मूल विधि कहती है)।

नमस्ते ! आपके उत्तर के लिए धन्यवाद। एक OCA API लाइब्रेरी LGTM। महान विचार !

लेकिन सज्जाकार add_groups और इतने पर के साथ नहीं

आप सही हैं, इसे वास्तव में सरल बनाया जा सकता है।

समूहों को हटाने के बारे में, फिर आपको अन्य तकनीकों का उपयोग करना चाहिए जैसे कि कोर (उदाहरण के लिए, कम समूहों के साथ एक अन्य विधि जो मूल विधि कहती है)।

सुनिश्चित नहीं है कि यह सभी जरूरतों को कवर करेगा, लेकिन हम नए रेपो के खिलाफ एक विशिष्ट पीआर में इसके बारे में बात करेंगे।

@ टेल्स आपको केवल OCA इंस्टेंस टास्क ("प्रोजेक्ट बनाएँ") में लगाई गई विधि के बाद रेपो बनाने की जरूरत है और PR बनायें।

@ टेल्स , कृपया मुझे पिंग करें जब रेपो बनाया जाता है, तो मैं एक पीओसी शुरू करूंगा और अगले ओपन (/ बंद) दिनों में काम खत्म करने की कोशिश करूंगा।

मुझे अभी भी लगता है कि OCA API लाइब्रेरी होना एक अच्छा विचार है। @ टेल्स आपको केवल OCA इंस्टेंस टास्क ("प्रोजेक्ट बनाएँ") में लगाई गई विधि के बाद रेपो बनाने की जरूरत है और PR बनायें।

अच्छा बिंदु - उस समय मेरे पास ऐसा करने की अनुमति नहीं थी। मैं इस प्रक्रिया को OCA उदाहरण में नहीं ढूँढ रहा हूँ, हालांकि, मैं थोड़ा और खुदाई करूँगा और नए रेपो के साथ वापस रिपोर्ट करूँगा।

हम्म् ठीक है हां, इसलिए मैं रेपो निर्माण के लिए एक प्रक्रिया नहीं ढूंढ सकता हूं, इसलिए मैं सिर्फ आगे जाकर रेपो बनाने जा रहा था - लेकिन ऐसा लगता है कि मेरे पास अनुमति नहीं है। @pedrobaeza क्या आप एक रिक्त OCA / अजगर-ओसा रेपो बनाने में मन सकूं ?

This ऐसा करने वाले डेकोरेटर के लिए। मेरे पास @privileged डेकोरेटर बनाने का विचार था जो एक ही काम करेगा और जिसे सर्वर-टूल्स में एक नए टूल मॉड्यूल से आयात किया जा सकता है।

लेकिन डेकोरेटर का एक पाइप लाइब्रेरी का हिस्सा होने के साथ-साथ हो सकता है। मुझे केवल @ api.groups नाम के बारे में आश्चर्य है। क्या यह भ्रामक नहीं होगा क्योंकि यह ओडू आपी पायथन मॉड्यूल से नहीं आ रहा है?

हाय @ NL66278 ,

खैर, नाम स्थान के बारे में, मुझे लगता है कि टकराव संभव नहीं होगा, क्योंकि नाम @ oca.groups होगा न कि @ api.groups। (या ऐसा ही कुछ)

@legalsylvain मैं पहले उदाहरण के उपयोग पर प्रतिक्रिया कर रहा था। @oca.groups होने से बहुत अच्छा होगा।

@legalsylvain यह एक अच्छा विचार है!

मैं सभी ओका पैकेजों के लिए एक नामस्थान पैकेज के रूप में 'ओका' रखना चाहूंगा। हम इस नए पैकेज को 'ओका-डेकोरेटर' नाम दे सकते हैं। यह पैकेज 'oca.decorator' (या oca.xyz) प्रदान करेगा

from oca.decorator import groups

    @groups(..)
    def function_name():

लगभग groups मैं उदाहरण allowed_groups लिए अधिक स्पष्ट नाम पसंद करूंगा।

लामी

@lasley यह वह कार्य है जहाँ एक नई रिपॉजिटरी / PSC के लिए प्रक्रिया निर्दिष्ट की गई है: https://odoo-community.org/web#id = 264 और view_type = form & model = project.task & action = 468 और active_id = 2

ओमग धन्यवाद पेड्रो! किसी कारण से मैंने प्रोजेक्ट से रेपो तक सब कुछ खोज लिया, लेकिन "पीएससी" को शामिल करने के लिए नहीं सोचा। Derp!

मुझे अभी भी OCA GitHub में कुछ अतिरिक्त अधिकारों की आवश्यकता होगी - मेरे पास नया बटन नहीं है:

अब फिर से कोशिश करें कि मैंने आपकी भूमिका बदल दी है।

@lasley @pedro क्यों python-oca ? यह नाम निरर्थक है। आप अजगर पैकेज का नाम कैसे देते हैं?

@lmignon - मैंने सुझाव मांगे और यह सबसे अच्छा था। अजगर पैकेज को इसी तरह नामित किया गया है।

क्या विचार है? मैं सुन रहा हु।

@ जेल्ली मेरा मुख्य चिंता एक अखंड अजगर पैकेज के निर्माण से बचना है। यदि प्राथमिक लक्ष्य यह है कि नए विशेष सज्जाकार प्रदान करें तो ओसा-डेकोरेटर क्यों नहीं। नाम को पैकेज द्वारा कवर किए गए कार्यात्मक दायरे या जो भी आप चाहते हैं, उस पर निर्भर होना चाहिए। कम से कम नाम सार्थक होना चाहिए। IMO 'अजगर-महासागर' बहुत विस्तृत है।

मैं oca-decorator साथ अच्छा हूं, हालांकि हमें मॉड्यूल को थोड़ा अलग ढंग से संरचना करने की आवश्यकता होगी, जो मुझे लगता है कि इसके बाद सज्जाकारों को नाम स्थान में शीर्ष-स्तरीय बनाना है। मुझे यकीन है कि यह मूल रूप से मेरे पास था, लेकिन हमने इसे LasLabs / python-oca # 1 में oca.helpers वापस धकेल दिया।

वैसे भी यह परिवर्तन करना काफी आसान है, और मुझे लगता है कि कोड के संदर्भ में इस पर चर्चा करना बेहतर होगा। यह देखते हुए कि मैंने रेपो बनाया, पीआर सबमिट करेगा और आपके सुझाव को शामिल करेगा - फिर हम इस अपहृत पीआर के बजाय संदर्भ में चर्चा कर सकते हैं।

@lasley oca नेमस्पेस खाली रहना चाहिए। अन्यथा समान नाम स्थान के तहत अन्य अजगर पैकेज बनाना संभव नहीं होगा।

है, समझ लिया तो हम मूल रूप से हमारे नाम बदलना चाहते हैं जाएगा helpers करने के लिए पैकेज decorators , तो फोन है कि अजगर सामान के लिए हमारे स्कीमा? सार oca-package-sub == oca.package.sub

हाँ: मुस्कुराओ: यह विचार है।

बहुत बुरा ocapi लिया जाता है: smile_cat:

https://github.com/OCA/oca-decorators/pull/1 सबमिट किया गया

इस कोड की संरचना के बारे में मेरा एक प्रश्न है। (शायद मेरा सवाल अप्रासंगिक है, क्षमा करें)

मूल रूप से, मैं इस कोड को लिखने के दो तरीके देखता हूं।

ए) एक शास्त्रीय ओडो मॉड्यूल के माध्यम से (एक मौजूदा या नए भंडार में)। इसलिए, इसका उपयोग करने के लिए, हमें कुछ लिखना होगा

from odoo.addons.my_oca_lib_in_module import my_decorator

बी) एक अजगर के माध्यम से lib।

ऐसा लगता है कि आप सभी समाधान "बी" के बारे में बात कर रहे हैं, और निश्चित रूप से, यह क्लीनर समाधान है।
लेकिन दूसरे हाथ में, मुझे डर है कि इस तरह की तकनीक कुछ उपयोगकर्ताओं को अवरुद्ध करेगी जिनके पास मॉड्यूल का उपयोग करने के लिए कोई तकनीकी कौशल नहीं है जो नए ओसा-पायथन के काम पर निर्भर करते हैं। मुझे लगता है कि यूआई के माध्यम से मॉड्यूल स्थापित करने वाले लोगों के लिए एक उदाहरण के लिए या odoo.sh के माध्यम से (और कल OCA ऐपस्टोर के साथ कल हो सकता है!)। मुझे यकीन नहीं है कि सभी होस्टिंग सिस्टम आसानी से कस्टम पायथन लिब को स्थापित करने की अनुमति देंगे।
यह अफ़सोस की बात है अगर कुछ उपयोगकर्ताओं को ओसीए मॉड्यूल स्थापित करने की संभावना नहीं होगी, क्योंकि एक अतिरिक्त देयता पर निर्भर करता है जो कुछ लोगों के लिए स्थापित करने योग्य नहीं है।

फिलहाल OCA में केवल एक अन्य छूट है। Openupgradelib। कोड शुरू में OpenUpgrade परियोजना में था, और एक बाहरी अजगर-काम में ले जाया गया था। मेरे लिए यह ओपनअपग्रेडेलिब के लिए एक अवरुद्ध बिंदु नहीं है, क्योंकि एक उन्नयन करना एक तकनीकी चीज है।

तुम क्या सोचते हो ?

क्या हम जानते हैं कि Odoo.sh पाइप निर्भरता को कैसे संभालता है?

IMO यह उन पर है कि external_depencies मेनिफ़ेस्ट में ठीक किया जाए - हमारे पास बहुत सारे मॉड्यूल हैं जो इसका उपयोग करते हैं। मुझे नहीं लगता कि इस नई लाइब्रेरी का उपयोग कर मॉड्यूल जो एक राशि, किसी भी अलग होगा barcodes_generator_abstract की आवश्यकता होती है barcode

Odoo.sh (या फ्रेंच लोगों के लिए Odoo.hs) अगला Runbot नहीं है। बेट लिया।

😆 हाँ हम जानते हैं कि मेरी शर्त उस पर कहाँ है

हमारे पास बहुत सारे मॉड्यूल हैं जो इसका उपयोग करते हैं (@lasley द्वारा)

वास्तव में, लेकिन यह काफी अलग है। बेशक, यदि आप एक ऐसी प्रणाली चाहते हैं जो बारकोड पीढ़ी को संभालती है, तो आपको बारकोड को स्थापित करना चाहिए। तारांकन के लिए समान, आदि ...
लेकिन यह बहुत सीमित है, और शायद दुनिया में कुछ उपयोगकर्ता ऐसे मॉड्यूल स्थापित नहीं कर रहे हैं क्योंकि वे नहीं कर सकते हैं या वे नहीं जानते कि कैसे करना है। लेकिन कोई विकल्प नहीं है। बारकोड पीढ़ी का उपयोग करने के लिए आपको बारकोड लाइब्रेरी की आवश्यकता होती है।

यहाँ, यह अलग है। मैंने अभी OCA कोड सोर्स विश्लेषण को अपडेट किया है। आज 4182 मॉड्यूल हैं। (दो मील के पत्थर में मौजूद एक मॉड्यूल दो बार गिना जाता है)। दूसरी ओर, सभी 4182 मॉड्यूलों में, केवल 274 अजगर निर्भरताएं हैं। तो OCA मॉड्यूल का 94% बाहरी अजगर के लिबास पर निर्भर नहीं है और इसे बहुत आसानी से स्थापित किया जा सकता है। विवरण :

यदि कल, उपयोगी सज्जाकारों के साथ एक अच्छा अतिरिक्त ओका पायथन कार्य है (जैसे हम इस धागे में वर्णन करने की कोशिश करते हैं जो एक सुरक्षा मुद्दे को ठीक करने की कोशिश करते हैं), OCA के अधिकांश मॉड्यूल इस दायित्व पर निर्भर करते हैं, चरण दर चरण।

OCA का उद्देश्य OCA सदस्यों के काम को बढ़ावा देना है। इसलिए यदि इस तरह का निर्णय (स्थापित करने के लिए एक दायित्व बनाने के लिए) लोगों को ओसीए मॉड्यूल का उपयोग करने की संभावना को कम कर रहा है, तो मुझे लगता है कि हमें इस दिशा में फिलहाल नहीं जाना चाहिए। हम शास्त्रीय मॉड्यूल के साथ पहले थोड़ा सा ओसा-डेकोरेटर रिपॉजिटरी बना सकते हैं। और अगर 1/2 साल में, यह परिपक्व है, और यदि तैनाती और होस्टिंग सिस्टम अधिक परिपक्व (*) हैं, तो सभी कोड को बाहरी देयता में रखना बहुत आसान होगा।

ओपनअपग्रेड कोड ओपनअपग्रेड रिपॉजिटरी में वर्षों के दौरान रहा है और हाल ही में @StefanRijnhart द्वारा एक बाहरी परिवाद में सेट किया गया है। मुझे लगता है कि यह बदलाव कोई बड़ी बात नहीं थी।

(*): पिछले वर्षों के दौरान होस्टिंग और परिनियोजन प्रणाली बहुत बदल गई है। (bzr द्वारा कोड प्राप्त करना, जीथब द्वारा कोड प्राप्त करना, बिल्डआउट तकनीक का उपयोग करना, और हाल ही में pypi परिनियोजन)

मैं सुनना चाहता हूं कि @ OCA / बोर्ड उस बिंदु के बारे में क्या सोच रहे हैं। यह केवल एक तकनीकी निर्णय नहीं है, यह एक रणनीतिक निर्णय भी है

अब चूंकि https://github.com/OCA/oca-decorators उपलब्ध है, यह RFC वहां जा सकती है।

@legalsylvain - मैंने इसे लाइब्रेरी के रूप में बनाने से पहले मूल रूप से api.foreach लिए एक मॉड्यूल प्रस्तुत किया था। इस पीआर पर एक नज़र डालें, और आप देखेंगे कि हमने इस रणनीति को क्यों छोड़ दिया।

जब आप 60-70 वर्णों वाले आयात पथ के लिए लेखांकन प्रारंभ करते हैं, और एक कोशिश / सिवाय इसके कि आप आयात के प्रत्येक के आसपास रखा जा सकता है के अलावा, एपीआई का उपयोग असंभव के पास खराब हो गया था। यह मॉड्यूल को मूल रूप से शून्य बना देगा - आयात रिकॉर्ड लूप की तुलना में कठिन है।

दिलचस्प रूप से पर्याप्त हमारी कोशिश / रणनीति को छोड़कर सज्जाकारों के साथ बुरी तरह से विफल हो जाती है, लेकिन यह पूरी तरह से अलग विषय है। फिर से, मैं चाहता हूं कि ओडू उनके external_dependencies कुंजी को ठीक करेगा।

@dreispt - इस पूर्व-मौजूदा चर्चा को दूसरे रेपो में स्थानांतरित करने का एक अच्छा तरीका है? यहां बहुत सारे बिंदुओं को उजागर किया गया है जो मुझे यकीन नहीं है कि द्रवित रूप से खत्म हो जाएंगे।

जब आप 60-70 चार्ट वाले आयात पथ के लिए लेखांकन शुरू करते हैं, तो एपीआई का उपयोग असंभव के करीब था

मुझे समझ नहीं आ रहा है कि उस समाधान में क्या जरूरत है सिवाय इसके।

एक oca @ foreach डेकोरेटर का उपयोग करने के लिए oca_api lib या मॉड्यूल में परिभाषित करें। :

लिब सॉल्यूशन पर असर पड़ता है
तैनात करें:

• पाइपलाइन स्थापित करें या बिल्डआउट के माध्यम से। सास मर्यादा।

प्रकट फ़ाइल:

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

पायथन फ़ाइल:

from oca_api import oca

मॉड्यूल समाधान प्रभावित करता है
तैनात करें:

• पाइप स्थापित करें या डाउनलोड करें और यूआई के माध्यम से या बिल्डआउट के माध्यम से या बस एडोनस फ़ाइल में एक मॉड्यूल जोड़कर स्थापित करें। कोई सास मर्यादा नहीं।

प्रकट फ़ाइल:

'depends': ['oca_api'],

पायथन फ़ाइल:

from odoo.addons.oca_api import oca

या मैं कुछ याद किया? यदि हाँ, तो कृपया मुझे सुधारें।

सधन्यवाद।

मुझे समझ नहीं आ रहा है कि उस समाधान में क्या जरूरत है सिवाय इसके।

कोशिश / सिवाय इसके कि हमें क्या करना है जब कुछ भी आयात करना है जो कोर ओडू नहीं है, इसलिए आपके उदाहरण इसके बजाय निम्नलिखित होंगे:

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 में ऊपर दिए गए इसी तरह के तर्क को उजागर किया। मुझे लगता है कि ये समानांतर बातचीत हैं - मूल रूप से हम इस तरह से फीचर-सेट प्रदान करते हैं।

मुझे व्यक्तिगत रूप से लगता है कि @ लमिग्नन यहीं है और हमें यह एक foreach डेकोरेटर को भी स्थानांतरित किया।

हाय @ लसले।

ओउ धन्यवाद! मैंने सोचा था कि एक मॉड्यूल के लिए निर्भरता बनाना यह मानने के लिए पर्याप्त था कि मॉड्यूल मौजूद है, लेकिन सभी ओसीए कोड को rgreping, मैंने बहुत सारे नमूने देखे जो आप बात करते हैं। (report_xls और कनेक्टर के लिए बहुत कुछ)।

मेरे पास एक मॉड्यूल के कारण सुरक्षा मुद्दों को समझने के लिए कौशल नहीं है। मेरे लिए, यदि मॉड्यूल स्थापित नहीं है, तो oca_api के मॉड्यूल के कोड को नहीं बुलाया जाना चाहिए। लेकिन शायद मैं गलत हूं।

सादर प्रणाम।

मुझे लगा कि एक मॉड्यूल के लिए निर्भरता बनाना यह मानने के लिए पर्याप्त था कि मॉड्यूल मौजूद है,

अधिक जानकारी के लिए https://github.com/odoo/odoo/pull/14850 पर एक नज़र डालें

मेरे लिए, यदि मॉड्यूल स्थापित नहीं है, तो oca_api के मॉड्यूल के कोड को नहीं बुलाया जाना चाहिए।

उसमें समस्या है। यह मामला नहीं है - ओडू सभी मॉड्यूल addons पथ में मेमोरी में आयात करता है। इसके कारण, मॉड्यूल पर आयात किसी भी मॉड्यूल में सफल होगा - चाहे आश्रित वास्तव में स्थापित हो या न हो।

यह ओडू में मूल है, और वास्तविक रूप से कोई परिधि नहीं है। यह भी है कि मैं अपने ग्राहकों की उसी तरह से सह-मेजबानी नहीं करता जिस तरह ओडू एसए करता है। मैं उत्सुक हूँ अगर वे Odoo.sh के साथ इसे हल करने में कामयाब रहे हैं, लेकिन मेरा अनुमान है कि उनके सास में उनके हाथों पर टिक टिक है

इस सभी स्पष्टीकरण के लिए धन्यवाद। यह अफ़सोस की बात है कि odoo / odoo # 14850 स्वीकार नहीं किया गया है।
मुझे अभी भी लगता है कि बाहरी दायित्व के आधार पर बहुत सारे ओसीए मॉड्यूल बनाने से निश्चित रूप से इन मॉड्यूल का उपयोग सीमित हो जाएगा। लेकिन ठीक है, एक मॉड्यूल वास्तव में एक समाधान नहीं लगता है।
सादर और आपकी जानकारी के लिए बहुत बहुत धन्यवाद।

मैं इस मुद्दे को बंद करता हूं। (https://github.com/OCA/oca-decorators/issues/7 में स्थानांतरित)
आपकी सभी टिप्पणियों के लिए धन्यवाद और धन्यवाद।