DIGI-UW/OpenELIS-Global-2

Affected Component / Area Frontend (React / Carbon UI) 👾 Description of the Issue When setting a custom logo under Admin > Site Branding > Login Page Logo, the custom logo displays as expected, but there is a noticeable issue with how the logo renders during initial page load and periodic background updates. Steps to Reproduce Log in as an Administrator and upload a custom logo under Admin > Site Branding. Save changes and log out to navigate to the Login page (/login). Refresh the browser page (F5 or Ctrl+R). Observe the logo container on the login page. Expected Behavior The custom uploaded site logo should render directly on initial page load and remain statically displayed without flickering. Actual Behavior Initial Page Load: Upon refreshing or navigating to the login page, the default/original OpenELIS logo flashes briefly for a microsecond before being replaced by the custom uploaded logo. Periodic Flashing: Every few seconds, the logo flashes back to the original OpenELIS lo

Affected Component / Area Testing (JUnit / Playwright / Cypress) 👾 Description of the Issue Seven test classes extend BaseWebContextSensitiveTest, which boots a full Spring context and a PostgreSQL container on every run. None of these seven classes use @Autowired, load fixture data, or interact with the database in any way — they test pure Java logic. Extending the heavy base class for them adds unnecessary startup time to the suite and sets a bad example for contributors who copy these files as a starting point for new tests. Files affected (one PR can cover all 7): File What it actually tests AnalyzerFhirImportControllerTest Pure controller mapping logic SamplePatientUpdateDataSamplingSiteTest Sampling site field validation SamplePatientUpdateDataValidateTest validateSample field-error type NonConformityRecordNumberValidationProviderTest String validation logic ProviderIdParameterIntegrationTest Provider ID parameter parsing AuthenticatedAnalyzerControllerTest

Affected Component / Area Testing (JUnit / Playwright / Cypress) 👾 Description of the Issue The codebase has at least 3 different test patterns in use with no written rule explaining when to use which. New contributors pick the wrong base class by copying nearby tests. Patterns in the codebase Pattern Base class When to use Full DB integration extends BaseWebContextSensitiveTest Service, DAO, or controller tests that need a real DB Security slice extends SecuritySliceMockMvcTest Controller tests that verify auth/role enforcement Standalone MockMvc @RunWith(MockitoJUnitRunner.class) + standaloneSetup Controller tests that verify response shape without DB Plain JUnit No runner Pure logic, no Spring, no DB 💡 Proposed Solution Add a section to CONTRIBUTING.md titled ## Backend Test Patterns with a table like the one above, one example snippet per pattern, and a rule of thumb: If the test doesn't query the database, it should not extend BaseWebContextSensitiveTest.

Discovered via: CI failure on feat/OGC-1142-panel-management-m1-schema after rebasing onto develop (commit range from git pull on 2026-08-12). Failing Tests ResultEntryRestControllerTest.save_withInterpretation_writesReportVisibleNote:545 Status expected:<200> but was:<500> ResultEntryRestControllerTest.save_interpretationFromComponentRow_isScopedToThatComponent:709 Status expected:<200> but was:<500> These tests are new tests added to develop and were not present before the recent merge. Investigation confirms the failures are not caused by the OGC-1142 schema changes. Root Cause Analysis Two distinct errors are thrown during the save path (POST /rest/results-entry/analysis/{id}/result): Bug 1 — NoteServiceImpl: Duplicate interpretation note rejected ERROR — Class: org.openelisglobal.note.service.NoteServiceImpl Method: insert, Line: 416 Message: Duplicate record exists for E NoteServiceImpl.insert() calls duplicateNoteExists() before persisting. The duplicate check in Not

Running the full integration test suite (4692 tests) produces 2 failures and 6 errors, preventing a successful BUILD SUCCESS. Additionally, the jacoco Maven profile referenced in local tooling does not exist in the project's pom.xml, so coverage reports cannot be generated using -Pjacoco. Environment Item Value Branch develop Command mvn clean verify Total Time 23m 27s Result Tests run: 4692, Failures: 2, Errors: 6, Skipped: 3 Test Failures 1. OrderEntryLabelRequestServiceAggregationTest ac13_columnOrdering_systemFirstThenCustomAlphabetical (line 297) Assertion failed: at least one system sample column present (universal Specimen) fr014a_seededSpecimenLabel_isSampleColumn_onNoLinkOrder (line 255) Assertion failed: 032 must mark the seeded Specimen Label universal Observation Both failures point to the same area of functionality: Sample/label classification The seeded "Specimen" label is not being recognized as a universal/system sample column as expected. Test E