Conversation
Comments render markdown with cmark's safe option and every `<` escaped beforehand, so raw HTML never reaches the parser. Instead of weakening that, convert the four disclosure tags back to real elements after rendering: mark the escaped tags in text nodes (skipping pre/code so the syntax can still be documented), then re-parse so the block level elements are lifted out of the paragraph markdown wrapped them in. Only those four exact tags are recognized and they never carry attributes, so no other markup can be smuggled in. The marker characters are stripped from the input so they cannot be forged, and unbalanced tags cannot leak an unclosed element into the page.
* upstream/master: Bug 1995464 - Overhaul guided bug entry form Bumped version to 20260916.2 Revert "Bug 2061445 - Migrate Bugzilla (system info) REST resource to native Mojo API" Bumped version to 20260916.1 Bug 2072689 - Buglist link on My Dashboard is broken Bug 2069466 Bug 2060932 - Support GitHub-style collapsible sections in comments Bug 2072224 - Add REST auth precedence note to not-yet-migrated resources
* upstream/master: Bumped version to 20260922.1 Bug 2002553 - BMO rest api search: Failed to fetch key from network storage when an attachment has been deleted
There was a problem hiding this comment.
Copilot review overview
🟡 Changes recommended
The corrected REST behavior lacks regression coverage for date custom fields.
Get a fresh assessment by requesting another Copilot review.
Review effort: Balanced
Findings: 1
What changed in this PR
Updates REST handling so date-only custom fields remain in YYYY-MM-DD format.
Changes:
- Converts only datetime custom fields during REST processing.
- Preserves date-only values for validation.
| File | Description |
|---|---|
Bugzilla/WebService/Bug.pm |
Separates date-only fields from datetime conversion. |
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
Xzzz
left a comment
Xzzz
left a comment
There was a problem hiding this comment.
Two points, both about the same thing: the field can now be written, but not with the value the API returns for it.
| next | ||
| unless ($field->type == FIELD_TYPE_DATETIME | ||
| || $field->type == FIELD_TYPE_DATE); | ||
| next unless $field->type == FIELD_TYPE_DATETIME; |
There was a problem hiding this comment.
_format_cf_value (line 1896) still routes FIELD_TYPE_DATE through type('dateTime', ...), so the field comes back as 2026-01-15T00:00:00Z and that exact value is refused on input; only a bare YYYY-MM-DD is accepted. Read-modify-write over a bug breaks on it.
Suggest splitting that branch the way this one is split: YYYY-MM-DD for FIELD_TYPE_DATE, dateTime for FIELD_TYPE_DATETIME, as deadline already does at line 1850.
Flagging rather than requesting, since reading these fields already worked and changing the output is breaking for anything parsing the current form. Worth being a decision either way.
|
|
||
| $t->put_ok($url | ||
| . "rest/bug/$bug_id" => api_headers($api_key) => json => | ||
| {DATE_FIELD, '2026-03-01 10:00:00'})->status_is(400) |
There was a problem hiding this comment.
Worth adding 2026-03-01T00:00:00Z next to the space-separated form. That is what the endpoint returns for this field, so it is the value a client is most likely to send back, and it is rejected too. Pinning it makes the contract explicit whichever way the question on Bug.pm goes.
No description provided.