كيف تدير الأدوار والصلاحيات

أضفت متعاقدًا إلى مساحة عملك الأسبوع الماضي. احتاج إلى مشروع واحد، إعادة التصميم التي تنفّذها لعميل. اليوم تلاحظ أنه يقدر على فتح كل مشروع في مساحة العمل، بما فيه خارطة الطريق الداخلية التي أردت إبقاءها خاصة. لا شيء تعطّل. لا خلل. اخترت الدور الخاطئ حين دعوته، وفي Taskfolk يقرّر ذلك الاختيار الواحد وقت الدعوة ما يمكن أن يلمسه الشخص وما لا يمكنه.

تلك مشكلة أدوار وصلاحيات إدارة المشاريع، وتستحق أن تُضبط بشكل صحيح قبل أن ترسل دعوةً واحدة. يغطي هذا الدليل الأدوار الخمسة كلها التي يمنحك Taskfolk إياها، وكيف تدعو الناس بالوصول الصحيح من البداية، وكيف تغيّر دورًا أو تسلّم الملكية لاحقًا، وكيف تُبقي المشاريع محدّدة النطاق المتعاونين الخارجيين خارج العمل الذي لا تريدهم فيه. صفحة الأشخاص هي حيث يعيش كل هذا، فمنها نبدأ.

لماذا تهمّ أدوار وصلاحيات إدارة المشاريع قبل أن تدعو أحدًا

ضبط الوصول بشكل صحيح أسهل من التراجع عنه. حالما يقرأ متعاقد مشروعك الداخلي أسبوعًا، «إلغاء رؤيته» ليس شيئًا ممكنًا. خارطة الطريق الخاصة التي تصفّحها، وأحاديث الأسعار في التعليقات، والأفكار نصف المنجزة في الباكلوج، كل ذلك صار في رأسه أصلًا. اللحظة التي تحمي عملك فعلًا هي الدعوة، لا التنظيف بعدها.

يعالج Taskfolk هذا بالأدوار. كل شخص في مساحة عمل يحمل دورًا واحدًا بالضبط على مستوى مساحة العمل، ويجيب ذلك الدور عن سؤال واحد: ما المسموح لهذا الشخص فعله هنا. هل يقدر على حذف مشروع؟ تحرير مهمة شخص آخر؟ القراءة فقط، بلا لمس أبدًا؟ أم أنه غريب يجب أن يرى مشروعًا واحدًا ولا شيء سواه؟

الدور يقرّر، على مستوى مساحة العمل كلها. النموذج كله مبني بحيث يكون الخيار المحكم هو السهل.

هناك خمسة أدوار: المالك، والمسؤول، والعضو، والمشاهد، والضيف. كثير من الأدوات تتوقف عند أربعة وتعامل حالة المتعاون الخارجي بوصفها فكرة لاحقة. يجعل Taskfolk الضيف دورًا حقيقيًا بقواعده الخاصة، وهو ما تريده حين يحتاج عميل أو مستقل أو وكالة إلى مشروع واحد ولا شيء سواه.

تدير كل جزء من هذا من شاشة واحدة. في تنقّل مساحة العمل هي موسومة الأشخاص، وهي القاعدة الرئيسة: من في مساحة العمل، وما يقدر كل شخص على فعله، ومن لا يزال على دعوة غير مقبولة، وأي أشخاص خارجيين محدّدو النطاق لأي مشاريع. لنفتحها.

صفحة الأشخاص: حيث ترى الجميع وتديره

تعيش صفحة الأشخاص على /w/[workspace]/members. ملاحظة صادقة أولًا: تسمية التنقّل وعنوان الصفحة كلاهما يقول الأشخاص، لكن الرابط لا يزال يقول /members. هذا عن قصد. أُبقي المسار /members كي لا تنكسر الروابط والإشارات المرجعية القديمة، بينما انتقل الاسم المرئي إلى الأشخاص لأنه يُقرأ أفضل. اكتب الرابط بيدك، استخدم /members. تنقّل بالنقر، ابحث عن الأشخاص.

