ADR-0076: A directly editable field is a closed enumeration, not a generic patch - #34
Open
nguyenngothuong wants to merge 1 commit into
Conversation
A record page shows values and offers no way to change one. `EditFieldsDrawer` writes custom fields and states in its own header that no built-in column has a write on this build — which is true, and true on purpose: every write to a built-in entity is an intent flow, because ADR-0001 holds that "set column to value" is not a unit of business meaning. Some values, though, are just values. A misspelt company name is not an event, and a platform whose answer to a typo is a new capability is one whose capability count tracks its users' spelling. So the question is not whether a field may be edited directly, but who decides which ones and when that decision is checked. This proposes the division already drawn for configured processes in 26 §7.3, applied to columns: configuration selects which pair and what value, and cannot add a pair. One flow, `crm.record.field.set`, over an `EditableColumn` enumeration the compiler sees the whole of; a diagnostic when a member names a column `Describe` does not answer for; a fitness function refusing any pair also reachable through an intent flow, which is the two-ways-to-write defect that rules out a generic patch. It reaches `field_policy` and the tenant's validation rules — both of which exist and neither of which anything in the sample writes through today — journals to `custom_field_history`, and emits `record.field.changed`. No code. The ADR first, per CONTRIBUTING: a rejected ADR costs an hour. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Signed-off-by: nguyenngothuong <nguyenthuongtb12@gmail.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
ADR only — no implementation, per
CONTRIBUTING.md: a rejected ADR costs an hour, a rejected implementation costs a week.Why I am asking
I want to add inline editing to the record page — click a value, change it, save. Before writing any of it: on this build nothing edits a built-in column, and
EditFieldsDrawersays so in its own header rather than leaving it to be discovered. Reading around it, that looks deliberate — every write to a built-in entity is an intent flow, which is ADR-0001 holding.So the design question is not the UI. It is whether this platform should acquire a generic write, and I think the answer is no.
What it proposes
One flow,
crm.record.field.set, over anEditableColumnenumeration the compiler sees the whole of. Configuration selects which pair and what value; it cannot add a pair.That is not a new pattern here — it is the division already drawn in 26 §7.3 for configured processes, where an administrator rewrites transitions while the action kinds stay closed and
ProcessPublishing.Validaterefuses an unknown one. I have applied the same shape to columns rather than inventing a second one.The rule for what goes in the enumeration: a column is in it when changing it means the previous value was wrong, and out of it when changing it means something happened. The second is an intent and keeps its flow. So
account.nameandcontact.emailare in;opportunity.stageis not.The part I would most like challenged is the fitness function: a pair in the enumeration that is also reachable through an intent flow fails the build. Without that, this decays into the generic patch it exists to refuse, over about a year. I would rather that check be wrong now than absent.
What it deliberately does not do
record.patch, for the reason in the Context section — the manifest would describe an application that is not the one running, which is the guarantee in13-AI-Nativefailing for every entity with a guarded column.custom_validation_ruleset throughGuardOperator.custom_field_historyalready has the right shape and today only ever holds a custom column.If this is accepted
Implementation would come as its own PR — enumeration, diagnostic FLOWX1035, fitness function, capability, tests first,
docs/26updated in the same PR. If it is rejected I would like to know whether it is the closed enumeration you object to or inline editing at all, since the second answer saves me proposing a variation on the first.Also happy to be told this belongs behind the manifest v1.0 freeze; it adds no manifest field, which is why I did not assume so.
Signed off under the DCO. One file plus its index row.