fix CpoName rendering on charge point detail page

[goekay]

after #2039, CpoName is not a standalone column anymore. therefore, ChargeBoxRecord.getCpoName() does not exist. we need to get it out of ChargeBoxRecord.getOcppConfiguration()

[qodo-free-for-open-source-projects]

Review Summary by Qodo

Fix CpoName rendering by extracting from OCPP configuration

🐞 Bug fix

Walkthroughs

Description

• Extract CpoName from OCPP configuration JSON instead of direct column
• Add getCpoName() method to ChargePoint.Details class
• Parse OCPP configuration safely with null checks
• Update JSP view to use new getCpoName() method

Diagram

flowchart LR
  A["ChargeBoxRecord.ocppConfiguration"] -->|"parse JSON"| B["ObjectNode"]
  B -->|"extract CpoName key"| C["String value"]
  D["ChargePoint.Details.getCpoName()"] -->|"calls"| E["getConfigValueSafely()"]
  E -->|"returns"| C
  F["JSP view"] -->|"calls"| D
  F -->|"displays"| C

Loading

File Changes

1. src/main/java/de/rwth/idsg/steve/repository/dto/ChargePoint.java 🐞 Bug fix +24/-0

Add CpoName extraction from OCPP configuration JSON

• Added imports for JSON parsing and configuration key enum
• Implemented getCpoName() method in Details inner class
• Added getConfigValueSafely() helper method to parse OCPP configuration JSON
• Safely extracts configuration values with null checks at each step

src/main/java/de/rwth/idsg/steve/repository/dto/ChargePoint.java

---

2. src/main/webapp/WEB-INF/views/data-man/chargepointDetails.jsp 🐞 Bug fix +1/-1

Update CPO Name field to use new getter method

• Changed CPO Name field reference from cp.chargeBox.cpoName to cp.cpoName
• Updated to use new getCpoName() method from ChargePoint.Details class

src/main/webapp/WEB-INF/views/data-man/chargepointDetails.jsp

---

[qodo-free-for-open-source-projects]

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (0) 📎 Requirement gaps (0)

1. readTree(value.data()) lacks validation ✓ Resolved 📘 Rule violation ☼ Reliability

Description

ChargePoint.Details#getConfigValueSafely parses chargeBox.getOcppConfiguration().data() via
mapper.readTree(...) without checking for null/blank content and without handling JSON parsing
failures, which can throw at runtime during page rendering. This violates input-validation and
error-semantics expectations because malformed/empty persisted configuration can propagate as an
externally visible 500-style failure instead of a controlled outcome.

Code

src/main/java/de/rwth/idsg/steve/repository/dto/ChargePoint.java[R56-64]

+        private static String getConfigValueSafely(ChargeBoxRecord chargeBox, String key) {
+            var value = chargeBox.getOcppConfiguration();
+            if (value == null) {
+                return null;
+            }
+
+            var mapper = JsonObjectMapper.INSTANCE.getMapper();
+            var node = mapper.readTree(value.data());
+            if (!node.isObject()) {

Evidence

PR Compliance ID 1 calls for null/blank checks on externally supplied or nested values prior to use,
but the code dereferences value.data() and attempts to parse it without validating it. PR
Compliance ID 2 requires avoiding generic 500-style failures and non-leaking error behavior; because
readTree(...) is invoked without a try/catch and the getter is evaluated during JSP rendering
(e.g., ${cp.cpoName}), any parse-time exception will surface as a view-render error. This risk is
reinforced by other code in the codebase treating readTree(...) as throwable (e.g., by declaring
throws JacksonException at another call site).

src/main/java/de/rwth/idsg/steve/repository/dto/ChargePoint.java[56-70]
src/main/java/de/rwth/idsg/steve/repository/dto/ChargePoint.java[52-71]
src/main/webapp/WEB-INF/views/data-man/chargepointDetails.jsp[99-103]
src/main/java/de/rwth/idsg/steve/ocpp/ws/custom/MeterValue15Deserializer.java[46-56]
Best Practice: Learned patterns
Best Practice: Learned patterns

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`ChargePoint.Details#getConfigValueSafely` calls `mapper.readTree(value.data())` on persisted `ocppConfiguration` content without validating that the JSON string is non-null/non-blank and without catching parse exceptions. If the stored configuration is empty or malformed/unexpected, the getter can throw during view evaluation and cause an externally visible 500-style failure.
## Issue Context
This getter is used directly by the charge point details view via JSP expressions (e.g., `${cp.cpoName}`), so runtime exceptions during JSON parsing will bubble up as page-rendering failures. The project also has other usage that acknowledges `readTree(...)` is throwable (e.g., declaring `throws JacksonException`), underscoring the need for explicit error handling here.
## Fix Focus Areas
- src/main/java/de/rwth/idsg/steve/repository/dto/ChargePoint.java[52-71]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---