حالات سير العمل المخصصة

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

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

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

لماذا تكفّ الأعمدة الافتراضية عن النفع

لوحة بعمود «قيد التنفيذ» واحد جيدة حين تكونون ثلاثة. الجميع يرى كل شيء، و«قيد التنفيذ» يعني شيئًا واحدًا فعلًا.

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

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

قبل أن تلمس زرًا، مع ذلك، هناك نموذج ذهني واحد يجب توضيحه. إنه ما يُبقي كل هذا آمنًا.

الحالات مقابل فئات الحالات: التقسيم الذي يُبقيها آمنة

كل شيء يقوم على هذا. يُبقي Taskfolk فكرتين منفصلتين متمايزتين: فئة الحالة، والحالة نفسها.

الفئة enum ثابت بسبع قيم بالضبط: backlog، todo، in_progress، in_review، done، failed، cancelled. لا يمكنك اختراع جديدة. هذا مقصود. الفئة هي العمود الفقري الدلالي الذي تقرأ منه التقارير، وعلَم المفتوح/المنجز، وتواريخ الحل، والواجهة البرمجية العامة كلها. حين يقول تقرير «12 مهمة مفتوحة، 4 محلولة هذا الأسبوع»، فهو يعدّ الفئات، لا أسماء الأعمدة. لو كانت الفئات قابلة للتحرير بحرية، لما بقي شيء من ذلك موثوقًا من مشروع إلى آخر.

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

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

flowchart LR
    CR[Code review column] --> IR[in_review category]
    QA[QA column] --> IR
    IR --> RP[Reports and resolved dates]
    IR --> API[Public API status]

تحصل على التفصيل الذي تحتاج إليه عمليتك دون الكذب على مقاييسك.

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

أين تدير حالات اللوحة

هناك مكانان لإدارة الأعمدة، وهما الميزة نفسها تكتب إلى الجدول نفسه. استخدم أيهما أقرب إلى يدك.

الأول إعدادات المشروع، تحت تبويب حالات اللوحة. الرابط المباشر /w/<workspace>/p/<project>/settings?tab=statuses. هذا هو السطح الكامل: كل عمود مبسوط في قائمة بكل أدواته ظاهرةً دفعةً واحدة. جيد لجولة إعداد متأنية.

الثاني اللوحة نفسها. الـ «+» المتأخر في الطرف الأيسر من الأعمدة يضيف واحدًا جديدًا، ولكل ترويسة عمود قائمة نقاط (أيقونة النقاط الثلاث) لإعادة التسمية وتغيير اللون وإعادة التصنيف والتحريك والحذف. جيد لتعديل سريع بينما تنظر إلى العمل الفعلي.

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

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

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

أضف عمودًا وأعد تسميته وغيّر لونه

إضافة عمود هي صف الإنشاء في أعلى بطاقة حالات اللوحة. ثلاثة أمور تملؤها.

اكتب اسمًا في حقل اسم الحالة. الأسماء تصل إلى 80 محرفًا، وإن كان الأقصر يُقرأ أفضل على عمود لوحة. لمثالنا، اكتب Code review.

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

اختر لونًا. هناك ثماني عيّنات مسبقة: #6B6F7A و#A4A8B2 و#FFD60A و#4FE8E5 و#6AF7A8 و#FF8A3D و#FF3B6B و#B47CFF. أو انقر المنتقي المخصص وأدخل أي hex من 6 خانات بصيغة #RRGGBB. بما أن «قيد المراجعة» موجود أصلًا، اختر شيئًا مجاورًا لكن متمايزًا كي لا تتموّه مرحلتا المراجعة إحداهما في الأخرى على اللوحة. العيّنات مضبوطة أصلًا لتُقرأ بوضوح على اللوحة الداكنة، فأي منها رهان آمن.

