checks: a relation kept from the stored row (calculatedActionOnUpdate keep) is read from the payload - leaving it out bypasses agree/forbidWhen
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 22/100
Research direction
Start from the generated controller's row-level check path, where agree, forbidWhen and compare read the payload, and from SalesInvoiceProformaKeepAction, which restores Proforma after the check runs. Look at how #7673 made checks read stored system-owned fields, and extend that to kept, readOnly columns. Done when a PUT that omits a kept relation is refused by the same agree: [Proforma, Customer] check as one that echoes it.
Written by the indexing model from the issue text.
Description
A row-level check (agree, forbidWhen, compare) is evaluated by the generated controller on the PAYLOAD. A relation that the record keeps from its stored row on update (calculatedActionOnUpdate: <Keep>Action, the "system-written, never picked" pattern) can be left out of the payload. The check then sees it unset and skips, and the keep action restores it right after. So the check never sees the value the row is saved with.
Found while fixing BusinessIntents/base-sales-invoices#205 on 14.81.0 (hunt run 37984537906). SalesInvoice.Proforma is kept by SalesInvoiceProformaKeepAction, and the new check is agree: [Proforma, Customer] onProperty Customer (#7677):
PUT SalesInvoice/27 {...row, Customer: <other>} -> 400 "bills the proforma's customer" (Proforma echoed)
PUT SalesInvoice/27 {...row, Proforma: null, Customer: <other>} -> 200, stored Proforma 2 + the other customer
Expected: the checks read the value the row is SAVED with. For a kept, readOnly or system-owned column that is the stored value, not the payload's absence, in the same way #7673 made checks read stored system-owned fields. Then the second PUT is refused like the first.
- Dominant language
- Java
- Stars
- 278
- Forks
- 97
- Avg merge
- 18h 57m
- Merged PRs (30d)
- 249
Getting set up
- No Dockerfile or Docker Compose file
- Has a pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from eclipse-dirigible/dirigible
-
Difficulty 2/5 1-3 hours Newbie friendliness 80/100
eclipse-dirigible/dirigible#7958 ·
Maintainers usually reply within 1 day
-
intent: a create-from without fromStatus answers 200 on a missing or unknown source id (no 400/404)Open
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
eclipse-dirigible/dirigible#7945 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
eclipse-dirigible/dirigible#7891 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
eclipse-dirigible/dirigible#6538 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
eclipse-dirigible/dirigible#4812 ·
Maintainers usually reply within 1 day
All issues in eclipse-dirigible/dirigible
Similar issues
-
enhancement feature
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
rsp777/service-pulse-app#28 ·
-
human-required sync-failed
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
Azure/osdu-spi-file#63 ·
Maintainers usually reply within 1 day
-
area/ysql kind/enhancement priority/medium status/awaiting-triage
Difficulty 2/5 1-3 hours Newbie friendliness 73/100
yugabyte/yugabyte-db#35578 ·
Maintainers usually reply within 1 day
-
frontend quick win
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
CodeForPhilly/benefit-decision-toolkit#571 ·
Maintainers usually reply within 1 day
-
approved
Difficulty 2/5 1-3 hours Newbie friendliness 67/100
checkstyle/checkstyle#22129 ·
Maintainers usually reply within 1 day