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

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

چرا نقش‌های پیش‌فرض وردپرس کافی نیستند؟

وردپرس شش نقش پیش‌فرض دارد که حول مدیریت محتوا ساخته شده‌اند. در یک پلتفرم کوچینگ، این نقش‌ها با شکاف‌های زیر روبه‌رو می‌شوند:

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

در کوچینگ، محرمانگی یک قابلیت نیست؛ پیش‌شرط اعتماد است.

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

نقش‌ها در پلتفرم کوچینگ

مراجع (Coachee)

دسترسی به جلسات شخصی، ثبت یادداشت شخصی، مشاهده فاکتور و برنامه، بدون دسترسی به مراجعان دیگر.

کوچ (Coach)

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

سرپرست کوچ (Coach Supervisor)

مشاهده یادداشت‌های کوچ‌های زیرمجموعه برای اهداف نظارتی، با رضایت صریح مراجع.

مدیر برنامه (Program Manager)

مدیریت تخصیص کوچ به مراجع، مدیریت جلسات، بدون دسترسی به محتوای جلسه.

مدیر کل (Platform Admin)

مدیریت کل پلتفرم، بدون دسترسی مستقیم به محتوای جلسات به‌دلیل محرمانگی.

چالش‌های رابطه کوچینگ

۱. محرمانگی مطلق

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

۲. رابطه دوتایی کوچ-مراجع

هر مراجع با یک کوچ مشخص کار می‌کند. دسترسی باید در سطح این رابطه دوتایی تعریف شود، نه فقط در سطح نقش. این نیازمند یک لایه Additional Capability است. برای مطالعه بیشتر، مطلب کار با User Meta در وردپرس را ببینید.

۳. زمان‌بندی جلسه

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

۴. تخصیص دینامیک کوچ

در پلتفرم‌های بزرگ، تخصیص کوچ به مراجع دینامیک است. اگر کوچ تغییر کند، دسترسی نیز باید منتقل شود. این نیازمند یک جدول واسط (Pivot Table) است. برای مطالعه بیشتر، مطلب فیلدهای سفارشی ACF را ببینید.

۵. داده پرداخت

داده‌های پرداخت مراجعان باید در لایه‌ای جدا از کوچ باشد. این جداسازی از منظر GDPR (General Data Protection Regulation) و قوانین داخلی ضروری است.

تنظیمات مربیگری هر نقش

نقش دسترسی جلسه یادداشت پرداخت
مراجع جلسات شخصی خودش خودش
کوچ مراجعان تخصیصی ثبت و ویرایش خیر
سرپرست زیرمجموعه مشاهده خیر
مدیر برنامه مدیریت تخصیص خیر مشاهده
مدیر کل مدیریت کل خیر مدیریت

پیاده‌سازی با PHP

ابتدا CPT جلسه کوچینگ را می‌سازیم. برای مطالعه بیشتر، مطلب پیاده‌سازی درست Custom Post Type را ببینید.

function wk_register_coaching_session_cpt() {
    register_post_type('wk_coaching_session', array(
        'label' => 'جلسات کوچینگ',
        'public' => false,
        'show_ui' => true,
        'capability_type' => 'wk_session',
        'capabilities' => array(
            'read_post' => 'read_wk_session',
            'edit_post' => 'edit_wk_session',
            'edit_posts' => 'edit_wk_sessions',
            'edit_others_posts' => 'edit_others_wk_sessions',
        ),
        'map_meta_cap' => true,
        'supports' => array('title', 'editor', 'author', 'custom-fields'),
    ));
}
add_action('init', 'wk_register_coaching_session_cpt');

سپس نقش‌های سفارشی را می‌سازیم. برای درک بهتر هوک‌ها، مطلب هوک‌های وردپرس را ببینید.

function wk_register_coaching_roles() {
    add_role('wk_coachee', 'مراجع', array(
        'read' => true,
        'edit_wk_sessions' => true,
        'publish_wk_sessions' => true,
        'read_own_invoices' => true,
    ));

    add_role('wk_coach', 'کوچ', array(
        'read' => true,
        'edit_wk_sessions' => true,
        'edit_others_wk_sessions' => true,
        'read_wk_coach_notes' => true,
        'edit_wk_coach_notes' => true,
        'schedule_wk_sessions' => true,
    ));

    add_role('wk_coach_supervisor', 'سرپرست کوچ', array(
        'read' => true,
        'read_wk_coach_notes' => true,
        'review_wk_sessions' => true,
    ));

    add_role('wk_program_manager', 'مدیر برنامه', array(
        'read' => true,
        'assign_wk_coaches' => true,
        'manage_wk_schedules' => true,
        'read_wk_invoices' => true,
    ));
}
add_action('init', 'wk_register_coaching_roles');

برای اعتبارسنجی و پاک‌سازی داده‌ها، مطلب اعتبارسنجی داده‌ها و پاک‌سازی داده‌ها را ببینید.

یادداشت جلسه و محرمانگی

یادداشت جلسه باید رمزنگاری‌شده ذخیره شود تا حتی مدیر سرور نتواند محتوای آن را ببیند:

function wk_save_session_notes($session_id, $coach_id, $notes) {
    if (!current_user_can('edit_wk_coach_notes')) {
        return new WP_Error('forbidden', 'دسترسی غیرمجاز');
    }
    $key = wk_get_coach_encryption_key($coach_id);
    $encrypted = openssl_encrypt($notes, 'aes-256-gcm', $key, 0, $iv = random_bytes(12));
    update_post_meta($session_id, 'wk_encrypted_notes', $encrypted);
    update_post_meta($session_id, 'wk_notes_iv', base64_encode($iv));
}