انقر «إضافة حالة». تحصل على تأكيد («أُضيفت "Code review".») ويظهر العمود الجديد في القائمة. قاعدتان يجب معرفتهما. الأسماء المكررة تُرفض بلا حساسية لحالة الأحرف، فلا يمكنك امتلاك «Code review» و«code review» معًا. وهناك سقف صارم من 12 حالة حيّة لكل مشروع. يبدو سخيًا حتى تتذكر أن سبعة افتراضية تنفق ميزانيتك أصلًا، فأضف المراحل بتأنٍّ.

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

أعد ترتيب الأعمدة كي تُقرأ اللوحة من اليمين إلى اليسار

ترتيب الأعمدة ليس زخرفة. يجب أن تعكس لوحتك كيف يتدفق العمل فعلًا، كي يقرأ من يمسحها بنظره دورة حياة تذكرة دون تفكير. قائمة الانتظار في أقصى اليمين، منجزة في أقصى اليسار، وكل ما بينهما بالترتيب الذي يحدث به فعلًا.

عمود «مراجعة الكود» الجديد لدينا أُلحق بنهاية القائمة، وهذا خاطئ. مراجعة الكود تحدث بعد الترميز وقبل المراجعة النهائية، فمكانها بين «قيد التنفيذ» و«قيد المراجعة».

ثلاث طرق لتحريكه، كلها تحفظ الترتيب نفسه عبر LexoRank تحت الغطاء:

• في الإعدادات، استخدم سهمَي أعلى وأسفل على صف العمود.
• على اللوحة، افتح قائمة نقاط ترويسة العمود واختر «تحريك يسارًا» أو «تحريك يمينًا».
• على اللوحة، اسحب ترويسة العمود نفسها. هذه تعمل فقط إن كنت تملك project.edit_settings؛ الترويسة هي مقبض السحب.

ادفع «مراجعة الكود» لأعلى حتى يهبط بين «قيد التنفيذ» و«قيد المراجعة». الآن تُقرأ لوحة WEB: قائمة الانتظار، للتنفيذ، قيد التنفيذ، مراجعة الكود، قيد المراجعة، منجزة، ورحلة تذكرة عبر اللوحة تطابق رحلتها عبر عمليتك.

هذه أيضًا لحظة ملاحظة أن اللوحة والإعدادات ميزة واحدة فعلًا. أعد الترتيب في الإعدادات، تتحدّث اللوحة. اسحب على اللوحة، تتحدّث الإعدادات. جدول واحد، بابان.

تغيير فئة حالة، وما يفعله بمهامك

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

كل حالة تقابل فئة واحدة بالضبط. حين تغيّر ذلك التقابل، يعيد Taskfolk ختم كل مهمة في ذلك العمود حاليًا. يحدث أمران لكل مهمة من تلك:

• تُضبط status (الفئة) على القيمة الجديدة.
• يُعدَّل طابعها الزمني للحل: الانتقال إلى فئة نهائية (done أو failed أو cancelled) يختم resolvedAt بالآن، والخروج من فئة نهائية يمسحه.

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

إليك حالة ملموسة. لنقل إن لديك عمود «جاهز للإطلاق» يقابل in_review، يحمل ثماني تذاكر مُعتمَدة لكن غير مُطلَقة بعد. تقرر أن «جاهز للإطلاق» يجب أن يُعدّ منجزًا فعلًا، فتقلب فئته من in_review إلى done. لحظة حفظك، تُعلَّم التذاكر الثماني كلها محلولةً اعتبارًا من الآن. عدّ المحلول هذا الأسبوع يقفز بثمانية. يُحسب زمن دورتها إلى هذه اللحظة.

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

قيّد الانتقالات ببطاقة سير العمل

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

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

الدلالات تستحق التوضيح بالضبط، لأن الحالات الحدية هي حيث يلتبس الأمر على الناس:

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

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

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

stateDiagram-v2
    state "In Progress" as ip
    state "Code review" as cr
    state "In Review" as ir
    state "Done" as d
    ip --> cr
    cr --> ir
    ir --> ip: needs work
    ir --> d: approved

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

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

أين تُفرض القواعد فعلًا

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