في أعلى الصفحة شريط ملخص. يعرض الإجمالي ثم عددًا لكل دور: المالك، المسؤول، العضو، المشاهد، الضيف. هذه أسرع قراءة لشكل مساحة عملك. نظرة واحدة تخبرك أن لديك، مثلًا، مالكًا واحدًا، ومسؤولَين، وثمانية أعضاء، وثلاثة مشاهدين، وضيفًا واحدًا، وهذا كثيرًا ما يكفي وحده لالتقاط خطأ. إن توقّعت صفر ضيوف ورأيت واحدًا، فتعرف أين تنظر.

أسفل الشريط قائمة الأعضاء النشطون. يعرض كل صف صورة الشخص (صورته، أو أحرفه الأولى إن لم يضبط واحدة)، واسمه، وبريده، وشارة دور ملوّنة كي تميّز مالكًا من مشاهد بنظرة واحدة. يحمل صفك أنت شارة أنت الصغيرة كي لا تخلط نفسك أبدًا بزميل يشاركك الاسم. الصفوف التي تخص وكلاء الذكاء الاصطناعي تحمل شارة وكيل، لأن الوكيل في Taskfolk عضو حقيقي في مساحة العمل، لكنه غير بشري.

على الجانب الأيسر من الصفحة ستجد بطاقة دعوة الأشخاص، وبحسب مساحة عملك، لوحة الدعوات المعلّقة وبطاقة وصول المشاريع محدّدة النطاق. سنصل إلى كلٍّ منها. المهم الآن استيعابه أن هذه الصفحة الواحدة هي حيث ترى الحالة الراهنة وتغيّرها معًا. لا تبحث عبر إعدادات المشاريع لإدارة من هو من على مستوى مساحة العمل. كل شيء هنا.

الأدوار الخمسة، وما يقدر كل واحد على فعله فعلًا

تحت الغطاء، يمرّ كل قرار صلاحية في Taskfolk عبر مصفوفة دور-صلاحية واحدة. جدول واحد، الأدوار على جانب والإجراءات على القمة، ونعم أو لا في كل خانة. تلك هي نموذج التخويل كله، ولأن هناك جدولًا واحدًا فقط، فالسلوك متّسق في كل مكان. اللوحة، وتفاصيل المهمة، والتعليقات، والمستندات، وقناة الفريق، والنماذج، وميزات الذكاء الاصطناعي، كلها تسأل الجدول نفسه السؤال نفسه. إليك ما يعنيه كل دور عمليًا.

المالك. هناك مالك واحد بالضبط لكل مساحة عمل، وهو أنت إن أنشأتها. للمالك تحكم كامل. ثلاثة أمور تخص المالك وحده: حذف مساحة العمل، وتغيير سبيكة مساحة العمل (جزء /your-workspace من الرابط)، ونقل الملكية إلى شخص آخر. لا مسؤول يقدر على ذلك، مهما كان موثوقًا. دور المالك ليس شيئًا توزّعه. إنه شيء تحمله، أو تمرّره عمدًا.

المسؤول. يدير المسؤولون مساحة العمل يوميًا. يقدر المسؤول على:

• تحرير إعدادات مساحة العمل
• دعوة الأعضاء وإزالتهم
• تغيير أدوار الآخرين (بحدّ واحد صارم، مغطّى أدناه)
• إنشاء المشاريع وأرشفتها، وتحرير إعداداتها
• تحرير أو حذف أي تعليق، لا تعليقاته فقط
• إدارة النماذج والإشراف على قناة الفريق، ما يعني حذف أي رسالة وإدارة القنوات

المسؤول مساعدك في القيادة. الشيء الوحيد الذي لا يقدر عليه المسؤول أن يصير المالك أو يمسّ صف المالك. المزيد عن ذلك تحت نقل الملكية.

العضو. هذا هو دور العمل الافتراضي، وهو الذي يجب أن يحمله معظم زملائك. يقدر العضو على:

• إنشاء المهام وتحرير مهامه
• كتابة تعليقاته وتحريرها وحذفها
• رفع المرفقات
• إدارة الوسوم وكتابة المستندات
• استخدام محادثة الذكاء الاصطناعي وإرسال الرسائل في قناة الفريق
• ربط وكيل الكود الخاص به

