सर्वर प्रशासन

ChurchApps में सर्वर प्रशासन सुविधाएँ केवल Server.Admin अनुमति वाले उपयोगकर्ताओं के लिए उपलब्ध हैं। ये उपकरण सिस्टम के सभी चर्चों में प्लेटफ़ॉर्म संचालन, सहायता और समस्या निवारण के लिए उपयोग होते हैं।

पहुँच प्रतिबंधित

इस पृष्ठ पर वर्णित सुविधाओं के लिए Server.Admin अनुमति आवश्यक है और ये सामान्य चर्च एडमिनिस्ट्रेटरों के लिए उपलब्ध नहीं हैं। ये केवल प्लेटफ़ॉर्म ऑपरेटरों और सहायता स्टाफ़ के लिए हैं।

सर्वर एडमिन तक पहुँचना

Server.Admin अनुमति वाले उपयोगकर्ता B1 Admin से सर्वर एडमिन पैनल तक पहुँच सकते हैं:

1. admin.b1.church में लॉग इन करें
2. Jump menu खोलें, Settings का विस्तार करें, और Server Admin पर क्लिक करें। (आप सीधे admin.b1.church/admin पर भी जा सकते हैं।)
3. सर्वर एडमिन पैनल बाईं ओर तीन समूहों में अपने अनुभाग सूचीबद्ध करता है: Directory (Churches, Users, Impersonate User), Operations (Background Jobs, Commons, Usage Trends), और System (Translation Lookups, Server Health, Database Migrations)

दो-चरणीय साइन-इन रीसेट करना

यदि किसी उपयोगकर्ता ने दो-चरणीय साइन-इन चालू किया है और उसका फ़ोन और backup codes दोनों खो गए हैं, तो एक server admin इसे बंद कर सकता है:

1. सर्वर एडमिन पैनल का Users अनुभाग खोलें और उपयोगकर्ता को खोजें।
2. दो-चरणीय साइन-इन वाले उपयोगकर्ताओं पर Two-factor on बैज दिखता है। उसके बगल में Reset 2FA पर क्लिक करें।
3. प्रॉम्प्ट की पुष्टि करें। ऐसा केवल तब करें जब आपने पुष्टि कर ली हो कि आप किससे बात कर रहे हैं।

इसके बाद उपयोगकर्ता केवल अपने पासवर्ड से लॉग इन कर सकता है और अपनी प्रोफ़ाइल से दो-चरणीय साइन-इन फिर सेट कर सकता है। रीसेट mfa_reset के रूप में ऑडिट लॉग में दर्ज होते हैं। endpoint POST /membership/users/mfa/reset/:userId है और इसके लिए Server.Admin आवश्यक है।

उपयोगकर्ता प्रतिरूपण (Impersonation)

प्रतिरूपण सुविधा server admins को सहायता और समस्या निवारण के उद्देश्य से किसी अन्य उपयोगकर्ता के रूप में लॉग इन करने देती है। उपयोगकर्ता द्वारा रिपोर्ट की गई समस्याओं की जाँच करते समय या चर्चों को उनके सिस्टम कॉन्फ़िगर करने में मदद करते समय यह उपयोगी है।

उपयोगकर्ता का प्रतिरूपण कैसे करें

1. सर्वर एडमिन पैनल का Impersonate User अनुभाग खोलें
2. खोज फ़ील्ड में उपयोगकर्ता का नाम या ईमेल पता दर्ज करें
3. Search पर क्लिक करें या Enter दबाएँ
4. खोज परिणामों में से वह उपयोगकर्ता चुनें जिसका आप प्रतिरूपण करना चाहते हैं
5. खुलने वाले डायलॉग में प्रतिरूपण की पुष्टि करें
6. आप उस उपयोगकर्ता के रूप में लॉग इन होंगे और उनके खाते पर भेजे जाएँगे

महत्वपूर्ण नोट्स

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

API Endpoint

प्रतिरूपण सुविधा Membership API में /users/:userId/impersonate endpoint द्वारा समर्थित है। तकनीकी विवरण के लिए Membership Endpoints देखें।

सुरक्षा संबंधी विचार

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

Commons मॉडरेशन

Commons उत्पादों में उपयोगकर्ता-प्रस्तुत कंटेंट के लिए साझा मॉडरेशन कतार है -- WorshipCommons गीत, Lessons.church पाठ, FreeShow टेम्पलेट, और B1 वेबसाइट बिल्डर टेम्पलेट सभी एक ही कतार से गुज़रते हैं, अलग-अलग उत्पाद-विशिष्ट समीक्षा उपकरणों के बजाय।