flowchart TD
    A[Issue page update] --> C{Server transition check}
    B[Board drag] --> C
    K[Bulk status change] --> C
    E[Automation set_status] --> C
    F[v1 REST and transition API] --> C
    C -->|allowed| W[Status written]
    C -->|blocked| X[Rejected, columns named]

إليك كل مسار كتابة وما يحدث حين تكون الحركة غير قانونية:

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

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

رسالة الحركة المحظورة تسمّي الأعمدة، فهي ليست غامضة أبدًا. تُقرأ: Workflow: "In Review" cannot move to "Backlog". Transitions are configured in project settings. من يصطدم بها يعرف بالضبط ما حدث وأين يغيّره إن كانت القاعدة خاطئة.

صمّام أمان واحد يستحق المعرفة. يحلّ الفرض حالة «من» الفعلية بالطريقة نفسها التي تحلّها اللوحة: بـ status_id حين يكون العمود حيًّا، وإلا بالعمود الافتراضي للفئة. وإن تعذّر حلّ الحالة الراهنة فعلًا (معرّف ميت أو مجهول)، تُسمَح الحركة. فلا يمكن أن تُحتجَز تذكرة أبدًا في حالة غير قابلة للحل. بين ذلك وكون الحركات إلى الذات قانونيةً دائمًا، لا إعداد يمكن أن يعلّق تذكرة إلى الأبد.

أدر الحالات والقواعد عبر الواجهة البرمجية v1

كل ما سبق له توأم في الواجهة البرمجية، وهذا يهمّ إن كان وكيل أو سكربت يُعدّ المشاريع لك. الأعمدة تعيش على /v1/workspaces/{slug}/projects/{key}/statuses على عنوان الأساس https://taskfolk.ai/api. قراءتها تحتاج إلى نطاق projects:read؛ إنشاؤها وتحريرها وحذفها يحتاج إلى projects:write.

ابدأ بسرد الأعمدة، لأن قواعد الانتقال تُكتب معرّفات حالات، لا أسماء:

curl "https://taskfolk.ai/api/v1/workspaces/taskfolk/projects/WEB/statuses" \
  -H "Authorization: Bearer tfk_live_a1b2..."

كل حالة في الرد تحمل حقول سير عملها إلى جانب الأساسيات:

{
  "id": "0197a3e2-...",
  "name": "In Review",
  "name_ar": null,
  "color": "#4FE8E5",
  "category": "in_review",
  "rank": "n",
  "allowed_transitions": null,
  "wip_limit": null
}

allowed_transitions: null هو الافتراضي بلا تقييد. لتطبيق بوابة «قيد المراجعة» نفسها التي بنيناها في الواجهة، أرسل PATCH للحالة بمعرّفَي «قيد التنفيذ» و«منجزة». يُسقِط الخادم معرّف الحالة نفسها وأي معرّف ليس عمودًا حيًّا في المشروع، والقائمة تُسقَف عند 24 هدفًا. أرسل null لإعادة الضبط إلى السماح بالكل، أو [] لعمود نهائي.

curl -X PATCH "https://taskfolk.ai/api/v1/workspaces/taskfolk/projects/WEB/statuses/<in-review-id>" \
  -H "Authorization: Bearer tfk_live_a1b2..." \
  -H "Content-Type: application/json" \
  -d '{ "allowed_transitions": ["<in-progress-id>", "<done-id>"] }'

await fetch(
  "https://taskfolk.ai/api/v1/workspaces/taskfolk/projects/WEB/statuses/" + inReviewId,
  {
    method: "PATCH",
    headers: {
      Authorization: "Bearer tfk_live_a1b2...",
      "Content-Type": "application/json",
    },
    body: JSON.stringify({
      allowed_transitions: [inProgressId, doneId],
    }),
  }
);

import requests

requests.patch(
    f"https://taskfolk.ai/api/v1/workspaces/taskfolk/projects/WEB/statuses/{in_review_id}",
    headers={"Authorization": "Bearer tfk_live_a1b2..."},
    json={"allowed_transitions": [in_progress_id, done_id]},
)

