ओडू 17 से ओडू 18 में स्थानांतरण: क्या परिवर्तन, क्या टूटता है, और कैसे तैयारी करें

ओडू हर साल एक प्रमुख संस्करण जारी करता है, और प्रत्येक अपग्रेड नई सुविधाएँ, प्रदर्शन में सुधार और अनिवार्य रूप से महत्वपूर्ण परिवर्तन लाता है। Odoo 17 से Odoo 18 में माइग्रेट करने के लिए सावधानीपूर्वक योजना बनाने की आवश्यकता होती है, खासकर यदि आप कस्टम मॉड्यूल चलाते हैं या सामुदायिक ऐड-ऑन पर भरोसा करते हैं। इस गाइड में ओडू 17 से 18 माइग्रेशन के बारे में वह सब कुछ शामिल है जो आपको जानना आवश्यक है: मुख्य परिवर्तन, संभावित टूट-फूट, तैयारी के चरण और परीक्षण रणनीतियाँ।

Odoo 18 में अपग्रेड क्यों करें?

Odoo 18 ने पूरे प्लेटफ़ॉर्म में महत्वपूर्ण सुधार पेश किए:

• नए OWL 3 घटक: बेहतर प्रदर्शन और डेवलपर अनुभव के साथ फ्रंटएंड घटकों को फिर से लिखा गया
• एआई-संचालित विशेषताएं: पूर्वानुमानित लीड स्कोरिंग, स्मार्ट बैंक समाधान सुझाव, और एआई-सहायता प्राप्त सामग्री निर्माण
• स्प्रेडशीट सुधार: वास्तविक समय ओडू डेटा, पिवट टेबल और सहयोगी संपादन के साथ मूल स्प्रेडशीट एकीकरण
• विनिर्माण उन्नयन: बेहतर उत्पादन शेड्यूलिंग, उपठेका पोर्टल और शॉप फ्लोर टैबलेट इंटरफ़ेस
• प्रदर्शन: अनुकूलित एसेट बंडलिंग और आलसी लोडिंग के माध्यम से 15-25% तेज पेज लोड होता है
• वेबसाइट बिल्डर: नए ड्रैग-एंड-ड्रॉप ब्लॉक, थीम अनुकूलन विकल्प और बेहतर मोबाइल संपादन

पुराने संस्करणों पर बने रहने का मतलब है सुरक्षा पैच गायब होना, सामुदायिक मॉड्यूल अपडेट तक पहुंच खोना और तकनीकी ऋण जमा होना जो भविष्य में प्रवासन को कठिन बना देता है।

समयरेखा: ओडू प्रवासन में कितना समय लगता है?

| जटिलता | कस्टम मॉड्यूल | अनुमानित समयरेखा | |---|---|---| | मानक (कोई कस्टम कोड नहीं) | 0 | 1-2 सप्ताह | | निम्न (कुछ कस्टम फ़ील्ड/दृश्य) | 1-5 | 2-4 सप्ताह | | मध्यम (कस्टम वर्कफ़्लोज़) | 5-15 | 4-8 सप्ताह | | उच्च (गहन अनुकूलन) | 15+ | 8-16 सप्ताह |

इन समयसीमाओं में विश्लेषण, माइग्रेशन, परीक्षण और गो-लाइव शामिल हैं। सबसे बड़ा चर कस्टम मॉड्यूल जटिलता है।

ओडू 18 में परिवर्तन को तोड़ना

ओडब्लूएल फ्रेमवर्क में बदलाव

Odoo 18 OWL 3 में माइग्रेशन जारी रखता है। यदि आपके कस्टम मॉड्यूल में फ्रंटएंड जावास्क्रिप्ट घटक शामिल हैं, तो इन परिवर्तनों की अपेक्षा करें:

मुख्य OWL परिवर्तन:

