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

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

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

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

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

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

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

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

نقش‌های ضروری در سایت مددکاری

مددجو (Beneficiary)

دسترسی به پرونده شخصی، مشاهده وضعیت درخواست، ثبت مدارک، بدون هیچ دسترسی به پرونده سایر مددجویان.

مددکار (Social Worker)

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

روانشناس همکار (Consulting Psychologist)

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

سرپرست مددکاری (Social Work Supervisor)

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

مدیر عملیات (Operations Manager)

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

چالش‌های داده اجتماعی

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

۱. داده هویتی و خانوادگی

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

۲. گردش کار چندنقشی

یک پرونده از چند مرحله عبور می‌کند: پذیرش، بررسی اولیه، تصویب، اجرا، پیگیری. هر مرحله نقش مسئول متفاوتی دارد. پیاده‌سازی این گردش کار نیازمند یک لایه State Machine است. برای مطالعه بیشتر، مطلب هوک‌های وردپرس مرور دقیقی از امکان‌های Custom Workflow ارائه می‌دهد.

۳. داده ارجاعی

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

۴. رضایت آگاهانه

هر دسترسی باید مبتنی بر رضایت آگاهانه مددجو باشد. رضایت باید قابل لغو و قابل ردیابی باشد. این نیازمند یک جدول Consent با تاریخچه کامل است.

۵. گزارش‌دهی قانونی

داده مددکاری مشمول گزارش‌دهی به سازمان‌های بالادستی است. اما گزارش باید تجمیعی و ناشناس باشد تا حریم خصوصی مددجو حفظ شود. استاندارد Social work در ویکی‌پدیا مرور خوبی از چارچوب حرفه‌ای این حوزه ارائه می‌دهد.

تنظیمات اجتماعی برای هر نقش

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

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

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

function wk_register_social_record_cpt() {
    register_post_type('wk_social_record', array(
        'label' => 'پرونده‌های مددکاری',
        'public' => false,
        'show_ui' => true,
        'capability_type' => 'wk_social_record',
        'capabilities' => array(
            'read_post' => 'read_wk_social_record',
            'edit_post' => 'edit_wk_social_record',
            'edit_posts' => 'edit_wk_social_records',
            'edit_others_posts' => 'edit_others_wk_social_records',
        ),
        'map_meta_cap' => true,
        'supports' => array('title', 'author', 'custom-fields'),
    ));
}
add_action('init', 'wk_register_social_record_cpt');

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

function wk_register_social_roles() {
    add_role('wk_beneficiary', 'مددجو', array(
        'read' => true,
        'read_own_social_record' => true,
        'upload_documents' => true,
    ));

    add_role('wk_social_worker', 'مددکار', array(
        'read' => true,
        'edit_wk_social_records' => true,
        'edit_others_wk_social_records' => true,
        'read_wk_case_notes' => true,
        'edit_wk_case_notes' => true,
        'refer_wk_cases' => true,
    ));

    add_role('wk_consulting_psychologist', 'روانشناس همکار', array(
        'read' => true,
        'read_referred_wk_records' => true,
        'write_wk_professional_opinion' => true,
    ));

    add_role('wk_social_supervisor', 'سرپرست مددکاری', array(
        'read' => true,
        'read_wk_case_notes' => true,
        'approve_wk_cases' => true,
    ));
}
add_action('init', 'wk_register_social_roles');

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

گردش کار پرونده مددکاری

یک پرونده مددکاری از چند مرحله عبور می‌کند. پیاده‌سازی این گردش کار با یک State Machine سبک انجام می‌شود:

function wk_transition_case_state($record_id, $new_state, $actor_id) {
    $allowed_transitions = array(
        'intake' => array('review', 'rejected'),
        'review' => array('approved', 'rejected'),
        'approved' => array('active'),
        'active' => array('followup', 'closed'),
        'followup' => array('closed'),
    );
    $current = get_post_meta($record_id, 'wk_case_state', true);
    if (!isset($allowed_transitions[$current]) ||
        !in_array($new_state, $allowed_transitions[$current], true)) {
        return new WP_Error('invalid_transition', 'انتقال وضعیت مجاز نیست');
    }
    update_post_meta($record_id, 'wk_case_state', $new_state);
    update_post_meta($record_id, 'wk_last_actor', $actor_id);
    update_post_meta($record_id, 'wk_state_changed_at', current_time('mysql'));
    return true;
}

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

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

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

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

برای امن‌سازی احراز هویت، مطلب تقویت احراز هویت در وردپرس را ببینید. برای دفع حملات Brute Force، مطلب دفع حملات Brute Force در وردپرس راهنمای عملی است. برای بررسی لاگ‌های دسترسی، مطلب بررسی لاگ حملات سایت را ببینید.

از منظر حقوقی، داده مددکاری مشمول سخت‌گیرانه‌ترین قوانین حفاظت از داده است. مطلب انطباق با GDPR در پروژه وردپرس مرور دقیقی از الزامات ارائه می‌دهد. همچنین مطلب GDPR و تأثیر آن بر وب‌سایت‌های ایرانی برای پروژه‌های داخلی مفید است.

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

پرسش‌های پرتکرار درباره تنظیمات نقش اجتماعی

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

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

چگونه گردش کار پرونده را پیاده‌سازی کنم؟

با یک State Machine سبک که وضعیت پرونده را در Post Meta نگهداری می‌کند و انتقال‌ها را اعتبارسنجی می‌کند.

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

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

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

با نگهداری داده پرداخت در CPT جداگانه و نقش اختصاصی. مددکار فقط به فاکتور خودش دسترسی داشته باشد، نه به داده پرداخت مددجو.

آیا می‌توانم گزارش تجمیعی بسازم بدون نشت داده هویتی؟

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

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

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

نگاه معماری در سطح سیستم‌های اجتماعی

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

رویکرد پیشنهادی، معماری «Multi-Party Access Control» است. هر پرونده یک Graph از ذی‌نفعان دارد که هرکدام سطح دسترسی متفاوتی دارند. این Graph در یک جدول جداگانه ذخیره می‌شود و توسط یک Policy Engine تفسیر می‌شود.

نکته دوم، بحث «Consent Propagation» است. اگر مددجو به سازمان A رضایت دسترسی داده، و سازمان A پرونده را به سازمان B ارجاع داده، رضایت اولیه باید به‌طور خودکار به ارجاع دوم منتقل نشود. هر ارجاع نیازمند رضایت جدید است. این نیازمند یک لایه مدیریت رضایت با دانه‌بندی دقیق است.

نکته سوم، بحث «Immutable Audit for Regulators» است. لاگ دسترسی باید به‌گونه‌ای باشد که در صورت بازرسی قانونی، قابل ارائه باشد، اما بدون افشای محتوای پرونده. این نیازمند یک معماری «Append-Only» است که فقط متادیتای دسترسی را ثبت می‌کند.

پیشنهادهای عملی برای پیاده‌سازی

سه توصیه عملی که در پروژه‌های واقعی مؤثر بوده‌اند:

  1. کلید رمزنگاری را در یک Vault جدا (مثل HashiCorp Vault) نگهداری کنید، نه در دیتابیس.
  2. هر انتقال وضعیت پرونده را در یک لاگ تغییرناپذیر ثبت کنید تا در صورت بازرسی، قابل ارائه باشد.
  3. یک Endpoint عمومی برای تأیید رضایت طراحی کنید تا مددجو هر زمان بتواند وضعیت دسترسی‌ها را ببیند.

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