ما لا يقدر العضو عليه أن يحرّر عملًا ليس له. لا يقدر على إعادة كتابة مهمة زميل أو حذف تعليق لم يكتبه. ذلك الحدّ هو ما يمنع مساحة عمل مزدحمة من التحول إلى مكان يكتب فيه أي شخص فوق أي شخص.

المشاهد. المشاهد للقراءة فقط، وهو أصرم مما يتوقع الناس. لا يقدر المشاهدون على التعليق ولا الرفع ولا تحرير أي شيء، ولا إنفاق رصيد الذكاء الاصطناعي لمساحة العمل. ينظرون، ولا يغيّرون. استثناء واحد يستحق المعرفة: يقدر المشاهدون على قراءة قناة الفريق. يقدرون على متابعة المحادثة في قنواتك، لكنهم لا يقدرون على النشر. فقول «المشاهدون لا يرون شيئًا» خطأ. يرون الكثير. لا يقدرون على تعديل أي منه، ولا على تكبيد فاتورة ذكاء اصطناعي. المشاهد هو الدور الصحيح لصاحب مصلحة يريد الاطلاع دون مقعد على لوحة المفاتيح.

الضيف. الضيف متعاون خارجي، والسمة المميزة النطاق. الضيف لا يرى مساحة عملك. الضيف يرى فقط المشاريع المحددة التي تضيفه إليها صراحةً، ولا شيء سواها. ضمن تلك المشاريع يقدر الضيف على إنشاء مهامه وتحريرها، والتعليق، وإرفاق الملفات، وهذا يكفي لعمل حقيقي معًا.

لكن الضيف لا يقدر على تحرير مهام الآخرين، ولا إدارة الوسوم أو المستندات أو النماذج، ولا استخدام محادثة الذكاء الاصطناعي، ولا لمس أي إدارة لمساحة عمل أو مشروع أو عضو. الضيف هو الدور للعميل، والمستقل، وشريك الوكالة. إنه الجواب عن مشكلة المتعاقد في المقدمة.

الصفوف الخمسة نفسها، مختصرةً:

الدور	مقعد مدفوع	يقدر على تغيير العمل	يرى افتراضيًا
المالك	نعم	كل شيء، إضافةً إلى حذف مساحة العمل وتغيير السبيكة ونقل الملكية	كل مشروع
المسؤول	نعم	إدارة مساحة العمل والمشاريع، وأي تعليق	كل مشروع
العضو	نعم	مهامه وتعليقاته	كل المشاريع المفتوحة
المشاهد	لا	لا شيء، للقراءة فقط	كل المشاريع المفتوحة
الضيف	لا	مهامه وتعليقاته، في المشاريع الممنوحة فقط	لا شيء

إذًا: خمسة أدوار، لا أربعة. المالك والمسؤول يديران الأمور، والعضو يؤدي العمل، والمشاهد يراقب، والضيف هو الغريب الذي تُدخله غرفةً واحدة. أمسك بهذا النموذج فتصير معظم قرارات الدعوة بديهية.

كيف تدعو أعضاء إلى مساحة عمل بالدور الصحيح

الدعوة تُنفَّذ من بطاقة دعوة الأشخاص في صفحة الأشخاص. المالكون والمسؤولون فقط يرون هذه البطاقة. الأعضاء والمشاهدون والضيوف لا يقدرون على الدعوة. سطر البطاقة نفسه يلخّص المسار: «أدخل بريدًا، اختر دورًا، وأرسل. تنتهي الدعوة بعد 7 أيام.»

يمكنك دعوة شخص واحد أو دفعة. الصق البُرد مفصولةً بفواصل أو مسافات أو فواصل منقوطة أو أسطر جديدة، حتى 50 عنوانًا في إرسال واحد. لكل مدعوّ تختار دورًا من قائمة تحديد: مسؤول، عضو، مشاهد، أو ضيف. لاحظ ما ينقص. لا خيار للمالك. المالك غير قابل للدعوة أبدًا، بالتصميم، لأن مساحة العمل لا يمكن أن يكون لها إلا مالك واحد، والطريق الوحيد لنقله نقل متعمَّد.