• घटक जीवनचक्र: willStart और willUpdateProps को setup() और onWillStart हुक से बदल दिया जाता है
• टेम्पलेट संकलन: क्यूवेब टेम्प्लेट अब रनटाइम के बजाय बिल्ड टाइम पर अनुकूलित जावास्क्रिप्ट में संकलित होते हैं
• सेवा इंजेक्शन: विशेष रूप से this.env.services पैटर्न के माध्यम से सेवाओं तक पहुंच; प्रत्यक्ष आयात को बहिष्कृत कर दिया गया है
• एसेट बंडलिंग: web.assets_backend बंडल संरचना बदल गई है; अपनी __manifest__.py परिसंपत्ति घोषणाओं को अद्यतन करें

उदाहरण माइग्रेशन:

// Odoo 17
class MyComponent extends Component {
    async willStart() {
        this.data = await this.rpc('/my/endpoint');
    }
}

// Odoo 18
class MyComponent extends Component {
    setup() {
        onWillStart(async () => {
            this.data = await this.env.services.rpc('/my/endpoint');
        });
    }
}

पायथन बैकएंड परिवर्तन

मॉडल और फ़ील्ड परिवर्तन:

• fields.Monetary को अब currency_field को स्पष्ट रूप से घोषित करने की आवश्यकता है (अब currency_id पर डिफ़ॉल्ट नहीं)
• @api.multi डेकोरेटर को पूरी तरह से हटा दिया गया था (v13 के बाद से अप्रचलित, लेकिन कुछ सामुदायिक मॉड्यूल अभी भी इसका उपयोग करते हैं)
• sudo() व्यवहार परिवर्तन: sudo() बिना तर्क के अब स्पष्ट रूप से OdooBOT उपयोगकर्ता के बजाय SUPERUSER का उपयोग करता है
• search_count() अब प्रदर्शन अनुकूलन के लिए एक वैकल्पिक limit पैरामीटर स्वीकार करता है

अपडेट करने के लिए अप्रचलित तरीके:

| पदावनत (v17) | प्रतिस्थापन (v18) | |---|---| | fields.Many2one.search() | fields.Many2one domain विशेषता के साथ | | _register_hook() | प्रकट में _post_init_hook | | मॉडलों में डायरेक्ट एसक्यूएल | उचित मानकीकरण के साथ self.env.cr.execute() | | website.published फ़ील्ड | website.is_published (बदला हुआ नाम) |

देखें और टेम्पलेट परिवर्तन

• फ़ॉर्म दृश्य: sheet रैपर अब सभी फॉर्म दृश्यों के लिए अनिवार्य है (पहले वैकल्पिक)
• सूची दृश्य: tree टैग का आधिकारिक तौर पर नाम बदलकर list कर दिया गया है (पिछला-संगत उपनाम अभी भी काम करता है लेकिन बहिष्करण चेतावनियों को ट्रिगर करता है)
• कानबन दृश्य: QWeb t-esc अब डिफ़ॉल्ट है; t-raw को सुरक्षा के लिए स्पष्ट ऑप्ट-इन की आवश्यकता है
• रिपोर्ट QWeb: पीडीएफ रेंडरिंग इंजन अपडेट किया गया; लेआउट परिवर्तन के लिए सभी मुद्रित रिपोर्टों का परीक्षण करें

डेटाबेस स्कीमा परिवर्तन

Odoo 18 में मुख्य तालिकाओं में संरचनात्मक परिवर्तन शामिल हैं:

• sale.order.line को सदस्यता प्रबंधन के लिए नए क्षेत्र प्राप्त होते हैं
• account.move.line में नए समाधान-संबंधित कॉलम शामिल हैं
• बड़ी सूची के साथ बेहतर प्रदर्शन के लिए stock.quant तालिका का पुनर्गठन किया गया
• mail.message और mail.activity तालिकाएँ नई अनुक्रमणिकाओं के साथ अनुकूलित

इन स्कीमा परिवर्तनों को मानक मॉड्यूल के लिए ओडू की अंतर्निहित माइग्रेशन स्क्रिप्ट द्वारा नियंत्रित किया जाता है, लेकिन इन तालिकाओं को संदर्भित करने वाले कस्टम मॉड्यूल को मैन्युअल अपडेट की आवश्यकता होती है।

##प्रवास-पूर्व तैयारी चेकलिस्ट

1. अपने वर्तमान इंस्टालेशन का ऑडिट करें

