claimrevolution/oe-module-claimrev-connect

Fix so enabling the module no longer blanks the Patient Portal / API panel on the patient dashboard (or fatals the claims/ERA/payment pages) on OpenEMR 8.0.x. Completes the 2.1.4 KernelCompat migration — eleven getKernel() call sites in templates/eligibility.php and the public/*.php entry points were still calling the method that doesn't exist on 8.0.x — and adds a try/catch (\Throwable) fault boundary around the eligibility section so a render fault can never blank adjacent core panels again. Verified on the 8.0.0.3 test container.

Full Changelog: v2.1.6...v2.1.7

Fix — enabling the module blanked the Patient Portal / API panel on the patient dashboard (and fatalled other pages) on OpenEMR 8.0.x:

• 2.1.4 moved kernel resolution to Compat\KernelCompat::resolve() to avoid the direct OEGlobalsBag::getInstance()->getKernel() call that fatals on 8.0.x (core's OEGlobalsBag there has no getKernel()), but that migration only covered the src/ service layer. Eleven call sites still called getKernel() directly: templates/eligibility.php and ten public/*.php entry points (claims, claim_requeue, claim_status, claim_sync_status, eligibility_chat, era, EraDownload, payment_advice, payment_advice_post, reconciliation). On 8.0.x these still threw "Call to undefined method OEGlobalsBag::getKernel()". The eligibility template renders inside the core demographics page via a RenderEvent listener (Bootstrap::renderEligibilitySection), so its fatal aborted the whole page render and the Patient Portal / API panel — emitted after it — vanished; disabling the module made the panel reappear. Reported by a client on 8.0.x.
• Fix: route all eleven remaining call sites through KernelCompat::resolve()->getEventDispatcher(), completing the 2.1.4 migration. Verified on the 8.0.0.3 test container (patient dashboard renders, Portal/API panel present, eligibility section loads).
• Defense in depth: wrap the eligibility-section include in Bootstrap::renderEligibilitySection in a try/catch (\Throwable) fault boundary. A render fault in the module's demographics panel now logs via error_log and degrades to an inline notice instead of blanking adjacent core panels — the same isolation rationale as the 2.1.5 calendar fix. (\Throwable, not \Exception, since an undefined-method fatal is an Error.)

Fix for css on calendar not showing appointments in some views.

Full Changelog: v2.1.5...v2.1.6

Fix — appointments invisible in calendar week/day view when eligibility indicators are enabled:

• A second, independent defect in the calendar eligibility indicator (distinct from the 2.1.5 crash fix). The day/week calendar template treats an event's eventViewClass as a full replacement for the core CSS class ($evtClass = $event['eventViewClass'] ?? $evtClass in views/day/ajax_template.html), not an addition. The core class for an appointment is event_appointment, which in ajax_calendar_sass.scss supplies z-index: 2 and background-color: white. CalendarEligibilityIndicator::filterCalendarEvents set eventViewClass to only the eligibility class (e.g. event_elig_active), so the appointment <div> lost event_appointment and dropped behind the calendar grid — appointments appeared to vanish in week and day view (month view uses a different template and was unaffected). Reported by a provider who traced it to the event div losing its z-index.
• Fix: mergeEventViewClass now preserves a base class — the existing eventViewClass if another listener set one, otherwise event_appointment — and appends the eligibility class to it, so the appointment keeps its stacking and fill while still getting the eligibility border.

v2.1.5 - calendar indicator fault boundary; appointments can no longe…

…r be blanked by the eligibility indicator

Critical fix — installing the module could make all calendar appointments disappear:

• The calendar eligibility indicator (CalendarEligibilityIndicator::filterCalendarEvents, enabled by "Enable Calendar Eligibility Indicators") listens on OpenEMR's CalendarUserGetEventsFilter. Core dispatches that filter inside postcalendar_userapi_pcGetEvents() with no error handling, then returns whatever the listeners produce. The listener ran an unguarded SELECT ... FROM mod_claimrev_eligibility (referencing payer_responsibility, last_checked, create_date, individual_json, status). On an install whose mod_claimrev_eligibility schema was out of date (missing column) or otherwise unhappy, that query threw — and because core has no try/catch around the dispatch, the exception aborted the whole calendar event fetch, so every appointment vanished from the calendar. Disabling the module removed the listener and the appointments reappeared, which is why the symptom looked like the module was deleting appointments. It never touched appointment data.
• Fix: wrap the indicator logic in a fault boundary. A cosmetic color indicator must never be able to remove appointments, so filterCalendarEvents now delegates to applyEligibilityIndicators inside a try/catch (\Throwable); on any failure it logs via error_log and returns the events unmodified. The calendar always renders; at worst the eligibility colors are missing.

v2.1.4 — fix OE 8.0.x login 500 (KernelCompat kernel resolution)

Cross-version compatibility fix:

• Resolve the OpenEMR kernel via a new Compat\KernelCompat::resolve() helper instead of calling OEGlobalsBag::getInstance()->getKernel() directly. getKernel() only exists on core's flex/master line; the 8.0.x patch releases ship an OEGlobalsBag without it. Because the real class is present on 8.0.x, the OEGlobalsBagShim swap never activates there, so the direct call fatalled with "Call to undefined method OEGlobalsBag::getKernel()" during login bootstrap — taking the whole site to a 500. The helper reads the kernel from the 'kernel' global (with a type guard), exactly as flex's getKernel() does internally, so the same binary works on 7.x, 8.0.x, and flex. Fixes the regression introduced in 2.1.3.

v2.1.3 - cross-version (OE7+OE8) module with compat shims, security h…

Cross-version compatibility and security hardening:

• Read stored credentials with CryptoGen::decryptStandard instead of decryptFromDatabase. The newer helper was added to OE core in the 8.x line but does not exist on OE 7.x; reverting to decryptStandard lets the same module binary work on both branches.
• Close findings from the external Aisle Analyzer security review of PR #11265: tighten IDOR and CSRF gaps on AJAX endpoints, refetch ERA and claim status server-side rather than trusting the browser to echo them back, and tighten property-access hardening on several response shapes.

Test mode coverage extended to every gated page:

• ERA tab and EraDownload short-circuit to mock data when test mode is enabled, gated by the global setting (the per-tab checkbox is removed).
• Payment Advice tab reads the test-mode global directly; per-tab checkbox removed.
• Reconciliation tab returns mock rows via ReconciliationMockService.
• Eligibility Chat returns mock AI answers in test mode.
• claim_sync_status and claim_requeue short-circuit cleanly without contacting the API.
• README's test-mode coverage row documents every gated page.

Maintenance:

• Rector/PHPStan cleanups across the module.
• Fix STATUS_UPLOAD_ERROR constant typo.
• Miscellaneous narrowing of array/object access patterns flagged by PHPStan.