نموذج الدعوة لا يجبرك على تذكّر ما يعنيه كل دور. كل خيار يحمل وصفًا بلغة واضحة هناك في النموذج:

الخيار	ما يقوله النموذج
مسؤول	«يقدر على دعوة الأعضاء وإدارة المشاريع وتغيير الأدوار (عدا المالك).»
عضو	«يقدر على إنشاء المهام وتحريرها وترك التعليقات.»
مشاهد	«للقراءة فقط، لا يقدر على التعليق أو الرفع أو تحرير أي شيء.»
ضيف	«متعاون خارجي، لا يرى إلا المشاريع التي تضيفه إليها.»

اختر الدور، انقر إرسال، فتخرج الدعوة بريدًا برابط سحري. Taskfolk بلا كلمات مرور، فلا خطوة كلمة مرور يتعثر فيها المدعوّ. يقبلون بتسجيل الدخول بالبريد نفسه الذي دعوتهم به، وعند تسجيل الدخول ينضمون إلى مساحة العمل بالدور الذي اخترته.

بعض الحدود الصادقة كي لا يفاجئك شيء:

• تنتهي الدعوات بعد 7 أيام وهي أحادية الاستخدام.
• الدعوات محدّدة المعدل بـ 100 في الساعة لكل مساحة عمل، والإرسال الواحد مسقوف عند 50 عنوانًا، فلا يمكنك لصق ألف بريد وقصفها دفعةً واحدة.
• إن دعوت شخصًا لديه أصلًا دعوة معلّقة، فالجديدة تُلغي القديمة وتحل محلها.
• تظهر الدعوات المعلّقة في لوحة الدعوات المعلّقة، حيث يمكنك إعادة إرسال واحدة (رمز جديد، ساعة 7 أيام جديدة، بريد جديد) أو إلغاء واحدة (يتوقف الرابط عن العمل فورًا).
• الدعوات المنتهية تسقط من القائمة وحدها.

عمر الدعوة كله يتّسع في صورة واحدة:

stateDiagram-v2
    [*] --> Pending: Send invite
    Pending --> Accepted: Recipient signs in
    Pending --> Expired: 7 days pass
    Pending --> Revoked: Revoke, or a new invite replaces it
    Pending --> Pending: Resend starts a new 7 day clock
    Accepted --> [*]

لجولة أوفى في مسار الدعوة، بما فيه ما يراه المستلم، اقرأ كيف تدعو أعضاء الفريق.

دعوة ضيف وتحديد نطاقه لمشاريع محددة

هنا تُحلّ مشكلة المتعاقد كما ينبغي. حين تختار ضيف دورًا، يتغير نموذج الدعوة: يظهر منتقي مشاريع الضيوف. إنه تحديد متعدد قابل للبحث، ففي مساحة عمل بها مشاريع كثيرة يمكنك الكتابة للتصفية بدل التمرير. هذا هو مغزى دور الضيف كله، تقرير أي مشاريع بالضبط يهبط فيها الغريب.

لنقل إنك تُدخل مصممًا خارجيًا للمساعدة على مشروع WEB وWEB فقط. تدعو بريده، وتضبط الدور على ضيف، وفي مشاريع الضيوف تختار WEB. هذا كل شيء. حين يقبل، يرى مشروع WEB، ولوحته بأعمدة قائمة الانتظار / للتنفيذ / قيد التنفيذ / قيد المراجعة / منجزة، ومهامه مثل «Timeline + Summary tab»، ولا شيء سواها. خارطة طريقك الداخلية، وعملك مع عملائك الآخرين، ومشروعك المالي، لا شيء من ذلك موجود على قدر ما يمكنه أن يعرف.

النموذج صريح في الافتراضي: «يبدأ الضيوف بلا وصول إلى المشاريع. بعد أن يقبلوا، أضفهم إلى مشاريع محددة من قسم الوصول محدّد النطاق أدناه.» يبدأ الضيف باطلاع صفري وتمنح المشاريع عمدًا، واحدًا تلو الآخر. هذا نقيض التسرّب في المقدمة. العضو يرى كل مشروع غير محدّد النطاق افتراضيًا. الضيف لا يرى شيئًا افتراضيًا. ذلك الفرق هو بالضبط لماذا كان يجب أن يكون المتعاقد ضيفًا، لا عضوًا.

