Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

intent: exports: fields have no text normalisation - per-file case, allowed characters, replacements and a refusal on information loss

Closed
  • Is something wrong?
#7,925 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

A pull request for this has already been merged.

  • #7999 by @nedelcho-delchev-tues — merged

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
35/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Active
Tech stack
java
Domain
backend

Research direction

The issue names engine-intent unit tests and an export integration test, but no source files or entry points. Start by locating how exports: fields are parsed and written, then trace how export run records store field values. Done means each proposed option is covered by unit tests, onLoss rejects the run with record and field details, and the integration test verifies an uppercased, stripped name column in a delimited file.

Written by the indexing model from the issue text.

Description

Problem

An exports: field writes its source value verbatim. The field options are from / literal / param, width / align / pad / truncate, scale / decimalSeparator, pattern (dates) and the XML name / attribute — there is no way to normalise text for a target file format. The run only fails when a character cannot be encoded in the target charset.

Some regulator formats accept a far narrower character set than the master data should hold. Example: the Bulgarian NRA validators for the payroll Declarations обр. 1 / обр. 6 accept only uppercase Cyrillic, digits and - in names, while the VAT-ledger validator of the same agency accepts Latin, №, „“, &, /, ., , and more. The legal name must stay as registered in the master data; each file needs its own normalisation, in one declared place, not in a Java helper per module.

Proposal

Per-field text options on exports: fields:

  • case: upper | lower
  • allowed: "<character class>" — characters outside it are handled by replace / strip
  • replace: { "№": "", "/": " " } — explicit replacements applied before allowed
  • onDisallowed: strip | space | fail (default fail, keeping the "nothing is written approximately" rule); collapseSpaces: true
  • onLoss: fail — refuse the run (recorded FAILED, 422) naming the record and field when normalisation changed more than case, punctuation and whitespace — e.g. a Latin-script value written into a Cyrillic-only field — instead of writing a value nobody typed.

The run record keeps the original and the written value for every field that was normalised, so a rejected upload can be traced back to the record.

Verify

Unit tests in engine-intent for each option and the onLoss refusal; one export IT writing a delimited file with an uppercased/stripped name column.

Dominant language
Java
Stars
278
Forks
97
Avg merge
18h 57m
Merged PRs (30d)
249

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from eclipse-dirigible/dirigible

All issues in eclipse-dirigible/dirigible

Similar issues

More Java issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.