शुरू करने से पहले सब कुछ दस्तावेज़ित करें:

• [ ] सभी स्थापित मॉड्यूल (आधिकारिक, समुदाय और कस्टम) की सूची बनाएं
• [ ] वर्तमान ओडू संस्करण और पैच स्तर रिकॉर्ड करें
• [ ] सभी कस्टम विकास (फ़ील्ड, मॉडल, दृश्य, रिपोर्ट, निर्धारित क्रियाएँ) का दस्तावेज़ीकरण करें
• [ ] सभी बाहरी एकीकरणों की सूची बनाएं (भुगतान गेटवे, शिपिंग वाहक, तृतीय-पक्ष एपीआई)
• [ ] वर्तमान पहुंच अधिकार और रिकॉर्ड नियम कॉन्फ़िगरेशन निर्यात करें
• [ ] उत्पादन डेटाबेस और फाइलस्टोर का पूरी तरह से बैकअप लें

2. सामुदायिक मॉड्यूल संगतता की जाँच करें

प्रत्येक समुदाय (ओसीए या तृतीय-पक्ष) मॉड्यूल के लिए:

• जांचें कि GitHub या Odoo Apps स्टोर पर Odoo 18-संगत संस्करण मौजूद है या नहीं
• यदि कोई संगत संस्करण मौजूद नहीं है, तो तय करें कि मॉड्यूल को स्वयं पोर्ट करना है, कोई विकल्प ढूंढना है, या कार्यक्षमता को हटाना है
• वी18 पोर्ट पर ईटीए के लिए मॉड्यूल अनुरक्षकों से संपर्क करें

3. कस्टम मॉड्यूल पोर्ट तैयार करें

प्रत्येक कस्टम मॉड्यूल के लिए, माइग्रेशन प्रयास का आकलन करें:

कम प्रयास (प्रति मॉड्यूल 1-3 दिन):

• केवल नए फ़ील्ड और सरल दृश्यों वाले मॉड्यूल
• कोई JavaScript/OWL घटक नहीं
• परिवर्तित मूल तरीकों का कोई ओवरराइड नहीं

मध्यम प्रयास (प्रति मॉड्यूल 3-10 दिन):

• OWL घटकों वाले मॉड्यूल को अद्यतन की आवश्यकता है
• अप्रचलित या परिवर्तित मूल तरीकों को ओवरराइड करना
• कस्टम रिपोर्ट को QWeb अपडेट की आवश्यकता है

उच्च प्रयास (प्रति मॉड्यूल 10+ दिन):

• परिवर्तित कोर मॉड्यूल (लेखा, इन्वेंट्री, वेबसाइट) के साथ गहन एकीकरण
• जटिल OWL फ्रंटएंड अनुप्रयोग
• बड़े पैमाने पर अप्रचलित या हटाए गए एपीआई का उपयोग करने वाले मॉड्यूल

अनुभवी ओडू माइग्रेशन विशेषज्ञों के साथ काम करने से कस्टम मॉड्यूल को पोर्ट करने का समय और जोखिम काफी कम हो जाता है।

माइग्रेशन निष्पादन चरण

चरण 1: प्रवासन वातावरण स्थापित करें

Production (v17) ──backup──> Test Database (v17)
                                    │
                              Upgrade to v18
                                    │
                              Test Database (v18)
                                    │
                              Validation & UAT
                                    │
                              Production (v18)

इसके साथ एक अलग वातावरण बनाएं:

• एक ताज़ा Odoo 18 सर्वर इंस्टालेशन
• आपके उत्पादन डेटाबेस की एक प्रति
• सभी कस्टम मॉड्यूल v18 पर पोर्ट किए गए

चरण 2: डेटाबेस अपग्रेड चलाएँ

ओडू एंटरप्राइज के लिए: अपग्रेड.odoo.com पर ओडू की आधिकारिक अपग्रेड सेवा का उपयोग करें। अपना डेटाबेस अपलोड करें, और Odoo SA सभी मानक मॉड्यूल के लिए माइग्रेशन स्क्रिप्ट चलाता है।