Commons तक पहुँचना

1. सर्वर एडमिन पैनल में Commons टैब पर जाएँ।
2. आपको तीन उप-टैब दिखेंगे: Queue, Reports, और Assets।

एक सीमित music editor भूमिका भी Queue टैब देख सकती है, लेकिन उन प्रस्तुतियों को स्वीकृत करने से रोकी जाती है जो किसी गीत के अधिकार या लाइसेंसिंग बदलती हैं।

Queue

Queue सभी उत्पादों में हर लंबित प्रस्तुति सूचीबद्ध करती है, उत्पाद और एसेट प्रकार के अनुसार फ़िल्टर योग्य। हर पंक्ति दिखाती है कि प्रस्तुति नया एसेट है, उसके मूल लेखक द्वारा संपादन है, या किसी तृतीय पक्ष द्वारा संपादन, साथ में प्रस्तुतकर्ता का स्वीकृति रिकॉर्ड और प्रस्तुति कितनी देर से प्रतीक्षा कर रही है (72 घंटे पार होने पर चिह्नित)।

फ़ील्ड-स्तर के अंतर, फ़ाइल पूर्वावलोकन, और आइटम के एम्बेडेड केवल-पढ़ने योग्य पूर्वावलोकन के साथ एक ड्रॉअर खोलने के लिए Review पर क्लिक करें। स्वीकृत या अस्वीकृत करने के लिए a/r कीबोर्ड शॉर्टकट, और ड्रॉअर छोड़े बिना अगली या पिछली प्रस्तुति पर जाने के लिए j/k का उपयोग करें। अस्वीकार करने के लिए एक कारण (जैसे quality, duplicate, licensing, ccli, ai, या off-topic) और एक नोट चुनना आवश्यक है।

Reports

Reports टैब उन प्रकाशित एसेट्स के विरुद्ध दर्ज की गई कॉपीराइट और नीति/गुणवत्ता रिपोर्टों को संभालता है, जो Copyright और Policy & Other कतारों में बँटी हैं, साथ में Resolved इतिहास। काम शुरू करने के लिए रिपोर्ट का दावा करें, फिर एक resolution (upheld, dismissed, या duplicate) और एक action (none, unpublish, या remove) के साथ उसे हल करें।

Assets

Assets टैब प्रकाशित कंटेंट का एक खोज योग्य ब्राउज़र है, जिसमें क्रियाएँ हैं: किसी एसेट को Feature करना (उसे उत्पाद के होम पेज पर उजागर करना), उसे Unpublish/Republish करना, या Remove करना (कॉपीराइट या नीति कारण के साथ)।

विशेष रूप से गीतों के लिए, यहीं एक गीत Sunday-ready बनता है और किसी चर्च के B1 Admin गीत खोज में दिखने योग्य होता है: एक समीक्षक एसेट खोलता है और हर प्रकाशित key को Listened चिह्नित करता है, जब वे उसे सुन लेते हैं और पुष्टि कर लेते हैं कि स्कोर, कॉर्ड और स्लाइड सब मौजूद हैं। हर key चिह्नित होने पर ही गीत Sunday-ready बनता है।

जानकारी

Commons मॉडरेशन केवल स्टाफ़ के लिए है -- अलग-अलग चर्च कभी यह कतार नहीं देखते। वह एक जगह जहाँ किसी अलग चर्च का B1 Admin Commons डेटा छूता है वह गीत खोज का "WorshipCommons — free" अनुभाग है, जो केवल वे गीत दिखाता है जो पहले ही इस समीक्षा प्रक्रिया से गुज़र चुके हैं।

अंतर्निहित डेटा मॉडल और प्रस्तुति जीवनचक्र के लिए Content Commons architecture पृष्ठ देखें।

Group Email स्वीकृति

चर्च तब तक चर्च-लिखित ईमेल (group email, form follow-ups, workflow ईमेल, और खाता निमंत्रण) नहीं भेज सकते जब तक कोई server admin उन्हें स्वीकृत न करे। इससे बॉट द्वारा पंजीकृत चर्च साझा ChurchApps भेजने वाले पते का स्पैम के लिए उपयोग नहीं कर पाते।

1. सर्वर एडमिन पैनल में Churches टैब खोलें।
2. हर चर्च पर एक Group Email चिप दिखती है: Approved (हरा) या Not approved (रूपरेखा वाला)।
3. चर्च को स्वीकृत करने, या किसी स्वीकृति को रद्द करने के लिए चिप पर क्लिक करें और पुष्टि करें।

