استورد عناصر Jira إلى فريقي

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

يعالج القارئ بنية Jira الغريبة قبل تحويل الصف إلى مهمة. لا يفترض أن عنوان العمود فريد، لأن Labels والـ Sprints والـ Attachments وروابط العناصر قد تتكرر بالطريقة نفسها. وفي خلية Comment يقسم القيمة إلى التاريخ ومعرّف الكاتب والنص بثلاثة أجزاء فقط، فلا يحذف ما بعد أول فاصلة منقوطة كتبها صاحب التعليق. وإذا جاء ملف current fields بتعليق لا يحمل هذه البنية، يحتفظ بمحتوى الخلية بوصفه نص التعليق بدلاً من إسقاطه.

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

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

اختيار Sprint يغيّر التجميع لا طبيعة الـ Issue. يبقى حقل Project في Jira هو ما يسمّي مشروع فريقي، وتصبح قيمة Sprint المختارة عنوان قائمة مهام، ويصبح Summary عنوان المهمة. لا يُنشئ المستورد كيان Sprint له بداية ونهاية أو يحاول تشغيل تخطيط Scrum داخل فريقي. تستطيع الرجوع إلى المعاينة وتبديل التجميع إلى Status أو Epic أو Issue Type أو Assignee أو Priority قبل التأكيد، فتُقرأ البيانات من الملف نفسه مرة أخرى.

يبقى تحديد الإنجاز منفصلاً عن Sprint واسم Status المخصّص. يقرأ المستورد Status Category لأنها محصورة في القيم التي تفرّق العمل المفتوح والمنجز، بينما يستطيع فريق Jira تسمية Status بما يشاء. ويعني وجود Resolution أن العنصر حُل، لكن قيمة Resolution نفسها هي التي تفرّق المنجز من الملغى. لهذا لا تتحول كل Issue خرجت من Sprint قديم إلى مهمة مكتملة، ولا تُحسب العناصر الملغاة إنجازاً لم يحدث.

تبقى التفاصيل التي لا تدخل هذا الهيكل بجانب المهمة حيث أمكن. تُكتب Story Points في سطر مسمّى، وتبقى Labels في الملاحظات، وتتحول روابط Attachment القابلة للفتح إلى روابط بأسماء الملفات. أما العلاقات بين الـ Issues وتتبّع الوقت فلا يصيران سجلات مستقلة. وإذا تكرر Summary داخل القائمة الناتجة، يعالج المستورد تعارض العنوان ويعرض الاسم المعدّل قبل أن تضغط التأكيد، فلا يؤدي اختيار Sprint جديد إلى فشل القائمة كلها بسبب اسم مكرر.