feat(server): accept custom fields when filing a bug - #76
Merged
Conversation
The audit's first Warning noted that create_bug had no way to carry cf_* values, so a product with a mandatory custom entry field could not be filed into at all — update_bug_fields already had the cf_* machinery (I7), but the create side was a gap, not a new mechanism. create_bug now accepts the same custom_fields param and the same I7 cf_* prefix gate as the updater, applied before may_create and before any upstream call. The early error is safe to distinguish from the padded, uniform create refusal because its outcome is a pure function of the client's own key names, not of policy or upstream state. Confirmed no Matcher criterion reads cf_*, so a custom field cannot move a prospective bug between policy rules; a guard test pins that down alongside the existing product/component reclassification tests.
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
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.
Second of the two PRs from the create-time discovery audit item (#74 was
the first). Single commit.
What
create_bughad a fixed parameter set and no way to carrycf_*values, soa product with a mandatory custom entry field could not be filed into at
all —
update_bug_fieldsalready had thecf_*machinery (I7: onlycf_*keys may pass, otherwise the tool errors without calling Bugzilla),so the create side was a gap, not a new mechanism.
create_bugnow takes the samecustom_fieldsparam (JsonObject, samedoc wording as the updater) and applies the identical I7 prefix gate,
before
may_createand before any upstream call, then merges the keysinto the create payload. The early error here is safe to make
distinguishable even though the create refusal is otherwise padded and
uniform: its outcome is a pure function of the client's own key names, not
of policy or upstream state, so it discloses nothing about either.
Confirmed no
policy::Matchercriterion readscf_*— a custom fieldcannot move a prospective bug between rules the way
product/componentcan — and pinned that down with a new guard test alongside the existing
create-time reclassification tests.
Invariants touched
update_bug_fields.custom_fieldsandcreate_bug.custom_fields, and to record that the create-side gate runsbefore
may_createwith zero upstream requests on refusal.cf_*gate is aseparate, deliberately distinguishable early error, not a substitute for
the padded policy/upstream refusal.
Verification
cargo fmt --checkcargo clippy --workspace --all-targets -- -D warningscargo clippy -p bugwarden --features gen --all-targets -- -D warningscargo test --workspace --all-targets --locked— all green, including:crates/bugwarden-core/src/guard.rs: new unit test asserting thecreate verdict is unchanged by a
cf_*value, for both an allowed anda policy-denied product.
crates/bugwarden/tests/tools_wiremock.rs: acf_*key reaches thePOST /rest/bugbody; a non-cf_key errors with the exact I7 textand makes zero upstream requests.
cargo deny check— clean (no new dependencies).