Add WebConfig with Instant to String converter and update templates for consistent date formatting#107
Conversation
…ates for consistent date formatting
|
Warning Rate limit exceeded
To keep reviews running without waiting, you can enable usage-based add-on for your organization. This allows additional reviews beyond the hourly cap. Account admins can enable it under billing. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (2)
📝 WalkthroughWalkthroughThis PR introduces a Spring configuration class that registers a global type converter for formatting Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (2)
src/main/java/org/example/projektarendehantering/infrastructure/config/WebConfig.java (1)
14-15: Consider externalizing the timezone (and pattern) to configuration.Hardcoding
Europe/Stockholmworks for this deployment, but binds presentation policy to source. Exposing it as a property (e.g.app.display.zone,app.display.datetime-pattern) makes it trivially adjustable per-environment and clearer in intent.♻️ Suggested refactor
- private static final DateTimeFormatter DISPLAY_FORMAT = - DateTimeFormatter.ofPattern("yyyy-MM-dd HH:mm").withZone(ZoneId.of("Europe/Stockholm")); - - `@Bean` - public Converter<Instant, String> instantToStringConverter() { - return DISPLAY_FORMAT::format; - } + `@Bean` + public Converter<Instant, String> instantToStringConverter( + `@Value`("${app.display.datetime-pattern:yyyy-MM-dd HH:mm}") String pattern, + `@Value`("${app.display.zone:Europe/Stockholm}") String zone) { + DateTimeFormatter formatter = DateTimeFormatter.ofPattern(pattern).withZone(ZoneId.of(zone)); + return formatter::format; + }🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/main/java/org/example/projektarendehantering/infrastructure/config/WebConfig.java` around lines 14 - 15, The DISPLAY_FORMAT DateTimeFormatter is hardcoded to "yyyy-MM-dd HH:mm" and ZoneId.of("Europe/Stockholm"); change this to read two config properties (e.g. app.display.datetime-pattern and app.display.zone) with sensible defaults, remove the static final constant and instead build the DateTimeFormatter at runtime (e.g. in WebConfig constructor or a `@Bean` factory) using DateTimeFormatter.ofPattern(pattern).withZone(ZoneId.of(zone)), and use `@Value` or Environment to inject the properties so presentation pattern and timezone can be adjusted per-environment; keep the symbol names DISPLAY_FORMAT and WebConfig to locate the change.src/main/resources/templates/cases/detail.html (1)
103-103: Minor inconsistency: no null guard ondoc.uploadedAt.
note.createdAt(line 78) is rendered with ath:if="${note.createdAt != null}"guard, butdoc.uploadedAthere has none. TheConversionServicedoes treatnullasnull(so this won't NPE — the cell would just render empty), but for visual consistency with the notes section, consider mirroring the same guard, or drop the guard from line 78 ifnote.createdAtis in fact nevernull.♻️ Suggested change
- <span th:text="${{doc.uploadedAt}}">Date</span> + <span th:if="${doc.uploadedAt != null}" th:text="${{doc.uploadedAt}}">Date</span>🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/main/resources/templates/cases/detail.html` at line 103, The template is inconsistent: doc.uploadedAt is rendered without a null guard while note.createdAt uses th:if="${note.createdAt != null}"; update the template to mirror the notes behavior by adding the same conditional guard around the doc.uploadedAt span (or alternatively remove the th:if from note.createdAt if you can guarantee note.createdAt is never null) so both date renderings use the same null-handling approach; target the span rendering doc.uploadedAt and the span for note.createdAt when making the change.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In
`@src/main/java/org/example/projektarendehantering/infrastructure/config/WebConfig.java`:
- Around line 14-20: The template audit/list.html currently formats e.occurredAt
with "#temporals.format(e.occurredAt, 'yyyy-MM-dd HH:mm:ss', 'UTC')" which
conflicts with the new application-wide DISPLAY_FORMAT and
instantToStringConverter (yyyy-MM-dd HH:mm, Europe/Stockholm); if e.occurredAt
is an Instant, replace the inline formatter with the unified rendering by
changing the template to output ${e.occurredAt} so it uses
instantToStringConverter, otherwise if seconds/UTC are intentionally required
for audit traceability, add a clear comment above the template line explaining
why the inline '#temporals.format(..., "yyyy-MM-dd HH:mm:ss", "UTC")' is
deliberately different to avoid future confusion.
---
Nitpick comments:
In
`@src/main/java/org/example/projektarendehantering/infrastructure/config/WebConfig.java`:
- Around line 14-15: The DISPLAY_FORMAT DateTimeFormatter is hardcoded to
"yyyy-MM-dd HH:mm" and ZoneId.of("Europe/Stockholm"); change this to read two
config properties (e.g. app.display.datetime-pattern and app.display.zone) with
sensible defaults, remove the static final constant and instead build the
DateTimeFormatter at runtime (e.g. in WebConfig constructor or a `@Bean` factory)
using DateTimeFormatter.ofPattern(pattern).withZone(ZoneId.of(zone)), and use
`@Value` or Environment to inject the properties so presentation pattern and
timezone can be adjusted per-environment; keep the symbol names DISPLAY_FORMAT
and WebConfig to locate the change.
In `@src/main/resources/templates/cases/detail.html`:
- Line 103: The template is inconsistent: doc.uploadedAt is rendered without a
null guard while note.createdAt uses th:if="${note.createdAt != null}"; update
the template to mirror the notes behavior by adding the same conditional guard
around the doc.uploadedAt span (or alternatively remove the th:if from
note.createdAt if you can guarantee note.createdAt is never null) so both date
renderings use the same null-handling approach; target the span rendering
doc.uploadedAt and the span for note.createdAt when making the change.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 1bbb4ac7-7dd2-44cd-8e77-3554c7e377f4
📒 Files selected for processing (6)
src/main/java/org/example/projektarendehantering/infrastructure/config/WebConfig.javasrc/main/resources/templates/cases/closed.htmlsrc/main/resources/templates/cases/detail.htmlsrc/main/resources/templates/cases/list.htmlsrc/main/resources/templates/employees/list.htmlsrc/main/resources/templates/patients/list.html
2 participants
Summary by CodeRabbit