تعریف نقش تکنسین در ServiceDesk Plus؛ مجوزهای پایه و پیشرفته، محدوده مشاهده، تفاوت نقش دسترسی با مسئول تأیید و آزمون مجوزهای واقعی حساب.

شرکت مدانت

راهنمای فارسی ServiceDesk Plusکاربران و دسترسی‌ها ← نقش‌ها

موضوع مرجع: Roles | نسخه داخلی On-Premises

برای تعریف دسترسی، دو پرسش را جدا پاسخ دهید: کارشناس چه عملی انجام می‌دهد و روی کدام اطلاعات؟ در این مدخل، تنظیم مجوز را از تعیین مسئول تأیید تفکیک می‌کنیم. مشخصات محل خدمت نیز در راهنمای سایت‌ها توضیح داده شده است.

ایجاد و نگهداری نقش

در Admin، عبارت Roles را جست‌وجو کنید. با Add New Role نام یکتا و توضیح را وارد کنید؛ مجوزها و محدوده مشاهده را تعیین و ذخیره کنید. آیکون ویرایش برای اصلاح نقش و گزینه نمایش تکنسین‌های مرتبط برای مشاهده استفاده‌کنندگان آن است. نقش‌های سیستمی حذف‌پذیر نیستند؛ پیش از حذف نقش سفارشی، اعضای مرتبط را بررسی کنید. [۱]

مجوز پایه و مجوز پیشرفته

View مشاهده، Add ایجاد، Edit ویرایش و Delete حذف است. Complete Access همه این‌ها را فعال می‌کند. در Advanced Permissions، عملیات جزئی‌تر، مانند بستن درخواست یا تغییر موعد، کنترل می‌شوند. فعال‌بودن مشاهده ماژول نیز لازم است. [۱]

محدوده مشاهده

در Technicians allowed to view، گزینه‌های All برای همه سایت‌ها، All in associated Site برای سایت‌های مرتبط، All in Group & assigned to him برای گروه و موارد تخصیص‌یافته و Assigned to him برای موارد تخصیص‌یافته وجود دارند. دو گزینه آخر در مستند برای درخواست، مشکل و تغییر ذکر شده‌اند؛ آن‌ها را محدودیت یکسان همه دارایی‌ها ندانید. [۱]

نقش دسترسی با نقش سازمانی یکی نیست

Organization Roles برای معرفی مسئولان در سطح سازمان، منطقه، سایت یا دپارتمان و استفاده در تأیید درخواست خدمت است. انتخاب یک فرد به‌عنوان مدیر واحد، همان ساخت مجوز مدیریتی برای حساب او نیست. مسئولیت سازمانی و تنظیم دسترسی را در دو تصمیم جدا ثبت کنید. [۲]

Group Roles نیز مسئولیت وابسته به گروه پشتیبانی است؛ مثلاً نقشی که در ارجاع اعلان یا تأیید به کار می‌رود. برای هر گروه، یک تکنسین به یک نقش گروهی نسبت داده می‌شود؛ همان نقش می‌تواند در گروه‌های دیگر افراد متفاوتی داشته باشد. این سازوکار را با جدول مجوزهای Roles جایگزین نکنید. [۳]

یادداشت مدانت: آزمون دسترسی واقعی

برای هر نقش، یک جمله روشن بنویسید؛ مثلاً «رسیدگی به درخواست‌های تیم خود، بدون اختیار حذف». سپس حساب آزمایشی را با همین نیاز بسنجید. انتظار شما باید پیش از آزمون ثبت شده باشد؛ دیدن یک دکمه، به‌تنهایی دلیل کافی برای مناسب‌بودن کل نقش نیست.

یک درخواست داخل محدوده و یک درخواست آزمایشی خارج از محدوده آماده کنید. با نشست جداگانه، مشاهده، پاسخ‌گویی و عملیات لازم را امتحان کنید. برای مورد دوم، هم فهرست و هم نشانی مستقیم را بررسی کنید. همه آزمایش‌ها روی اطلاعات غیرحساس انجام شوند؛ برای آزمودن محدودیت، نیازی به بازکردن پرونده واقعی واحد دیگر نیست.

وقتی چند نقش روی حساب وجود دارد، نتیجه ترکیب آن‌ها را از نام نقش‌ها حدس نزنید. فهرست نقش‌های حساب، سایت‌های مرتبط و شرایط دسترسی به درخواست را ثبت کنید و همان وضعیت را آزمایش کنید. اضافه‌کردن ادمین برای رفع موقت یک خطا، آزمون نقش محدود را معتبر نمی‌کند.

پس از تغییر نقش، یک نفر غیر از تنظیم‌کننده نتیجه را بررسی کند. در صورت اختلاف، نام عملیات، شناسه درخواست آزمایشی و پیام خطا را ثبت کنید؛ نه رمز یا کلید حساب. روش آماده‌کردن حساب آزمون در راهنمای مدیریت تکنسین‌ها آمده است. برای دسته‌بندی مخاطبان محتوا نیز از گروه‌های کاربری استفاده کنید، نه از نام نقش به‌عنوان جایگزین گروه.

مطالب مرتبط

مدیریت تکنسین‌ها | گروه‌های پشتیبانی | گروه‌های کاربری | ورود کاربران از Active Directory | فهرست کاربران و دسترسی‌ها

سخن پایانی مدانت

دسترسی درست نه مانع کار است و نه مجوز دخالت در همه‌چیز. مرز مسئولیت را روشن کنید و همان مرز را در عمل بیازمایید؛ امنیت سامانه از اختیارهایی شروع می‌شود که دلیل روشنی برای واگذاری‌شان داریم.

منابع

  1. ManageEngine — Roles؛ ایجاد نقش، مجوزها و دامنه مشاهده.
  2. ManageEngine — Organization Roles؛ مسئولیت‌های سازمانی و تأیید درخواست خدمت.
  3. ManageEngine — Group Roles؛ مسئولیت‌های وابسته به گروه پشتیبانی.

نگارش فارسی بر پایه اطلاعات فنی منابع؛ روش آزمون و سخن پایانی، افزوده مدانت‌اند. بازبینی منابع: ۱۸ سپتامبر ۲۰۲۶. نام و دسترس‌پذیری گزینه‌ها را با Build نصب‌شده تطبیق دهید.

11

دیدگاه شما

دیدگاه مرتبط و محترمانه بنویسید.