ओडू समुदाय के लिए: OCA द्वारा openupgrade प्रोजेक्ट का उपयोग करें। ओपनअपग्रेड मानक मॉड्यूल के लिए समुदाय-संचालित माइग्रेशन स्क्रिप्ट प्रदान करता है:

1. लक्ष्य संस्करण के लिए ओपनअपग्रेड स्थापित करें
2. अपने परीक्षण डेटाबेस के विरुद्ध माइग्रेशन चलाएँ
3. त्रुटियों और चेतावनियों के लिए माइग्रेशन लॉग की समीक्षा करें
4. किसी भी समस्या को ठीक करें और साफ़ होने तक पुनः चलाएँ

चरण 3: पोर्ट कस्टम मॉड्यूल

प्रत्येक कस्टम मॉड्यूल के लिए:

1. __manifest__.py संस्करण को 18.0.x.x.x में अपडेट करें
2. पायथन कोड को ठीक करें (अप्रचलित एपीआई, परिवर्तित विधि हस्ताक्षर)
3. JavaScript/OWL घटकों को v3 पैटर्न में अपडेट करें
4. XML दृश्य ठीक करें (ट्री टू लिस्ट, शीट रैपर, टेम्पलेट परिवर्तन)
5. मॉड्यूल का परीक्षण सूट चलाएं और विफलताओं को ठीक करें
6. स्टेजिंग वातावरण में मैन्युअल रूप से परीक्षण करें

चरण 4: डेटा सत्यापन

माइग्रेशन के बाद, डेटा अखंडता सत्यापित करें:

• लेखा: v17 और v18 के बीच परीक्षण शेष के योग की तुलना करें। उन्हें बिल्कुल मेल खाना चाहिए.
• इन्वेंटरी: उच्च-मूल्य वाले उत्पादों के नमूने के लिए स्टॉक मात्रा सत्यापित करें।
• बिक्री/खरीद: खुले ऑर्डर और उनकी सही स्थिति की पुष्टि करें।
• संपर्क: जांचें कि पते और बैंक विवरण सहित ग्राहक और विक्रेता के रिकॉर्ड बरकरार हैं।
• अनुलग्नक: सत्यापित करें कि दस्तावेज़, चित्र और फ़ाइल अनुलग्नक पहुंच योग्य हैं।

परीक्षण रणनीति

स्तर 1: स्वचालित परीक्षण

प्रत्येक स्थापित मॉड्यूल के लिए पूर्ण परीक्षण सूट चलाएँ। आगे बढ़ने से पहले सभी विफलताओं को ठीक करें.

स्तर 2: कार्यात्मक परीक्षण

मुख्य व्यवसाय वर्कफ़्लो का शुरू से अंत तक परीक्षण करें:

• एक कोटेशन बनाएं, उसकी पुष्टि करें, सामान वितरित करें, एक चालान बनाएं, भुगतान दर्ज करें
• रसीद और विक्रेता बिल के माध्यम से खरीद आदेश की प्रक्रिया करें
• बीओएम से तैयार उत्पाद तक विनिर्माण ऑर्डर चलाएं
• एक पूर्ण बैंक समाधान चक्र पूरा करें
• प्रमुख वित्तीय रिपोर्ट तैयार करें और सत्यापित करें

स्तर 3: उपयोगकर्ता स्वीकृति परीक्षण (यूएटी)

प्रत्येक विभाग के वास्तविक उपयोगकर्ताओं को 5-10 व्यावसायिक दिनों के लिए स्टेजिंग वातावरण में अपने दैनिक कार्य करने दें। साझा स्प्रेडशीट या प्रोजेक्ट प्रबंधन टूल में मुद्दों को ट्रैक करें।

स्तर 4: प्रदर्शन परीक्षण

उत्पादन-स्तर डेटा वॉल्यूम के साथ पृष्ठ लोड समय, रिपोर्ट निर्माण गति और v17 और v18 के बीच खोज प्रदर्शन की तुलना करें।

गो-लाइव रणनीति

अनुशंसित दृष्टिकोण: सप्ताहांत प्रवास

