Content
View differences
Updated by Alexander Coles 3 days ago
**As** a developer
**I want to** put code identifiers in Work Package subjects, e.g. `ProjectIdentifierCache`
use OpenProject for tracking bugs and code-related tickets
**so that** bug, feature manage regressions, features and maintenance tickets read the way the code does. with ease.
**Acceptance criteria**
* A subject typed as ``Fix Typing "Fix `ProjectIdentifierCache` in main module`` displays `ProjectIdentifierCache` in monospace everywhere the module" for a Work Package subject is shown — WP table, full view, cards, breadcrumb, notification centre — should then display the same way GitHub renders an issue or PR title.
* Only inline code spans (single backticks) are interpreted. No other Markdown — bold, italics, links, images, headings — renders identifier in a subject.
* The raw text including the backticks stays on the record: editing shows the backticks again, and search, filters and sorting keep matching the raw string.
* Contexts that demand plain text keep the raw string: page `<title>`, email subject lines, CSV/XLS export, API `subject` value.
monospace - as GitHub does
**Technical notes**
* Rendering is display-time only; nothing is stored pre-rendered. Escape the subject before injecting the `<code>` element.
* GitHub's scope is the reference: code spans in titles, nothing else.
<br>
**Permissions and visibility considerations**
* Visible to anyone who can already see the subject. No new permission.
_To whom is this feature visible?_
* Not applied in the plain-text contexts listed above.
_When is it not visible?_
**Translation considerations**
* No new user-facing strings.
_Key terms and phrases in the key languages_
**Out of scope**
* Any Markdown beyond inline code spans.
* Markup in other short-text fields (project names, version names, custom-field values).
<br>
_Set the_ **To be informed/consulted teams** _field to include all teams necessary to be informed of the changes._
**Acceptance criteria**
* A subject typed as ``Fix
* Only inline code spans (single backticks) are interpreted. No other Markdown — bold, italics, links, images, headings — renders
* The raw text including the backticks stays on the record: editing shows the backticks again, and search, filters and sorting keep matching the raw string.
* Contexts that demand plain text keep the raw string: page `<title>`, email subject lines, CSV/XLS export, API `subject` value.
* Rendering is display-time only; nothing is stored pre-rendered. Escape the subject before injecting the `<code>` element.
* GitHub's scope is the reference: code spans in titles, nothing else.
* Visible to anyone who can already see the subject. No new permission.
* No new user-facing strings.
* Any Markdown beyond inline code spans.
* Markup in other short-text fields (project names, version names, custom-field values).