flowchart TD
    A[Who sees which projects] --> B[Owner or admin]
    A --> C[Member or viewer]
    A --> D[Guest]
    B --> E[Every project, always]
    C --> F[All open projects plus scoped projects they are added to]
    D --> G[Only projects granted explicitly]

صراحة تقنية واحدة تستحق المعرفة. حين تضيف ضيفًا إلى مشروع، تخزّن عضوية المشروع دورًا على مستوى المشروع من مسؤول أو عضو أو مشاهد، لأن جدول أعضاء المشاريع الأساسي لا يحمل قيمة «ضيف». تلك التسمية على مستوى المشروع لا ترفع سقف الضيف.

صلاحياته الحقيقية لا تزال محكومة بصف الضيف لمساحة العمل في المصفوفة. فحتى لو خُزّن ضيف بوصفه «مسؤول» مشروع، لا يزال غير قادر على الأمور المحظورة على ضيف مساحة العمل مثل إدارة الوسوم أو استخدام محادثة الذكاء الاصطناعي. دور مساحة العمل هو السقف. دور المشروع مجرد كيفية تسجيل العضوية.

إن أردت الآليات الأعمق لإحكام إغلاق المشاريع، يغطي كيف تقيّد الوصول إلى المشاريع المشاريع محدّدة النطاق من البداية إلى النهاية.

كيف تغيّر دور أحدهم أو تنقل الملكية

أدوار الناس تتغير. مساهم يصير قائدًا. صاحب مصلحة يريد وصول تحرير. شريك مؤسِّس يجب أن يكون مسؤولًا فعلًا. تتولى كل ذلك من قائمة النقاط لكل صف، أي ⋮ في نهاية كل صف عضو على صفحة الأشخاص.

افتح القائمة على صف أحدهم فترى إجراءات تغيير الدور بصيغة تغيير إلى {role}، مثل «تغيير إلى مسؤول» أو «تغيير إلى مشاهد». اختر واحدًا فيصير التغيير فوريًا. يؤكّد تنبيه بـ «حُدّث الدور إلى {role}.»

تحت الغطاء يستدعي هذا إجراء changeMemberRole، الذي يفرض القواعد كي لا تنشئ حالةً غير متّسقة. الأبرز: لا يمكنك خفض مالك عبر هذه القائمة. صف المالك لن يعرض عليك «تغيير إلى مسؤول»، لأن الطريق الوحيد لنقل الملكية نقل حقيقي.

ذلك النقل إجراء قائم بذاته. بوصفك المالك، تعرض قائمة صف عضو آخر جعله المالك. اختياره يفتح حوار تأكيد يوضّح المبادلة: «نقل الملكية إلى {email}؟ يصير مالك مساحة العمل وتصير أنت مسؤولًا. المالك وحده يقدر على إعادة نقل الملكية.» أكّد، فيصير التغيير ذرّيًا. يصير الهدف مالكًا وتُخفَّض أنت إلى مسؤول في الحركة نفسها، فيوجد في كل لحظة مالك واحد بالضبط. لا تنتهي أبدًا بمالكين أو بلا مالك. يؤكّد تنبيه «نُقلت الملكية إلى {email}.»

sequenceDiagram
    actor O as Current owner
    participant U as Taskfolk
    actor T as New owner
    O->>U: Make owner, then confirm
    U->>T: Promoted to owner
    U->>O: Demoted to admin
    Note over U: One atomic change, never two owners or zero

يقدر المسؤولون على تغيير الأدوار أيضًا، ضمن حدود. يقدر المسؤول على ترقية عضو إلى مسؤول، وخفض مسؤول إلى مشاهد، وهكذا. ما لا يقدر عليه المسؤول ترقية أي شخص إلى مالك أو مسّ صف المالك إطلاقًا. قائمة تحديد الدور التي يستخدمها المسؤول لا تشمل حتى المالك خيارًا، ويرفض الخادم أي محاولة لتعديل المالك. فقول «مسؤول يجعل نفسه مالكًا بهدوء» ليس شيئًا يمكن أن يحدث. الملكية لا تنتقل إلا حين يختار المالك الحالي نقلها.