1. शुक्रवार शाम: अंतिम उत्पादन बैकअप लें। सभी लेनदेन रोकें.
2. शनिवार: उत्पादन डेटाबेस पर अपग्रेड चलाएँ। किसी भी अंतिम मिनट के डेटा को पोर्ट करें।
3. रविवार: पूर्ण डेटा सत्यापन और धुआं परीक्षण। उत्पादन सर्वर पर तैनात करें.
4. सोमवार सुबह: लाइव हों। पहले 48 घंटों तक बारीकी से निगरानी करें।

रोलबैक योजना तैयार रखें: v17 डेटाबेस बैकअप और सर्वर कॉन्फ़िगरेशन उपलब्ध रखें ताकि गंभीर समस्याएं सामने आने पर आप कुछ घंटों के भीतर वापस लौट सकें।

अक्सर पूछे जाने वाले प्रश्न

प्रश्न: क्या मैं संस्करण छोड़ सकता हूं और ओडू 16 से सीधे ओडू 18 पर स्थानांतरित कर सकता हूं? हाँ, लेकिन यह अधिक जटिल है। प्रत्येक संस्करण की अपनी माइग्रेशन स्क्रिप्ट होती है, और संस्करणों को छोड़ने से परिवर्तन बढ़ जाते हैं। ओडू की अपग्रेड सेवा बहु-संस्करण जंप को संभालती है, लेकिन कस्टम मॉड्यूल पोर्टिंग के लिए प्रत्येक छोड़े गए संस्करण से ब्रेकिंग परिवर्तनों को संबोधित करने की आवश्यकता होती है। बहु-संस्करण प्रवासन के लिए 50-100% अधिक समय का बजट।

प्रश्न: क्या माइग्रेशन के दौरान मेरी कस्टम रिपोर्ट टूट जाएंगी? संभावित रूप से. अद्यतन डेटा संरचनाओं और रेंडरिंग इंजन सुधारों के कारण QWeb रिपोर्ट टेम्प्लेट अक्सर संस्करणों के बीच बदलते रहते हैं। माइग्रेशन के बाद प्रत्येक मुद्रित रिपोर्ट (चालान, डिलीवरी स्लिप, खरीद ऑर्डर) का परीक्षण करें और आवश्यकतानुसार टेम्पलेट समायोजित करें।

प्रश्न: क्या मुझे पलायन करना चाहिए या नई शुरुआत करनी चाहिए? यदि आपके पास वर्षों का ऐतिहासिक डेटा, जटिल कॉन्फ़िगरेशन और प्रशिक्षित उपयोगकर्ता हैं तो माइग्रेट करें। यदि आपका वर्तमान इंस्टॉलेशन मरम्मत से परे अत्यधिक अनुकूलित है, इसमें महत्वपूर्ण डेटा गुणवत्ता समस्याएं हैं, या यदि आपकी व्यावसायिक प्रक्रियाएं इतनी बदल गई हैं कि पुनर्संरचना तेज हो जाएगी, तो नए सिरे से शुरुआत करें। अधिकांश व्यवसाय अपने परिचालन इतिहास को संरक्षित करने के लिए माइग्रेशन चुनते हैं। यह मूल्यांकन करने के लिए कि कौन सा दृष्टिकोण आपकी स्थिति के लिए उपयुक्त है, एक ओडू कंसल्टेंसी पार्टनर से परामर्श लें।

व्यावसायिक प्रवासन सहायता

ओडू संस्करणों के बीच माइग्रेट करना एक तकनीकी परियोजना है जो अनुभवी हाथों से लाभान्वित होती है। ECOSIRE की Odoo माइग्रेशन सेवाएं पूरी प्रक्रिया को कवर करती हैं: प्री-माइग्रेशन ऑडिट, कस्टम मॉड्यूल पोर्टिंग, डेटा माइग्रेशन, परीक्षण और गो-लाइव समर्थन।

हमारी टीम से संपर्क करें आपके विशिष्ट ओडू इंस्टॉलेशन के आधार पर माइग्रेशन मूल्यांकन और समयरेखा अनुमान के लिए। हम सटीक दायरा और बजट प्रदान करने के लिए आपके मॉड्यूल, अनुकूलन और डेटा जटिलता का विश्लेषण करेंगे।