mirror of
https://github.com/microsoft/BCQuality.git
synced 2026-08-06 17:36:53 +01:00
288f64df16
- All 7 existing Tier 1/2 knowledge files now include a BCApps Reference section with concrete source links and observed patterns - New: bcpt-scenarios-must-be-app-specific — PerformanceTest apps must include app-domain BCPT scenarios, not only Microsoft generic samples - New: permission-sets-must-follow-least-privilege — View/Edit/Admin hierarchy with IncludedPermissionSets, mirroring BCApps BusFound pattern - api-page-key-fields-must-be-editable-on-insert clarified: SystemId as ODataKeyField + Editable=false is valid (auto-generated); rule applies to consumer-provided key fields only Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
43 lines
2.1 KiB
Markdown
43 lines
2.1 KiB
Markdown
# CURABIS MCP: ODataKeyFields Editability Rule
|
|
|
|
## The Rule
|
|
|
|
Key fields declared in `ODataKeyFields` cannot have `Editable = false` when the API page permits inserts and **the field is consumer-provided**. This restriction causes the OData layer to reject the field as an unknown property during POST operations.
|
|
|
|
## Why It Matters
|
|
|
|
When a field is marked read-only, Business Central removes it from the OData write schema. If a consumer attempts to POST a new record with that key field in the request body, the system cannot match it to any writable property and returns a `BadRequest` error.
|
|
|
|
## Problematic vs. Correct Approach
|
|
|
|
**Incorrect:**
|
|
```al
|
|
field(projectNo; Rec."Project No.")
|
|
{
|
|
Editable = false; // prevents API inserts when consumer must supply the value
|
|
}
|
|
```
|
|
|
|
**Correct:**
|
|
```al
|
|
field(projectNo; Rec."Project No.")
|
|
{
|
|
// No Editable = false — consumer supplies this on POST
|
|
}
|
|
```
|
|
|
|
## Key Takeaways
|
|
|
|
- Every **consumer-provided** field referenced in `ODataKeyFields` on pages where `InsertAllowed = true` must remain editable
|
|
- The OData specification itself enforces immutability of key fields post-creation — no additional markup required
|
|
- Non-key fields can still use `Editable = false` without triggering this issue
|
|
- Test create operations via your OData endpoint to verify compliance
|
|
|
|
## BCApps Reference
|
|
|
|
BCApps `BCPTSuiteAPI.Page.al` uses `ODataKeyFields = SystemId` with `SystemId` marked `Editable = false`. This is a **valid exception** — `SystemId` is a system-generated GUID that BC assigns automatically on insert. The consumer never provides it in a POST body, so marking it non-editable does not break API inserts.
|
|
|
|
- **Source:** https://github.com/microsoft/BCApps/blob/main/src/Tools/Performance%20Toolkit/App/src/BCPTSuiteAPI.Page.al
|
|
- **Clarification from BCApps:** The rule distinguishes two key field types:
|
|
- **Auto-generated keys** (`SystemId`, auto-numbered codes): May be `Editable = false` — BC supplies the value, not the consumer.
|
|
- **Consumer-provided keys** (`"Project No."`, `"Code"`, `"Entry No."`): Must remain editable — the POST request must include this value and BC must accept it.
|