चर्च स्टाफ़ B1 Admin के Send Email डायलॉग में Request review बटन से स्वीकृति माँगते हैं। अनुरोध सहायता पते पर ईमेल होता है और चर्च का नाम, ID, पंजीकरण तारीख, स्थान, और किसने माँगा, सूचीबद्ध करता है। एक चर्च हर सप्ताह एक अनुरोध भेज सकता है। दैनिक भत्ते और bounces और शिकायतों पर स्वचालित रोक के लिए Church-authored email limits देखें।

डेटाबेस माइग्रेशन

Deploy Prod workflow लंबित माइग्रेशन स्वयं लागू करता है। होस्टेड डेटाबेस केवल Api के नेटवर्क के भीतर से कनेक्शन स्वीकार करते हैं, इसलिए GitHub runner उन तक नहीं पहुँच सकता; इसके बजाय serverless deploy के ठीक बाद workflow Api का migrate Lambda (api-Prod-migrate) चलाता है, जो हर मॉड्यूल के लंबित माइग्रेशन इस tab के समान runner से चलाता है और यदि कोई मॉड्यूल त्रुटि करे या मना किया जाए तो डिप्लॉय विफल कर देता है। Rollback Prod केवल Lambda कोड को वापस करता है; लागू किए गए माइग्रेशन लागू ही रहते हैं। Database Migrations टैब स्थिति जाँचने, वह चलाने के लिए जो डिप्लॉय ने नहीं चलाया (जैसे demo वातावरण पर, जिसका डिप्लॉय माइग्रेट नहीं करता), और बिना इतिहास वाले मॉड्यूलों को baseline करने के लिए है। (स्व-होस्टेड Docker इंस्टॉल अब भी Api कंटेनर शुरू होने पर माइग्रेशन स्वचालित रूप से चलाते हैं।)

टैब वर्तमान वातावरण और हर मॉड्यूल (membership, attendance, giving, आदि) के लिए एक पंक्ति दिखाता है, उसकी स्थिति, लागू और लंबित माइग्रेशन की संख्या, और अंतिम लागू माइग्रेशन के साथ।

• Run Pending Migrations हर लंबित माइग्रेशन लागू करता है, एक समय में एक मॉड्यूल, क्रम से। पहली विफलता पर रुकता है और हर मॉड्यूल के लिए क्या लागू हुआ यह दिखाता है।
• No history चिह्नित मॉड्यूल का डेटाबेस माइग्रेशन ट्रैकिंग से पहले का है। उसे स्वचालित रूप से कभी नहीं चलाया जाता, क्योंकि इससे पुराने डेटा माइग्रेशन लाइव तालिकाओं पर फिर चल जाते। इसके बजाय उस मॉड्यूल पर Check Schema पर क्लिक करें। Api हर माइग्रेशन द्वारा बनाई गई तालिकाओं, कॉलमों और indexes की तुलना लाइव डेटाबेस से करता है और हर माइग्रेशन को Already applied, Missing, Partly applied, या Data only चिह्नित करता है। जाँच कुछ नहीं बदलती।
• जाँच परिणामों में, Record as Already Applied पता लगाए गए माइग्रेशन को उन्हें चलाए बिना माइग्रेशन इतिहास में लिखता है (पुष्टि के बाद)। आखिरी Already applied माइग्रेशन तक सब कुछ दर्ज होता है, उस सीमा के Data only वाले सहित; Missing वाले लंबित रहते हैं और फिर Run Pending Migrations से सामान्य रूप से चलाए जा सकते हैं।
• Partly applied माइग्रेशन दर्ज करने से रोका जाता है। यदि माइग्रेशन फिर से चलाना सुरक्षित है (पहले उसे पढ़ें), तो Re-run टिक करें ताकि वह लंबित रहे और ऊपर से फिर चले।

सर्वर एडमिन पैनल और CLI (yarn migrate:up) एक ही Kysely migrator और kysely_migration तालिका उपयोग करते हैं, इसलिए वे हमेशा इस पर सहमत रहते हैं कि क्या लागू हुआ है। सहायक endpoints हैं GET /membership/serverHealth/migrations, POST /membership/serverHealth/migrations/:module/run, GET .../:module/detect, और POST .../:module/baseline, सभी केवल Server.Admin के लिए।

संबंधित पृष्ठ

• Authentication & Permissions — अनुमति मॉडल और JWT प्रमाणीकरण
• Membership Endpoints — उपयोगकर्ता और चर्च प्रबंधन API
• Audit Log — किसी चर्च की गतिविधि लॉग देखें
• Content Commons Architecture — साझा एसेट मॉडल और मॉडरेशन जीवनचक्र