[sleidig]

Since multi-lingual systems were added (Aam-Digital/ndb-core#4283), configured texts can be stored as objects of translations (e.g. {"en-US": "Action", "de": "Aktion"}) instead of plain strings. The backend still read some of them as String, which broke every report calculation:

Cannot deserialize value of type `java.lang.String` from Object value (token `JsonToken.START_OBJECT`)
(through reference chain: ...AppConfigFile["data"]->java.util.LinkedHashMap["entity:Action"]->...AppConfigEntry["label"])

Changes

• SQS schema (the crash): AppConfigEntry no longer maps label. It was never used, because table names come from the entity: key.
• ConfigurableEnumOption view: a multi-lingual option label now resolves to one text. It uses the system's default language (SiteSettings:global.defaultLanguage), then English, then any non-empty translation. Plain string labels are unchanged.
  • To support this, a SiteSettings table (_id, defaultLanguage) is hard-wired into the SQS schema. Its fields are merged into a manually configured entity:SiteSettings instead of replacing it.
• ReportConfig.title and TemplateExport.title/description: ndb-core now stores these as translatable texts too. They would hit the same parsing error once someone translates a title, so they now resolve to a single text (English first, otherwise any translation) through a shared TranslatableTextDeserializer.
• Legacy ReportConfig write-back: now writes back the original title value, so a migrated document keeps all of its translations.

Notes

• The schema (configVersion) changes, so SQS re-ingests once after deployment. The first report calculation afterwards will be slower.
• The view SQL was checked against SQLite with these cases: default language set, not set, or missing from the translations; plain string labels; empty translations; options without a label.
• I assumed SQS stores SiteSettings.defaultLanguage as plain text (e.g. de). If it doesn't, the view falls back to English labels.
• Follow-up: the reporting docs in ndb-core (src/app/features/reporting/README.md) could mention how labels are resolved in multi-lingual systems.

Manual Testing Steps

1. In a multi-lingual system (entity labels stored as translation objects), trigger a report calculation. It should succeed instead of failing with the error above.
2. Run a report that joins ConfigurableEnumOption on a dropdown with translated options. label should show the option text in the system's default language.
3. Give a SQL report and an export template a translated title. Loading and running them should work.

Tests

• Unit tests added for: parsing a config with translated labels, the SiteSettings table (with and without a configured entity), TranslatableText resolving, a multi-lingual report title, and the legacy write-back keeping translations.
• The full unit test suite passes locally, apart from the 4 Testcontainers tests (Keycloak, Cucumber), which need Docker and could not run in this environment. ktlint passes.

---

Generated by Claude Code

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

Run configuration

• Source mode: Auto
• Repository: Aam-Digital/aam-services
• Branch: claude/fervent-mendel-37rxie
• File: .coderabbit.yaml
• Commit: 0e7e522
• Layers: Repository YAML
• Review profile: CHILL
• Plan: Advanced
• Run ID: df7c7dc4-6d69-42a4-9396-8d78b43fe4e5

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

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.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[Abhinegi2]

tested it, and everything seems to be working well, code also looks good.
@sleidig only one small notes, not blocking -

• titles resolve english-first, while enum labels use defaultLanguage. In a German-default system the two can differ (fine if intended )

[sleidig]

Thanks for testing! Re: titles resolving English-first while enum labels use defaultLanguage. This is intended:

• Report title: the backend only uses it as the name field of the /reports API. ndb-core doesn't read that field and shows its own ReportConfig.title.
• Export template title/description: parsed, but not used anywhere in the backend.
• Enum labels: these end up in the report results users see, so they follow the system's default language.

Making titles follow the default language as well would need the backend to read SiteSettings for those API responses, which isn't worth it for a field nobody displays.

If a title has no English translation, it falls back to the first non-empty translation (covered in TranslatableTextTest). If every translation is empty, it becomes an empty string, so parsing never fails.

---

Generated by Claude Code