جسم PATCH نفسه يأخذ أيضًا name وname_ar وcolor وcategory وwip_limit، وإنشاء عمود هو POST إلى المجموعة بـ { name, color, category }. تحذير تغيير الفئة السابق ينطبق بكامل قوّته هنا: PATCH يغيّر category يعيد ختم كل مهمة في ذلك العمود، تمامًا كالواجهة.

حين يحاول سكربت بعدها حركةً غير قانونية، فإن نقطة نهاية الانتقال المخصصة (POST .../issues/WEB-12/transition) وPATCH المهمة العادي كلاهما يجيبان بمغلّف التحقّق نفسه:

{
  "error": {
    "code": "validation",
    "message": "Workflow blocks this transition: \"In Review\" cannot move to \"Backlog\".",
    "details": {
      "code": "workflow_transition_blocked",
      "from": "In Review",
      "to": "Backlog"
    }
  }
}

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

حدود WIP: ما يفعله الحقل فعلًا، وما لا يفعله

حان وقت قسم صادق، لأن هذا هو المكان الوحيد الذي يمكن أن تضلّلك فيه الواجهة.

لبطاقة سير العمل حقل حد WIP على كل حالة: عدد صحيح من 1 إلى 999، أو فارغ لـ «بلا حد». يمكنك ضبطه، ويُحفظ، ويُخزَّن على العمود ويُكشف عبر الواجهة البرمجية v1 (wip_limit في الحمولات أعلاه). كل هذا صحيح.

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

وهو أيضًا ليس ما يقود شارة WIP على اللوحة. للوحة عرض WIP منفصل خاص بها: شارة «n / الحد» على ترويسة العمود وحد أحمر عند التجاوز. لكن تلك الشارة تقرأ افتراضًا مثبَّتًا لكل فئة، لا الرقم الذي كتبته. تلك الافتراضيات هي in_progress = 4، وin_review = 3، والباقي بلا سقف. والشارة لا تظهر أصلًا إلا حين تشغّل عرض WIP من جهة العميل فقط بـ ?wip=1 على رابط اللوحة. إنها مطفأة افتراضيًا.

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

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

حذف حالة، والحدود التي يجب تذكّرها

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

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

يحذّرك Taskfolk. حين يحمل العمود مهامًا، يقول حوار التأكيد: «ستُحذف المهام في هذا العمود حذفًا مؤقتًا. وهي قابلة للاسترجاع 30 يومًا.» بعد الحذف ترى رسالة مثل «حُذف العمود. أُرشفت N من المهام.» وعمود واحد لا يمكنك حذفه أبدًا: الأخير. اللوحة تحتاج إلى حالة واحدة على الأقل، فالعمود النهائي يرفض المغادرة («اللوحة تحتاج إلى حالة واحدة على الأقل.»).

في الختام، إليك الحدود الصادقة للميزة كلها، كي تدخل بتوقعات واضحة:

• 12 حالة حيّة كحد أقصى لكل مشروع. رتّب ميزانيتها.
• 7 فئات ثابتة. تسمّي وتلوّن بحرية؛ لا يمكنك اختراع فئة.
• قواعد الانتقال قائمة سماح بسيطة لكل «من». كل عمود يتحكم بحركاته الخارجة، مسقوفةً عند 24 هدفًا لكل حالة. لا نظام شروط لكل دور أو نوع أو انتقال، ولا مدقّقات، ولا شيء من آلية محرّك سير العمل الكاملة في Jira.
• الأسماء تُسقَف عند 80 محرفًا؛ الألوان hex من 6 خانات. الأسماء العربية مدعومة (لكل حالة اسم عربي اختياري يُعرض في اللغة الفعّالة ويرجع إلى الاسم الإنجليزي).
• الحذف مدمّر لمهام العمود، قابلة للاسترجاع 30 يومًا.

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

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