fix(custom-fields): reject over-long STRING values and reload help after publication #61

Merged

james.maes merged 1 commits from fix/custom-field-length-and-help-20261106 into develop 2026-11-06 15:32:04 +00:00

Conversation 0 Commits 1 Files Changed 4

+66 -2

james.maes commented 2026-11-06 14:40:17 +00:00

Owner

Copy link

Copy source

What Forge observed

GG Forge runs Collaboration from source 8f348daf and has been carrying two local patches:

1. A bounded STRING custom field (maxLength set on the definition) accepted writes longer than its maximum. QQQ's default ValueTooLongBehavior is PASS_THROUGH, and CustomFieldsProvider set maxLength without a behavior, so the over-long value went through unchecked.
2. Help content stored in helpContent for a section created by publishing a custom-field definition (for example table:document;section:customFields) did not appear until restart: the runtime metadata overlay created the section after startup help loading had already run.

The fix

• CustomFieldsProvider.field: a STRING field with a maxLength carries ValueTooLongBehavior.ERROR, so the write is rejected with a field error and the stored value is preserved.
• FeatureSettingsCustomizer.refresh: after RuntimeMetaDataOverlay.refresh (immediately, or inside the after-commit callback of the originating transaction) call QInstanceHelpContentManager.reloadHelpContent(instance) so persisted help binds to the newly created sections and fields.
• CHANGELOG entries under Unreleased / Fixed.

Both APIs exist in the pinned qqq-bom-pom 4.1.0-RC.15. Adaptation from the carried patch: inline fully-qualified names were replaced with imports; no logic changes.

Test evidence

Two regressions in CustomFieldsTest:

• publishedStringRejectsValuesBeyondItsMaximumLength: a 5-character bound accepts valid, rejects too long with errors, and the persisted value is still valid.
• publishedSectionReceivesStoredHelp: a helpContent row keyed to table:document;section:customFields is present on the section after publishing a definition.

./mvnw verify on this branch (Windows, JDK 21, no Docker needed by any suite): Checkstyle clean, Tests run: 164, Failures: 0, Errors: 0, Skipped: 0, JaCoCo All coverage checks have been met, BUILD SUCCESS. CustomFieldsTest ran 10 tests including both new ones.

Carried locally by GG Forge as collaboration-custom-fields.patch (supersedes collaboration-field-length.patch). Once released, Forge can drop the 0.1.0-forge.8f348daf324d-* development builds for this fix.

🤖 Generated with Claude Code

## What Forge observed GG Forge runs Collaboration from source `8f348daf` and has been carrying two local patches: 1. A bounded STRING custom field (`maxLength` set on the definition) accepted writes longer than its maximum. QQQ's default `ValueTooLongBehavior` is `PASS_THROUGH`, and `CustomFieldsProvider` set `maxLength` without a behavior, so the over-long value went through unchecked. 2. Help content stored in `helpContent` for a section created by publishing a custom-field definition (for example `table:document;section:customFields`) did not appear until restart: the runtime metadata overlay created the section after startup help loading had already run. ## The fix - `CustomFieldsProvider.field`: a STRING field with a `maxLength` carries `ValueTooLongBehavior.ERROR`, so the write is rejected with a field error and the stored value is preserved. - `FeatureSettingsCustomizer.refresh`: after `RuntimeMetaDataOverlay.refresh` (immediately, or inside the after-commit callback of the originating transaction) call `QInstanceHelpContentManager.reloadHelpContent(instance)` so persisted help binds to the newly created sections and fields. - CHANGELOG entries under Unreleased / Fixed. Both APIs exist in the pinned `qqq-bom-pom 4.1.0-RC.15`. Adaptation from the carried patch: inline fully-qualified names were replaced with imports; no logic changes. ## Test evidence Two regressions in `CustomFieldsTest`: - `publishedStringRejectsValuesBeyondItsMaximumLength`: a 5-character bound accepts `valid`, rejects `too long` with errors, and the persisted value is still `valid`. - `publishedSectionReceivesStoredHelp`: a `helpContent` row keyed to `table:document;section:customFields` is present on the section after publishing a definition. `./mvnw verify` on this branch (Windows, JDK 21, no Docker needed by any suite): Checkstyle clean, `Tests run: 164, Failures: 0, Errors: 0, Skipped: 0`, JaCoCo `All coverage checks have been met`, BUILD SUCCESS. `CustomFieldsTest` ran 10 tests including both new ones. Carried locally by GG Forge as `collaboration-custom-fields.patch` (supersedes `collaboration-field-length.patch`). Once released, Forge can drop the `0.1.0-forge.8f348daf324d-*` development builds for this fix. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

james.maes added 1 commit 2026-11-06 14:40:18 +00:00

fix(custom-fields): reject over-long STRING values and reload help after publication ... ef625ca300

Bounded STRING custom fields now carry QQQ's native ValueTooLongBehavior.ERROR,
so a write longer than maxLength is rejected with a field error and the stored
value is preserved. The QQQ default is PASS_THROUGH, which let over-long values
through unchecked.

After the runtime metadata overlay refreshes (immediately, or in the after-commit
callback of the originating transaction), persisted help content is reloaded so
sections and fields created by publishing a definition receive their stored
helpContent rows without a restart.

Two CustomFieldsTest regressions cover invalid-write preservation and stored
help on a newly published section. Carried locally by GG Forge as
collaboration-custom-fields.patch (supersedes collaboration-field-length.patch).

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Signed-off-by: James Maes <james@kof22.com>

james.maes merged commit 483dc271fe into develop 2026-11-06 15:32:03 +00:00

Sign in to join this conversation.

Reviewers

No Reviewers

Labels

Clear labels

architecture

Architecture review: coupling, cohesion, UI API

bug

Something isn't working

dependencies

documentation

Improvements or additions to documentation

duplicate

This issue or pull request already exists

enhancement

New feature or request

github_actions

Pull requests that update GitHub Actions code

good first issue

Good for newcomers

help wanted

Extra attention is needed

invalid

This doesn't seem right

java

Pull requests that update java code

question

Further information is requested

secuurity

wontfix

This will not be worked on

No labels

Milestone

No items

No Milestone

Projects

Clear projects

No projects

Assignees

Clear assignees

forge-recovery (Forge Recovery) james.maes (James Maes)

No Assignees

1 Participants

Notifications

Subscribe

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: QRun-IO/qbit-collaboration#61