تعیین خودکار تاییدکننده در JSM جیرا از مدیر مستقیم Active Directory
در هر فرایند تاییدی که ساختهام، یک الگو تکرار شده: اول از کاربر میخواهند تاییدکنندهاش را خودش انتخاب کند. سه ماه بعد میفهمند نصف درخواستها به آدم اشتباه رفته — یا به کسی که مرخصی است، یا به کسی که اصلاً اختیار تایید ندارد، یا به همکاری که «سریعتر تایید میکند».
راهحل واضح است: تاییدکننده باید مدیر مستقیم درخواستدهنده باشد و خودکار تعیین شود. اگر سازمان شما Active Directory دارد، این اطلاعات از قبل آنجاست — فیلد manager روی هر کاربر.
سه راه، به ترتیب هزینه
| روش | پیشنیاز | محدودیت |
|---|---|---|
| افزونهٔ مارکتپلیس | بودجه و دسترسی به مارکتپلیس | لایسنس سالانه، وابستگی به فروشنده |
| Automation داخلی Jira | ساختار ساده | به AD دسترسی ندارد |
| Listener با ScriptRunner | ScriptRunner + دسترسی خواندن AD | کد شما، نگهداری با شما |
گزینهٔ دوم برای وقتی خوب است که ساختار تایید ساده و ثابت باشد — مثلاً «همیشه مدیر تیم پشتیبانی». ولی Automation داخلی به AD دسترسی ندارد، پس برای مدیر مستقیم واقعی جواب نمیدهد.
گزینهٔ سوم انعطاف کامل میدهد و هزینهاش این است که کدش مال شماست و بعد از هر ارتقا باید تستش کنید.
منطق کار
یک Listener روی رویداد ساخت Issue در پروژهٔ مشخص، این پنج قدم را برمیدارد:
- درخواستدهنده (Reporter) را بگیر
- با AD یا LDAP تماس بگیر و فیلد
managerاو را بخوان - مقدار برگشتی — که معمولاً یک DN است — را به یک کاربر Jira تبدیل کن
- آن کاربر را در فیلد Approvers بگذار
- اگر هر مرحله شکست خورد، مسیر جایگزین را اجرا کن
مرحلهٔ ۳ همانجایی است که کار میشکند
AD معمولاً مدیر را به شکل Distinguished Name برمیگرداند:
CN=Ali Rezaei,OU=Managers,OU=Users,DC=example,DC=localاین رشته یک کاربر Jira نیست. باید به یوزرنیم یا ایمیل تبدیلش کنید و بعد کاربر Jira متناظر را پیدا کنید. اینجا سه چیز میتواند خراب شود:
- آن مدیر اصلاً کاربر Jira نیست. خیلی از مدیران ارشد حساب Jira ندارند.
- حساب دارد ولی غیرفعال است. کسی که از شرکت رفته، در AD ممکن است هنوز بهعنوان مدیر ثبت باشد.
- ایمیل AD با ایمیل Jira یکی نیست. یکی
a.rezaei@و دیگریali.rezaei@.
برای هر سه باید تصمیم داشته باشید — و تصمیمش کد نیست، سیاست سازمانی است.
پرسشهایی که باید قبل از کدنویسی جواب بدهید
این بخش مهمترین قسمت این نوشته است. اگر اینها را از قبل نپرسید، اسکریپتتان نصفهکاره تحویل داده میشود و بعداً هر هفته یک استثنا رویش سوار میشود.
- اگر مدیر پیدا نشد چه؟ درخواست بدون تاییدکننده بماند، یا به یک گروه پشتیبان برود؟ (پیشنهاد من: گروه پشتیبان — درخواست بیصاحب بدترین حالت است)
- اگر مدیر مرخصی باشد چه؟ Jira از مرخصی خبر ندارد. یا تاییدکنندهٔ دوم بگذارید یا مکانیزم تشدید بعد از N روز.
- اگر درخواستدهنده خودش مدیر باشد چه؟ کسی نباید تاییدکنندهٔ خودش باشد. باید یک سطح بالاتر برود.
- اگر بعداً Reporter عوض شد چه؟ تاییدکننده باید دوباره محاسبه شود یا همان بماند؟
- مدیرعامل چه؟ او مدیر ندارد. این حالت باید صریح مدیریت شود وگرنه اسکریپت خطا میدهد.
هر کدام از این پنج سؤال که بیجواب بماند، بعداً به شکل یک درخواست گیرکرده در صف تایید برمیگردد — و کسی نمیفهمد چرا.
نکات امنیتی
- برای خواندن AD از یک حساب سرویس با دسترسی فقطخواندنی استفاده کنید، نه حساب ادمین.
- اعتبارنامه را در متن اسکریپت ننویسید. اسکریپتهای ScriptRunner در بکاپها بهصورت متن ساده ذخیره میشوند.
- اتصال LDAP باید رمزنگاریشده باشد. LDAP ساده روی شبکه یعنی اعتبارنامه در ترافیک.
- فیلد Approvers را قفل کنید. اگر کاربر بتواند بعد از ساختهشدن، تاییدکننده را دستی عوض کند، کل زحمت خودکارسازی بیاثر میشود.
تست: هفت حالتی که باید امتحان شوند
۱. کاربر عادی با مدیر معتبر → مسیر خوشبینانه
۲. کاربری که در AD مدیر ندارد → مسیر جایگزین
۳. مدیری که کاربر Jira نیست → مسیر جایگزین
۴. مدیری که حسابش غیرفعال است → مسیر جایگزین
۵. درخواستدهنده = مدیر → یک سطح بالاتر
۶. AD در دسترس نیست → نباید ساخت Issue را بشکند
۷. تغییر Reporter بعد از ساخت → رفتار تعریفشدهحالت ششم را جدا کنید و حتماً تست کنید: اگر AD پاسخ ندهد، اسکریپت شما نباید جلوی ساختهشدن Issue را بگیرد. کاربر باید بتواند درخواستش را ثبت کند حتی اگر تاییدکننده بعداً دستی تعیین شود.
همهٔ این هفت حالت را روی محیط تست امتحان کنید، نه عملیاتی. اگر محیط تست ندارید، راهاندازی Jira روی Docker در یک بعدازظهر یکی برایتان میسازد.
جمعبندی
تعیین خودکار تاییدکننده از AD یکی از پرسودترین اتوماسیونهایی است که میشود در JSM پیاده کرد: هم خطای انسانی را حذف میکند، هم فرایند را قابل ممیزی میکند.
ولی سختی کار در نوشتن کد نیست — در تصمیمگیری دربارهٔ حالتهای استثناست. آن پنج سؤال را قبل از شروع با صاحب فرایند حل کنید. الگوهای دیگر خودکارسازی را هم در قوانین Automation در Jira جمع کردهام. اگر هنوز JSM را راه نینداختهاید و میخواهید از اول درست ساخته شود، راهاندازی Jira Service Management همین کار است.
سؤالی دربارهٔ همین موضوع دارید؟
بپرسید. اگر جوابش کوتاه باشد همانجا میگویم و اگر نیاز به بررسی داشته باشد، میگویم چه چیزی لازم است.
پرسیدن در واتساپخواندن بعدی
طراحی Workflow در جیرا: از وضعیتهای اضافه تا فرایندی که گزارش میدهد
طراحی Workflow در جیرا: چرا وضعیتهای اضافه گزارش را بیاعتبار میکنند، تفاوت status و statusCategory و resolution، و چهار ابزار روی هر Transition.
خواندنقوانین Automation در جیرا که بیشترین کار دستی را حذف میکنند
هشت قانون Automation در جیرا که واقعاً وقت آزاد میکنند، بههمراه سه اشتباهی که باعث میشود اتوماسیون به جای کمک، دردسر بسازد.
خواندن