Everything the app does, from the value on the customer’s screen to the settings that decide it. What the customer sees is marked as such; the rest is for administrators.
On the request page
The panel sits in the right-hand column of the request detail page, under status and request type. It shows only the fields you configured, and only on requests where they have a value.
Every value is formatted for the person reading it, in their language and time zone.
The portal’s sidebar is narrow. Flag a field for long values and the panel shows a short preview with a View full text button, instead of a column of wrapped words. One setting per field.
Portal editing
Editing is off after installation and after every upgrade. A field becomes editable only when an administrator switches it on, and Jira still decides what it accepts.
A dropdown of exactly the options Jira offers for that request, a date picker for a date, a search dialog for an Assets object, a text box for text. A long field opens a larger editor in a dialog.
A short hint per field tells the customer what belongs there, translatable like the label. A field marked required cannot be saved empty.
Set once per configuration, and it applies to every editable field in it.
Jira accepts a change only if the field is on the project’s edit screen and the app may edit issues there. The settings page cannot know that in advance, so it asks.
You choose which fields per field, and who and when per configuration. The settings page reminds you that Jira still decides, and that its history will name the app.
The value the customer saw is sent back with the change. If an agent edited that field in the meantime, the customer’s save is refused and they are asked to reload. A refused save is preferred to a silent overwrite, every time.
Assets objects
Jira’s issue API returns an Assets (CMDB) field as identifiers only. That is why portals usually show it blank, or as a number. The app looks up the object’s name and shows that.
The object already linked to the request is shown by its name, read from Assets when the request is viewed and not stored.
A search dialog restricted to the object types you allowed for that field. With no type allowed, the search finds nothing rather than everything.
Assets is part of JSM Premium. On a site without it, there are no Assets fields to show and the app’s Assets permissions are never used.
Choosing fields
The settings page lists every field on your site with its name, type and ID. Selecting one pre-fills its label with the Jira name, which you can change.
Priority, Due date, Components, Versions, Description and Resolution are in the same list as your custom fields. A field already chosen is hidden from the other rows, so nothing is mapped twice.
Two kinds are refused whatever you configure, including through import: the security level, which is an access-control fact rather than a value, and containers such as comments, worklogs, attachments and issue links.
CF_ASSET_TAG_PRI means nothing to a customer. Device serial number does. Every field gets a display label, and the panel an optional heading.
Per service desk
A default configuration applies everywhere. Any service project can replace it with its own fields, labels and editing rules.
A project without its own configuration uses the default. A project configuration replaces the default for that project, so an HR desk never shows an IT field by accident.
Service desk leads change their own labels and fields without waiting on a site admin. The page reaches only its own project, re-checked on the server for every call. The default configuration and the languages stay with Jira administrators.
Languages
The app’s interface is fully translated into 26 languages: every string, in every file, checked automatically. It follows each viewer’s Atlassian language and falls back to English.
Choose the languages your customers use, then translate as much as you like. Anything untranslated shows your default wording. Removing a language removes its translations everywhere, so nobody keeps seeing text you thought you deleted.
Rollout, diagnosis & logs
The tools a Jira administrator needs once the app is used by more than one team.
Copy a configuration that works onto any projects you select, in one step. Export a complete configuration as text and import it on another site to keep staging and production in step.
The change log records which administrator changed which configuration, the last 100 changes. Changes by customers records which customer changed which fields on which request, the last 200, field IDs only, never the values. Either can be cleared at any time.
Limits
| Limit | Value |
|---|---|
| Fields per configuration | 20 |
| Project configurations | 50, plus the default |
| Heading, label, hint, each translation | 100 characters |
| Languages | 26 |
| Text a customer can enter | 32,767 characters, Jira’s own limit |
| Values in a multi-value field | 100 |
| Allowed Assets object types per field | 20 |
| Change log / customer log | Last 100 / last 200 entries |
Show them first. Open one for editing when you are ready. Nothing becomes editable until you switch it on.
Custom Fields for JSM Portal