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

intent: a to-one relation picked on create and fixed afterwards (editable on the New form, 409 on a changed value in an update)

Open
  • Is something wrong?
#7,903 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
25/100
Issue type
Feature
Clarity
Clearly specified
Activity status
Active
Tech stack
java
Domain
api, backend

Research direction

Start by reading the relation handling in the power and personal update controllers, then inspect how document-view.html.template and form-view.html.template render relation fields and how .test manifests mark them. Define a relation option that permits selection on create, shows the field read-only on edit, and returns a translatable 409 when an update changes its stored value while leaving omitted values and system writes unaffected. Add tests for those cases, including the #7831 payload-check interaction.

Written by the indexing model from the issue text.

Description

Shape asked: a to-one relation that the user picks on CREATE and that is fixed from then on. For example:

relations:
  - { name: ProjectTimesheet, kind: manyToOne, to: ProjectTimesheet, required: true, fixedAfterCreate: true }
  - { name: Employee, kind: manyToOne, to: Employee, model: employees, required: true, personal: true, fixedAfterCreate: true }

Expected behaviour:

  • The NEW form renders the picker as usual. The EDIT form renders it read-only.
  • A user PUT (power and personal controller) that carries a different value than the stored row answers 409 with a translatable message (checks.<Entity>_fixed_<relation>). A payload that omits it keeps the stored value.
  • System writes (roll-ups, workflow steps, generates) are unaffected.
  • The .test manifest marks the relation read-only on edit, so the generic UI flow does not try to change it (#7554).

Why no 14.88.0 construct covers it:

  • calculatedActionOnUpdate on the relation (the "keep" pattern) holds the value server-side. But the form templates read any update action as "derived" and render the control disabled on the NEW form too (document-view.html.template / form-view.html.template, $readonly = ... || $property.calculatedActionOnUpdate). So the user can no longer pick the relation when creating the record. That is fine for a system-written back-reference such as SalesInvoice.Proforma, but wrong for a user-chosen placement.
  • readOnly: is refused on a relation (#7555).
  • immutableWhen is status-scoped and locks the whole record. A DRAFT timesheet must stay editable.
  • No checks: kind compares the payload with the stored row.

Case: BusinessIntents/base-timesheets#43 (catalogue T10). An employee can move their own timesheet to another project-month, so its hours land on another customer's invoice with the snapshots of the old placement. The module now carries a hand-written guard (custom/timesheets/TimesheetPlacementGuard.java, the calculatedActionOnUpdate of a read-only scalar snapshot that throws 409). It should be retired once this construct exists.

Related: #7831 (a kept relation is read from the payload by the checks).

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

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.