feat(publish form): lock pre-filled values and statements (#678) - #679
Merged
Conversation
A link into the publish form can pre-fill fields with URL parameters, but some of those values are not the user's to change: the "Create Introduction" link fills in the public key of the local key pair, and an introduction declaring a different key is simply wrong. Two new page parameters state that: - `locked` names the pre-filled values that cannot be changed. It holds per repetition, as the name carries the repetition suffix of the field it refers to, so a link can pre-fill and fix the keys a user already has while leaving them free to add more. - `locked-statements` names the statements whose repetitions are fixed: no adding, no removing. Independent of the value lock, and named either by the statement node or by a placeholder that occurs in it and no other. Both take the same template prefixes as the pre-fill parameters (`param_`/`prparam_`/`piparamN_`, bare = assertion template). A locked field stays enabled as far as Wicket is concerned and keeps being submitted: disabling it in Wicket looks right and is wrong, since the browser sends nothing for a disabled control and the form then reads the field as an emptied one, losing the value and failing its required check. Text inputs are marked readonly, which browsers submit; choice fields, which render as `select` and have no readonly in HTML, are disabled with their value mirrored in a hidden field of the same name. Removing a repetition group shifts the values of the following groups up through fixed placeholder slots, so the locks shift with them: the lock belongs to the pre-filled value, not to the slot, and removing a locked repetition must leave the value that slides into its place editable. The "Create Introduction" link now locks the user and the public key. Optional statements need no separate lock to be kept, as one is dropped by leaving a field empty and a locked value cannot be cleared. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01An6DWbMvqQM7z312vC7apK
A view entry action fills form fields from the row it sits on, through its "col:field" query mappings. Writing the field as "!field" now locks it too, so the form shows the value the action filled in but does not let the user change it. This is for values an action determines rather than proposes. The case at hand is the "derive new introduction" action of the introductions view, which appends the local public key to an existing introduction: a different key there makes the introduction wrong, so the field should not invite editing. Applies to param_ targets only, as a raw @ key is a fill-mode switch rather than a form field. Several locked mappings accumulate into repeated `locked` parameters, which the publish form already reads. Note the deploy order this implies: a view nanopublication that starts using "!" should be published only once the deployment reads it, as an older version treats "!public-key__.1" as a field name of its own and fills nothing. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01An6DWbMvqQM7z312vC7apK
Contributor
|
🎉 This PR is included in version 5.13.0 🎉 The release is available on:
Your semantic-release bot 📦🚀 |
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.
Closes #678.
A link into the publish form can pre-fill fields with URL parameters, but some of those values are not the user's to change: the "Create Introduction" link fills in the public key of the local key pair, and an introduction declaring a different key is simply wrong.
Two new page parameters
lockednames the pre-filled values that cannot be changed:It holds per repetition, as the name carries the repetition suffix of the field it refers to (
param_public-keyis the first key group,param_public-key__1the second). That is what lets a link pre-fill and fix the keys a user already has while leaving them free to add more with "+".locked-statementsnames the statements whose repetitions are fixed — no adding, no removing:A statement is named either by its node in the template (
st2) or by a placeholder that occurs in it and no other (public-key). Resolved when the lock is queried rather than when it is parsed, since the statements are only built afterwards.Both take the same template prefixes as the pre-fill parameters (
param_/prparam_/piparamN_; a bare name means the assertion template), accept comma-separated lists and repetition, and are independent of each other: a locked value in an unlocked statement can still be dropped by removing its repetition, and a locked statement's values stay editable unlesslockednames them too.Two things worth reviewing
The field stays enabled in Wicket. Disabling it looks right and is wrong: the browser sends nothing for a disabled control, and the form then reads the field as an emptied one — the value disappears and its required check fails. Text inputs get
readonly, which browsers submit; choice fields render asselect, which HTML has no readonly for, so they aredisabledwith the value mirrored in a hidden field of the same name. This was caught by driving the running app, not by the tests.Locks shift with values on removal.
RepetitionGroup.remove()does not delete a slot; it shifts the following groups' values up through fixed placeholder slots. The lock belongs to the pre-filled value rather than the slot, so it travels with it — otherwise removing a locked repetition would leave the value that slides into its place uneditable. Only IRIs that actually get a repetition suffix are shifted:iriSetholds the statement's constants too, and one can share a placeholder's postfix (rdfs:commentbeside acommentplaceholder), which shifted the same lock twice and undid it.A value lock is a guardrail — it is stated in the URL, so it stops accidental edits, not deliberate ones. A statement lock genuinely holds: Wicket does not invoke the listener of an invisible component, so a hidden "+" cannot be triggered from the page either.
Also
ProfileAccountPanelnow locksparam_userandparam_public-key.docs/locked-prefilled-values.md.Testing
LockedFieldTest(15) — per-repetition locking, lock shifting on removal, readonly/hidden-mirror rendering, statement locks.PublishFormLockTest(8) — parameter parsing for both locks.locked-statementsremoving the group's "+"/"-", and Preview producing a signed nanopub containing the locked key. Nothing published.Note: previewing after removing a key group reports "Invalid choice" on "has key location", which still references the removed declaration. That is pre-existing — the control run with no locking at all behaves identically.
🤖 Generated with Claude Code
https://claude.ai/code/session_01An6DWbMvqQM7z312vC7apK