عنصر آخر يعيش في قائمة النقاط تلك: وسمه وكيلًا وإلغاء وسمه وكيلًا. هذا يعلّم عضوًا وكيل ذكاء اصطناعي، أو يزيل العلامة، وهو إعداد لكل مساحة عمل. يهمّ للفوترة، التي سنعود إليها في النهاية، لأن الأعضاء الوكلاء مجانيون.

إزالة عضو أو مغادرة مساحة العمل بنفسك

أحيانًا التغيير الذي تريده ليس دورًا جديدًا، بل الخروج. تحمل قائمة نقاط الصف إجراء إزالة للمالكين والمسؤولين. مصمَّم إجراءً خطرًا ويفتح حوار تأكيد، لأنه ليس شيئًا تطلقه بالخطأ: «إزالة {email}؟ يفقد الوصول إلى مساحة العمل هذه وكل مشاريعها. تبقى مهامه وتعليقاته.»

اقرأ الجملة الأخيرة بعناية، لأنها الجزء الذي يخطئ فيه الناس. إزالة أحدهم لا تحذف عمله:

• تبقى مهامه.
• تبقى تعليقاته.
• يبقى تاريخ ما فعله في مساحة عملك سليمًا ومنسوبًا إليه.

ما تفعله الإزالة أنها تقطع وصوله. لم يعد يقدر على فتح مساحة العمل أو أي من مشاريعها.

هناك شيء آخر تفعله الإزالة، وهو الجزء المدروس. في المعاملة نفسها التي تزيل الشخص، يلغي Taskfolk تلقائيًا إسناد مهامه المفتوحة. فالتذكرة التي كان يعمل عليها لا تجلس مُسندةً إلى الأبد إلى شخص رحل. تعود غير مُسندة ويمكنك تسليمها لشخص لا يزال هنا.

لكن هذا يمسّ المهام المفتوحة فقط. المهام المحلولة أو المنجزة أو الفاشلة أو الملغاة تحتفظ بمُسندها الأصلي، لأن ذلك تاريخ، وإعادة كتابة من أنجز مهمةً قبل أشهر ستكون كذبة. العمل المفتوح يتحرّر. العمل المنجز يحتفظ بسجله.

إن لم تكن المالك وأردت المغادرة بنفسك، فهناك زر مغادرة مساحة العمل لك. يؤكّد بـ «مغادرة مساحة العمل هذه؟» ويفعل ما يقول. المالكون هم الاستثناء. المالك لا يقدر على المغادرة، لأن مساحة العمل لا يمكن أن تكون بلا مالك. إن كنت المالك وحاولت، سترى «لا يمكن للمالكين المغادرة. انقل الملكية أولًا، ثم غادر.» فتسلسل مغادرة المالك: جعله المالك لمن يتولى، ثم غادر بوصفك مسؤولًا.

وصول المشاريع محدّدة النطاق: إحكام مشروع على أعضاء محددين

الضيوف محدّدو النطاق لمشاريع محددة بطبيعتهم. لكن أحيانًا تريد إغلاق مشروع حتى على فريقك، فلا يراه إلا أعضاء مسمّون. ذلك مشروع محدّد النطاق، وهو إعداد من جزأين. تقلب المشروع إلى محدّد النطاق في إعدادات المشروع نفسه، ثم تدير قائمة أعضائه من صفحة الأشخاص.

مفتاح تحديد النطاق يعيش في إعدادات المشروع، لا في صفحة الأشخاص. افتح المشروع الذي تريد حمايته، وانتقل إلى إعداداته، وشغّل تقييد الوصول على أعضاء محددين. يضبط ذلك المشروع محدّد النطاق. من تلك اللحظة، يكون المشروع مرئيًا فقط لمالكي مساحة العمل ومسؤوليها (الذين يحتفظون دائمًا بالوصول إلى كل شيء) إضافةً إلى الأشخاص المحددين الذين تدرجهم. يتوقف كل من سواهم في مساحة العمل عن رؤيته، كأنه غير موجود.

