الطلب LR-2026-00302: البنل فيه عنصرين (HbA1c + eAG)، بس eAG مش ظاهر خالص في الورك ليست والفاليديشن. ده تحليل لـ«إيه اللي وصل، ليه مظهرش، إيه السبب الجذري، وإزاي نحلّها بشكل نهائي علشان متتكررش».
أول حاجة طمأنينة: مفيش داتا ضايعة. النتيجتين موجودين في قاعدة البيانات وصح:
| العنصر | نوعه | القيمة | الحالة | العينة |
|---|---|---|---|---|
| HBA1C0 (HbA1c) inv 9 | رقمي (مقاس) | 9.0 | released | 231 |
| eAG inv 3924 | معادلة (formula) | 211.6 | released | 231 |
eAG = (28.7 × {HBA1C0}) − 46.7 = (28.7 × 9.0) − 46.7 = 211.6 ✓. يعني العنصر اتحسب اتخزّن اترِليز — المشكلة في العرض بس، مش في الداتا.
الورك ليست/الفاليديشن بيجمّعوا عناصر البنل تحت رأس البنل بناءً على «نَسب» (panel ancestry) بييجي من الـAPI (/lis/sample-investigations). دي القيم اللي رجعت فعلياً للطلب ده:
| العنصر | الـAPI رجّع إنه تابع لبنل… | صح؟ |
|---|---|---|
| HBA1C0 (9) | HBA1C602 (2764) — is_panel=1 | صح |
| eAG (3924) | HBA1C0 (9) — is_panel=0 ❌ | غلط |
الـeAG اتحطّ تحت «بنل HBA1C0» — وHBA1C0 أصلاً مش بنل (is_panel=0)، يعني مفيش رأس بنل بيترسم ليه. فالـeAG بيقع تحت رأس وهمي مش بيظهر → العنصر بيختفي تماماً. (في الفاليديشن فيه فلتر isPanelMemberVisible بيخفي أي عنصر مالقاش رأس بنله؛ وفي الـdept-worklist العنصر أصلاً مابيتضافش للعرض غير جوّه لوب رأس البنل.)
eAG عضو في بنلين في قاعدة البيانات، مش بنل واحد:
الـeAG هو «الرفيق المحسوب» للـHbA1c، فاتسجّل زمان كـ«عضو» جوّه HBA1C0 (علشان يتحسب منه). بعدها اتعمل بنل HBA1C602 الحقيقي اللي بيلفّ الاتنين — بس العضوية القديمة (eAG داخل HBA1C0) فضلت موجودة.
دالة loadPanelMap بتاخد العضو، تلاقيه في بنلين الاتنين «مربوطين» بالطلب (HBA1C0 و HBA1C602 الاتنين متطلبين)، وبتختار أول واحد في ترتيب الصفوف = HBA1C0 (9) — من غير ما تتأكد إنه بنل حقيقي (is_panel=1). فاختارت بنل وهمي.
فحصت القاعدة كلها — ده نمط متكرر مش استثناء:
| الفئة | العدد | أمثلة |
|---|---|---|
| عضويات «شاردة» لأب مش بنل (is_panel=0) | 7 صفوف | HBA1C0←eAG · COAG←(6,28,29) · IRON←(47,48,49) |
| عناصر في أكتر من بنل (نَسب ملتبس) | 13 عنصر | UREA/CREAT (RFT+KFT) · TSH/FT4/FT3 (THYROID+THYROI) · NA/K (RFT+ELEC) · eAG… |
أي عنصر عنده عضوية لأب is_panel=0 (أو بيتلخبط بين بنلين)، معرّض إنه يختفي بنفس الطريقة. لازم الحل يكون جذري على مستوى المنطق، مش تصليح يدوي لكل حالة.
علشان نحلّها نهائياً ومتتكررش، مقترح 3 طبقات تكمّل بعض (الأولى تكفي للإصلاح، والباقي حماية وتنظيف):
في loadPanelMap نخلّي النَسب يتاخد من البنلات الحقيقية بس (is_panel=1). كده HBA1C0 (is_panel=0) يتشال من الحسبة خالص، والـeAG ميبقاش ليه غير بنل واحد = HBA1C602 ✓.
الأثر: بيصلّح eAG + كل الـ7 حالات الشاردة دفعة واحدة. مفيش أي عنصر هيتنسب لأب مش بنل تاني.
قاعدة ذهبية: أي نتيجة ليها قيمة مينفعش تختفي خالص. لو عنصر بنل ملقاش رأس بنله في العرض → يترسم كـعنصر مستقل (standalone) بدل ما يتلغي بصمت. ده بيقفل كل فئة «الاختفاء الصامت» حتى لو فيه عيب بيانات تاني في المستقبل. (يتطبّق في validation-worklist و dept-worklist.)
نشيل/نصلّح الـ7 عضويات الشاردة (العنصر اللي أبوه is_panel=0). للـeAG: العلاقة دي «رفيق محسوب» مش بنل — مكانها مش panel_members. ولو COAG/IRON المفروض بنلات فعلاً → نظبّط is_panel=1 عليهم. (مع الطبقة 1+2 دي بقت اختيارية للنظافة بس.)
الطبقة 1 + 2 مع بعض (إصلاح جذري + حماية دائمة). الطبقة 3 تنظيف نعمله بعدها على راحتنا. مفيش أي تغيير في شكل الشاشات — بس العناصر هتبان صح.
الاتنين تحت رأس HBA1C602 الصح، والـeAG يظهر بقيمته 211.6.
->where('p.is_panel', 1) اتطبّقت واترفعت — الـAPI بيرجّع دلوقتي eAG ← HBA1C602 ✓دلوقتي eAG (211.6) هيظهر تحت HBA1C602 جنب HbA1c في الورك ليست والفاليديشن. (اعمل refresh للصفحة.)