نکته کلیدی: کلید رمزنگاری هر کوچ باید در یک Vault جدا ذخیره شود. اگر کلید در دیتابیس وردپرس باشد، رمزنگاری بی‌معنا است. برای مطالعه بیشتر، مطلب کار با Options API را ببینید.

زمان‌بندی و تقویم جلسات

زمان‌بندی باید نقش‌محور و با کنترل تداخل باشد:

function wk_schedule_coaching_session($coach_id, $coachee_id, $datetime) {
    if (!current_user_can('schedule_wk_sessions')) {
        return new WP_Error('forbidden', 'دسترسی غیرمجاز');
    }
    if (!wk_is_assigned_coach($coach_id, $coachee_id)) {
        return new WP_Error('not_assigned', 'کوچ به این مراجع تخصیص نیافته');
    }
    $conflict = wk_check_schedule_conflict($coach_id, $datetime);
    if ($conflict) {
        return new WP_Error('conflict', 'تداخل زمانی با جلسه دیگر');
    }
    $session_id = wp_insert_post(array(
        'post_type' => 'wk_coaching_session',
        'post_status' => 'publish',
        'post_author' => $coach_id,
        'post_title' => sprintf('جلسه %s', $datetime),
    ));
    update_post_meta($session_id, 'wk_coachee_id', $coachee_id);
    update_post_meta($session_id, 'wk_scheduled_at', $datetime);
    return $session_id;
}

برای مطالعه بیشتر درباره کش و زمان‌بندی، مطلب ترنزینت وردپرس و کش هوشمند را ببینید.

امنیت و حریم خصوصی

سه لایه امنیتی ضروری است:

  1. رمزنگاری یادداشت‌های جلسه با کلید اختصاصی هر کوچ.
  2. ثبت لاگ هر دسترسی به یادداشت‌ها برای ممیزی.
  3. رضایت صریح مراجع برای هر دسترسی سرپرست.

برای مطالعه بیشتر درباره کدنویسی امن، مطلب نوشتن کد PHP امن برای وردپرس را ببینید. استاندارد GDPR چارچوب قانونی این حوزه را مشخص می‌کند.

پرسش‌های پرتکرار

آیا می‌توانم از نقش Author برای کوچ استفاده کنم؟

خیر. Author به همه پست‌های خودش دسترسی دارد، اما هیچ مکانیزمی برای تفکیک یادداشت جلسه از سایر محتوا وجود ندارد. باید نقش سفارشی با Capability اختصاصی بسازید.

چگونه محرمانگی یادداشت جلسه را تضمین کنم؟

با رمزنگاری AES-256 در سمت سرور و ذخیره کلید در Vault جداگانه. بدون این، حتی مدیر سرور می‌تواند محتوا را ببیند.

آیا سرپرست کوچ باید به یادداشت‌ها دسترسی داشته باشد؟

فقط با رضایت صریح مراجع و در بازه مشخص. این دسترسی باید لاگ شود و به مراجع قابل گزارش باشد.

چگونه داده پرداخت را از کوچ جدا کنم؟

با نگهداری داده پرداخت در یک Custom Post Type جداگانه و نقش اختصاصی. کوچ فقط به فاکتور خودش دسترسی داشته باشد، نه به فاکتور مراجع.

اشتباهات رایج

اشتباه پیامد راه‌حل
نقش یکسان برای همه کوچ‌ها نشت یادداشت بین کوچ‌ها نقش سفارشی با Capability اختصاصی
ذخیره یادداشت به‌صورت متن ساده نشت داده روان‌شناختی رمزنگاری با کلید اختصاصی
نبود لاگ دسترسی عدم امکان ممیزی ثبت هر دسترسی در جدول اختصاصی
دسترسی مدیر کل به محتوا نقض محرمانگی رمزنگاری + حذف Capability مستقیم
نبود رضایت مراجع برای سرپرست نقض GDPR و اخلاق فرم رضایت صریح و قابل لغو

تحلیل معماری پیشرفته

در سطح معماری سیستم، پلتفرم کوچینگ با یک چالش بنیادین روبه‌روست: مدل دسترسی وردپرس بر پایه «نقش» است، اما رابطه کوچینگ بر پایه «رابطه دوتایی» است. این یعنی نیازمند یک لایه ABAC (Attribute-Based Access Control) هستیم که فراتر از نقش، ویژگی‌های رابطه را نیز در نظر بگیرد.

رویکرد پیشنهادی، معماری «Relationship-Based Access Control» است. در این مدل، دسترسی بر اساس ترکیب (کاربر، نقش، مراجع، جلسه، زمان) تعیین می‌شود. این معماری، هم منعطف است و هم قابل ممیزی.

نکته دوم، بحث «Zero-Knowledge Storage» است. برای محرمانگی مطلق، باید یادداشت‌ها به‌گونه‌ای ذخیره شوند که حتی سرور نتواند آن‌ها را بخواند. این نیازمند رمزنگاری سمت کاربر با کلید مشتق‌شده از رمز عبور است.

نکته سوم، بحث «Consent Management» است. هر دسترسی سرپرست باید مبتنی بر رضایت صریح و قابل لغو مراجع باشد. این نیازمند یک سیستم مدیریت رضایت با تاریخچه کامل است.

اگر این چالش‌ها را در پروژه واقعی تجربه کرده‌اید، برای جالب است بدانید کدام بخش بیشترین زمان را گرفت: طراحی مدل دسترسی، رمزنگاری یادداشت، یا مدیریت رضایت. تجربه خود را در دیدگاه‌ها بنویسید.