حالما يوجد مشروع محدّد النطاق واحد على الأقل، تظهر بطاقة جديدة على صفحة الأشخاص للمالكين والمسؤولين: وصول المشاريع محدّدة النطاق. يبيّن وصفها القاعدة: «المشاريع محدّدة النطاق مرئية فقط لمالكي مساحة العمل ومسؤوليها إضافةً إلى الأشخاص المدرجين هنا. امنح الوصول أو اسحبه لكل مشروع.» هذه البطاقة هي حيث تبني قائمة الوصول. تختار المشروع محدّد النطاق، وتنقر إضافة عضو، وتختار زميلًا من منتقي «اختر زميلًا…»، وتمنحه دورًا على مستوى المشروع من مسؤول أو عضو أو مشاهد، وتضيفه. لسحب أحدهم، تزيله من البطاقة نفسها.

تظهر البطاقة فقط حين يكون لمساحة العمل مشروع محدّد النطاق فعلًا. لا مشاريع محدّدة النطاق، لا بطاقة. يُبقي ذلك صفحة الأشخاص نظيفة لمساحات العمل التي لا تحتاج إلى هذا أبدًا.

يساعد أن تُمسك قواعد الرؤية في مكان واحد، لأنها تتفاعل:

• الأعضاء والمشاهدون يرون كل المشاريع غير محدّدة النطاق (المفتوحة) افتراضيًا، إضافةً إلى أي مشروع محدّد النطاق أُضيفوا إليه صراحةً.
• الضيوف يرون مشاريعهم المحددة فقط، محدّدة النطاق أو لا. لا شيء مرئي للضيف افتراضيًا.
• المالكون والمسؤولون يرون كل شيء، بما فيه المشاريع محدّدة النطاق، ولا يمكن إغلاقها في وجههم.

فالمشروع محدّد النطاق هو الأداة للأسرار الداخلية: مشروع الاستحواذ، والتخطيط التنفيذي، والشيء الذي يجب أن يعرف ثلاثة أشخاص فقط بوجوده. تحديد نطاق الضيف هو الأداة للأشخاص الخارجيين. يحلّان مشكلتين مختلفتين بالفكرة الأساسية نفسها: الوصول صريح، لا مفترَض.

إدارة الأدوار من الواجهة البرمجية

كل ما سبق هو صفحة الأشخاص. إن أدخلت الناس من سكربتات، فالعمليات نفسها موجودة على الواجهة البرمجية REST. سرد من في مساحة العمل يتطلب استدعاءً واحدًا بمفتاح له نطاق members:read:

curl -s https://taskfolk.ai/api/v1/workspaces/your-workspace/members \
  -H "Authorization: Bearer tfk_live_..."

يحمل كل صف في الرد user_id وemail وname وrole وjoined_at، فيمكنك مقارنته بقائمة الموارد البشرية في مهمة مجدولة.

إرسال دعوة يحتاج إلى نطاق members:write، ويحمل المفتاح سقف منشئه: لا ينجح الاستدعاء إلا إن كان المفتاح لمالك أو مسؤول، القاعدة نفسها لبطاقة دعوة الأشخاص. الجسم هو الخيار نفسه الذي تصنعه في النموذج، بريد ودور (admin أو member أو viewer أو guest):

curl -s -X POST https://taskfolk.ai/api/v1/workspaces/your-workspace/invites \
  -H "Authorization: Bearer tfk_live_..." \
  -H "Content-Type: application/json" \
  -d '{"email": "[email protected]", "role": "guest"}'

const res = await fetch(
  "https://taskfolk.ai/api/v1/workspaces/your-workspace/invites",
  {
    method: "POST",
    headers: {
      Authorization: `Bearer ${process.env.TASKFOLK_API_KEY}`,
      "Content-Type": "application/json",
    },
    body: JSON.stringify({ email: "[email protected]", role: "guest" }),
  },
);
const { data } = await res.json(); // 201; data.expires_at is the 7-day deadline

import os
import requests

