Skip to content

[MODEUSCNT-69] Use order-insensitive comparison for R5.1 report attribute arrays#103

Merged
alb3rtino merged 1 commit into
masterfrom
MODEUSCNT-69
Feb 26, 2026
Merged

[MODEUSCNT-69] Use order-insensitive comparison for R5.1 report attribute arrays#103
alb3rtino merged 1 commit into
masterfrom
MODEUSCNT-69

Conversation

@alb3rtino

Copy link
Copy Markdown
Collaborator

https://folio-org.atlassian.net/browse/MODEUSCNT-69

Purpose

The ReportValidator.validateReportHeaderReportAttributes() method uses an order-sensitive comparison (equals) when checking report attributes against expected values. This causes valid reports to be rejected when a provider returns the Attributes_To_Show array elements in a different order than what is defined in ReportProperties. For example, a TR report expecting ["YOP", "Access_Type", "Access_Method"] would fail validation if a provider returns ["Access_Method", "YOP", "Access_Type"], even though the content is identical.

Approach

  • Replaced the direct equals comparison with a new reportAttributesMatch method that compares object fields individually, using set-based comparison for array values via arrayEqualsIgnoreOrder
  • Added a parameterized test covering TR, DR, IR, and PR report types that reverses the Attributes_To_Show array order and verifies validation still passes

@alb3rtino alb3rtino requested a review from slaemmer February 24, 2026 15:10
@alb3rtino alb3rtino changed the title [MODEUSCNT-69] R5.1 report validation rejects valid reports when Attributes_To_Show array order differs from expected [MODEUSCNT-69] Use order-insensitive comparison for R5.1 report attribute arrays Feb 25, 2026
@sonarqubecloud

Copy link
Copy Markdown

@alb3rtino alb3rtino merged commit 26d3d61 into master Feb 26, 2026
28 checks passed
@alb3rtino alb3rtino deleted the MODEUSCNT-69 branch February 26, 2026 19:18
alb3rtino added a commit that referenced this pull request Mar 11, 2026
…ic (#105)

https://folio-org.atlassian.net/browse/MODEUSCNT-70

## Purpose

The report merging logic in both COUNTER 5.0 and 5.1 modules performs
order-sensitive comparisons on report header attributes. This causes
merge failures when attribute arrays or pipe-delimited values appear in
different orders across reports that are otherwise equivalent. The
validation code paths were already fixed in #103 and
[mod-erm-usage#212](folio-org/mod-erm-usage#212),
but the merging code paths were not covered.

## Approach

- COUNTER 5.1 `ReportMerger`: Apply `ReportValidator.normalize()` to
report headers before the distinctness check during merge validation.
Made `normalize()` package-private and added recursion into nested
objects so it handles the full header structure.
- COUNTER 5.0 `ReportsMerger`: Replace `distinct()` with a
`distinctByNormalized()` predicate that normalizes pipe-delimited values
(split, sort, rejoin) before deduplication, applied to both report
attributes and report filters.
- Added tests in both modules covering merge scenarios with reordered
attributes.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants