توقّفنا عن التجربة على المباشر. الملف ده بيوثّق بالظبط ليه الورك ليست طلعت فاضية (أو طلب واحد)، الأسباب الجذرية بالأدلة، اللي اتصلح فعلاً، والخطة الآمنة عشان الورك ليست تعتمد على الباك إند بالكامل بدل منطق الفرونت — من غير ما نكسر الشاشة اليومية تاني.
المسار الجديد (الباك) مقفول قطعياً للكل (kill-switch بيمسح أي flag متخزّن). الصفحتين على المنطق القديم المثبّت. كل التحاليل بتظهر. مفيش حاجة مكسورة دلوقتي.
يعني نقدر نخطّط بهدوء — أي تنفيذ جاي هيكون متحقَّق offline الأول، وبعدين opt-in تجرّبه إنت، وبعدين أساسي. مش هنفعّل حاجة live من غير تأكيدك.
السبب الجذري الأساسي — مفاجأة في الـAPI القديم:
صفحة الورك ليست القديمة بتنادي:
بس الكنترولر القديم (LabResultController) بيتعامل مع status (مفرد) بس — مفيش معالجة لـstatuses (جمع). فالفلتر بيتجاهَل بالكامل، والـAPI بيرجّع كل تحاليل اليوم (المكتمل + الناقص).
الدليل: ?statuses=released و?statuses=pending رجّعوا نفس النتيجة بالظبط (52 نتيجة: 36 released + 16 entered).
| الورك ليست القديمة (فعلياً) | الورك ليست الجديدة (أول محاولة) | |
|---|---|---|
| بتعرض إيه | كل طلبات اليوم (لأن الفلتر متجاهَل) | الناقص بس (incomplete) |
| طلبات النهاردة | 12 طلب ✅ | 0 ثم 1 ❌ |
| ليه الفرق | النهاردة معظم الشغل اتعمل (released). القديمة بتعرضهم؛ الجديدة بتخفيهم لأنها فلترت "الناقص" — اللي فاكرين إنه سلوك القديمة، لكنه مكنش. | |
المشكلة مكانتش "بيانات ضايعة" ولا "render مكسور" — كانت تعريف غلط لإيه اللي الورك ليست المفروض تعرضه، مبني على فلتر API كان متعطّل من الأساس في القديم.
رحلة التشخيص كشفت 5 فجوات. دي كلها دلوقتي مفهومة، وأغلبها اتصلح:
statuses متجاهَل في القديماتصلحالقديم بيعرض كل طلبات اليوم. أضفت status_filter=worklist في الباك = كل طلبات اليوم (أي حالة) + ما-قبل-الـbench. تحقّق: 12 = 12 النهاردة، نفس مجموعة الـids بالظبط.
lab_section_id) مش مدعومةاتصلحdept مقسّم بالأقسام، بس الـendpoints الجديدة كانت بتتجاهل القسم → بتسقّط تحاليل. أضفت دعم lab_section_id في cards + rows. تحقّق: طلب 79 (21 تحليل) بيتقسّم بالظبط: قسم1=16 + قسم2=4 + قسم5=1، صفر ضياع.
الطلبات اللي اتجمّعت عيناتها بس لسه مالهاش نتيجة كانت بتختفي. أضفت prebenchCards() بتظهرهم تحت worklist/incomplete.
العرض وأمان البيانات تمام (النوع محفوظ، مفيش تحويل لـnumeric)، بس إعدادات إدخال النتائج الخاصة (قواعد الرفع، قالب الهيستوباث، requires_peer_review/grossing) مش جاية في الصف. ضفت جزء من الحقول؛ محتاج أكمّلها.
أول cutover خلّى الجديد أساسي وحذف القديم وقت ما الباك لسه مش بيدعم الأقسام → كسر → رجعنا بـgit. الدرس: الباك يكمل الأول، التحقّق الأول، الحذف آخر حاجة.
WorklistContextService — كل منطق التجميع (dedup، النَسب، البنلات، sub-sections، locked، الترتيب، رولأب، الملخّص، flag، التوقيت) في الباك.
/lis/worklist/cards + /requests/{id}/rows + /search — بتدعم lab_section_id + status_filter.
النهاردة: worklist = 12 = القديم (12)، نفس الـids بالظبط.
كل الـ12 طلب: عدد تحاليل كل طلب في الجديد = القديم (16,1,2,2,2,1,2,2,2,5,1,16).
HBA1C602 (عضوين بدون تكرار) + CBC (sub-sections) صح.
histopath مابتتحوّلش لـnumeric — صفر فساد بيانات.
status_filter=worklist (dept) — كل طلبات اليوم + ما-قبل-الـbench.lab_section_id (cards + rows)./lis/results القديم: نفس الطلبات؟ نفس التحاليل لكل طلب؟ نفس الحالات؟ نفس القيم/الفلاج؟status_filter=worklist (مش incomplete).?serverWorklist=1 (الافتراضي قديم → الـlab مايتأثرش).?serverWorklist=0) — مش هنحذفه في الخطوة دي.مفيش لمسة فرونت قبل ما الهارنس يثبت 100% تطابق على عدة أيام وأقسام.
إنت تجرّب بـ?serverWorklist=1 الأول. الـlab على القديم لحد ما تأكّد.
القديم يفضل موجود؛ ?serverWorklist=0 رجوع فوري؛ وفيه kill-switch قطعي لو لزم.
كل خطوة commit منفصل؛ رجوع كامل في ثواني.
الخطة دي بتحقّق طلبك (الاعتماد على الباك بدل الفرونت) بأمان. أنا جاهز أبدأ بـمرحلة 1 (إكمال حقول النتائج الخاصة) + مرحلة 2 (الهارنس) — كلها offline، الـlab مايتأثرش — وأرجّعلك نتيجة التطابق بالأرقام قبل أي لمسة فرونت. توافق على المسار ده؟