res = requests.post(
    "https://taskfolk.ai/api/v1/workspaces/your-workspace/invites",
    headers={"Authorization": f"Bearer {os.environ['TASKFOLK_API_KEY']}"},
    json={"email": "[email protected]", "role": "guest"},
)
res.raise_for_status()  # 201; the invite still expires after 7 days

تغييرات الدور تمرّ عبر PATCH /v1/workspaces/{slug}/members/{userId}، والقيم المقبولة هي admin وmember وviewer:

curl -s -X PATCH https://taskfolk.ai/api/v1/workspaces/your-workspace/members/USER_ID \
  -H "Authorization: Bearer tfk_live_..." \
  -H "Content-Type: application/json" \
  -d '{"role": "viewer"}'

لا قيمة owner في ذلك الجسم، عن قصد. الملكية تنتقل عبر النقل داخل التطبيق فقط، بمفتاح واجهة برمجية أو دونه.

من يدفع مقابل مقعد، وأخطاء أدوار شائعة يجب تجنبها

للأدوار جانب فوترة، وهو أبسط مما قد تخشى. ثلاثة أدوار فقط تكلّف مقعد منفّذ: المالك، والمسؤول، والعضو. تلك هي الأدوار التي تقدر على إنشاء الأشياء وتغييرها، فهي التي يعدّها Taskfolk ضمن اشتراكك لكل مقعد. المشاهدون مجانيون. الأعضاء الوكلاء مجانيون. لا يُعدّ أي منهما أبدًا ضمن كمية مقاعد Stripe، وحين تغيّر الأدوار أو تزيل الناس يعيد عدّ المقاعد مزامنته على أساس بذل الجهد كي لا تدفع مقابل شخص رحل.

لهذا نتيجة عملية حقيقية. صاحب مصلحة يحتاج فقط إلى مراقبة التقدّم يجب أن يكون مشاهدًا، لا عضوًا، لأن المشاهد لا يكلّفك شيئًا ولا يزال يرى اللوحات والمهام وقناة الفريق. حشو مساحة عملك بالمشاهدين مجاني. حشوها بالأعضاء ليس كذلك.

بعض الأخطاء تظهر مرارًا وتكرارًا، فسمّها وتجنّب الألم:

• دعوة متعاقد بوصفه عضوًا بدل ضيف. هذا سيناريو المقدمة. العضو يرى كل مشروع غير محدّد النطاق افتراضيًا. الضيف يرى فقط ما تمنحه. الأشخاص الخارجيون يجب أن يكونوا ضيوفًا دائمًا تقريبًا.
• توقّع اختفاء عمل عضو مُزال. لا يختفي. الإزالة تقطع الوصول وتلغي إسناد مهامه المفتوحة تلقائيًا، لكن مهامه وتعليقاته تبقى منسوبةً إليه. إن احتجت فعلًا إلى إزالة المحتوى، فتلك عملية حذف منفصلة، لا أثر جانبي لإزالة الشخص.
• افتراض أن المشاهدين لا يرون شيئًا. المشاهدون للقراءة فقط، لكنهم يقدرون على قراءة قناة الفريق. إن كانت قنواتك تحمل أمورًا لا يجب أن يقرأها مشاهد، فدور المشاهد ليس الجدار الذي تظنه.
• افتراض أن المسؤول يقدر على انتزاع الملكية. لا يقدر. المالك وحده يقدر على نقل الملكية، وفعل ذلك يخفضه إلى مسؤول في الحركة نفسها. المسؤولون الموثوقون ليسوا مالكين مع ذلك.

إن كانت أسئلتك المفتوحة عن جانب المال، يغطي هل يُعدّ وكلاء الذكاء الاصطناعي مقاعد فوترة الوكلاء تحديدًا، ويغطي كيف تدير الفوترة والخطط المقاعد والخطط وكمية المقعد من البداية إلى النهاية.

اضبط الأدوار وقت الدعوة، واستخدم الضيوف للغرباء، وحدّد نطاق المشاريع التي تحتاج إليه، فلا يحدث التسرّب في المقدمة أبدًا. افتح صفحة الأشخاص لمساحة عملك وتفقّد شريط الملخص الآن. إن لم تطابق الأعداد من يجب أن يملك ماذا، فقد وجدت أول إصلاح لك.