سطح دسترسی کارکنان در ووکامرس؛ چه زمانی نقش اختصاصی لازم است؟

انباردار برای آماده‌کردن سفارش به اطلاعات ارسال نیاز دارد؛ پشتیبان برای پاسخ‌گویی به وضعیت سفارش. هیچ‌کدام الزاماً نباید قیمت کالا، تنظیمات پرداخت یا همهٔ اطلاعات مشتریان را تغییر دهند. پیش از دادن نقش «مدیر فروشگاه»، وظیفه، دادهٔ لازم و عملیات مجاز هر نفر را مشخص کنید؛ بعد ببینید نقش موجود، افزونهٔ آماده یا توسعهٔ اختصاصی کدام‌یک این مرزها را رعایت می‌کند.

نویسنده: سجاد · انتشار: ۲۰۲۶/۱۰/۰۱

نقش مدیر فروشگاه چه دسترسی‌هایی دارد؟

طبق مستندات رسمی، ووکامرس نقش‌های «مشتری» و «مدیر فروشگاه» را اضافه می‌کند و قابلیت‌های مدیریت فروشگاه را به مدیرکل وردپرس می‌دهد. مدیر فروشگاه دسترسی گسترده‌ای به محصولات، سفارش‌ها، بازپرداخت، کوپن‌ها، گزارش‌ها، مشتریان و تنظیمات ووکامرس دارد؛ همچنین برخی قابلیت‌های ویرایش محتوای وردپرس را دریافت می‌کند. بنابراین این نقش ممکن است برای کارمند دارای وظیفهٔ محدود، بیش از نیاز باشد.

نقش‌هایی با نام «انباردار» یا «اپراتور پشتیبانی» را نباید در هر نصب ووکامرس موجود فرض کرد؛ ممکن است افزونه‌ای آن‌ها را ایجاد کرده باشد. افزونه‌ها و تغییرهای قبلی نیز می‌توانند مجوزهای نقش‌های موجود را عوض کنند. ملاک تصمیم، دسترسی واقعی کاربر در نصب شماست.

دیدن اطلاعات، تغییر آن‌ها و تأیید عملیات را جدا کنید

برای هر وظیفه سه سؤال بنویسید: کاربر چه چیزی را می‌بیند، چه چیزی را تغییر می‌دهد و کدام اقدام نیاز به تأیید فرد دیگری دارد؟ «دسترسی به سفارش» عبارت دقیقی نیست؛ ممکن است فقط مشاهدهٔ اقلام لازم باشد یا اجازهٔ تغییر وضعیت، لغو، خروجی‌گرفتن و بازپرداخت هم لازم شود. هرکدام باید مستقل بررسی شود.

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

مخفی‌کردن منو چرا کافی نیست؟

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

در وردپرس، نقش مجموعه‌ای از قابلیت‌هاست. توسعه‌دهنده باید در مسیرهای حساس، قابلیت لازم را با سازوکاری مانند current_user_can() بررسی کند؛ در REST API اختصاصی نیز بررسی مجوز در permission_callback تعریف می‌شود. مجازبودن یک نوع عملیات باید با مجازبودن دسترسی به سفارش یا انبار مشخص هم تطبیق داده شود.

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

افزونهٔ آماده مناسب است یا توسعهٔ اختصاصی؟

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

تصمیم را با نمونهٔ واقعی کار روزانه بگیرید. برای مقایسهٔ هزینهٔ نگهداری، وابستگی‌ها و مسیر خروج، راهنمای انتخاب افزونهٔ آماده یا اختصاصی را ببینید. نقش اختصاصی الزاماً به معنی ساخت یک سامانهٔ کامل از ابتدا نیست.

یک مثال فرضی: اپراتور ارسال در دو انبار

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

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

چک‌لیست آزمون پیش از تحویل دسترسی کارکنان

1. برای هر نقش، حساب آزمایشی جدا بسازید و با همان حساب وارد شوید؛ آزمون با حساب مدیرکل نتیجهٔ مناسبی برای نقش محدود نمی‌دهد.
2. کار مجاز را از ابتدا تا پایان اجرا کنید؛ محدودیت نباید انجام وظیفهٔ اصلی را ناممکن کند.
3. آدرس مستقیم صفحهٔ ممنوع و درخواست عملیات ممنوع را هم امتحان کنید؛ نتیجه باید رد دسترسی باشد و تغییری در داده ایجاد نشود.
4. در مثال دو انبار، شناسهٔ سفارش انبار دیگر را بررسی کنید؛ فهرست محدود کافی نیست اگر جزئیات آن سفارش قابل دریافت باشد.
5. جست‌وجو، چاپ، خروجی فایل و مسیرهای API مورد استفاده را کنترل کنید؛ دادهٔ خارج از محدوده نباید از این مسیرها نمایش داده شود.
6. پس از تغییر نقش یا پایان همکاری، دسترسی حساب و اعتبارنامه‌های مرتبط را دوباره بررسی کنید؛ اگر کلید API جداگانه وجود دارد، وضعیت آن را مستقل کنترل کنید.
7. بعد از به‌روزرسانی افزونه‌های مؤثر، آزمون‌های مجاز و ممنوع را تکرار و نتیجه را ثبت کنید.

این چک‌لیست پیشنهاد آزمون پذیرش است و تضمین امنیت کامل نیست. نسخهٔ وردپرس، ووکامرس، روش ذخیرهٔ سفارش‌ها و افزونه‌های دخیل را همراه نتیجهٔ آزمون ثبت کنید؛ برای بخش‌های وابسته به سفارش، راهنمای سازگاری افزونهٔ ووکامرس هم مفید است.

برای سفارش قابلیت اختصاصی چه اطلاعاتی بفرستید؟

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

آزمون‌های بالا را به معیارهای تحویل افزونه اضافه کنید و مسئول بازبینی نقش‌ها پس از تغییر تیم یا به‌روزرسانی را در برنامهٔ نگهداری مشخص کنید. هر نفر حساب مستقل داشته باشد تا واگذاری و قطع دسترسی قابل پیگیری باشد.

منابع و تاریخ بازبینی

منابع رسمی زیر در ۲۰۲۶/۱۰/۰۱ بررسی شدند. توضیح نقش‌های پیش‌فرض و سازوکار مجوزها از این منابع است؛ جدول وظایف، مثال دو انبار و آزمون‌های پذیرش، پیشنهادهای عملی این مقاله‌اند.

• نقش‌ها و قابلیت‌های پیش‌فرض ووکامرس
• نقش‌ها و قابلیت‌ها در راهنمای افزونهٔ وردپرس
• بررسی قابلیت کاربر در سمت سرور
• تعریف مسیر REST API و بررسی مجوز

وظایف و دسترسی‌های مورد نیاز را بفرستید خدمت ساخت افزونه اختصاصی ←