2.0.0 / 2.0.1

The request type is kept in the issue

Before: It is not visible which request type was used by a customer.
Now: The Request Type field contains the request type and the portal name that was initially selected by a customer (explicitly or indirectly in case of raising a request via email).

Request types can be set up more independently from issue types.

Before: Request types relevant to a particular issue type can be restricted to groups of users on Portal.
Now: Request types can be restricted to particular groups of users on Portal. If you have several request types based on the same issue type, you can restrict them separately.

Before: Request types relevant to a particular issue type uses the same screen scheme.
Now: Each request type has its own fields settings.

Before: Some system fields could not be hidden from issue view in HelpDesk independently from Jira issue view (Issue type, Description, Affected versions, Components, Priority, Status, Fix versions, Labels, Assignee, Reporter, Votes, Watchers, Created, Updated)
Now: Those fields can be hidden from HelpDesk issue view while displaying in Jira (excluding the Status that is displayed by default).

Request appearance in HelpDesk is now the same for all users.

Before: It's possible to set up different issue screen schemes for different groups of users in HelpDesk.
Now: The issue fields in HelpDesk (Portal, tracker) only relate to the relevant request type settings. No more additional screen schemes are required.

(info) As the request type is not defined for issues created before the update, those issues will be displayed as the following:

  • if there is at least one relevant request type, the issue will only display the fields applicable to any of the relevant request types.
  • If there are no relevant request types, the issue will not be displayed in the tracker.

The system fields can now be hidden from the request view screen.

Before: the request view depends on the relevant screen + issue field configuration
Now: the request view only depend on the relevant settings

Fields can be hidden from the issue screen with preset values.

Available for custom fields of the Text (single) and Select List (single) field types. Upcoming: more field types to hide.

Upgrade Notes

Auto-changes on upgrade

HelpDesk Settings → Customer Area → Portals → Screen schemes & Restriction For Issues. This section will be hidden and settings will be automatically copied to the relevant request new settings.


  • For each request type, the create/view/edit screens settings will contain the list of fields from the relevant issue type settings. If there were no specific settings, the fields will be inherited from the relevant issue settings.
  • For each request type, the restriction to groups of users will contain the restrictions from the relevant issue type settings.

A new field named Request Type will be added to the list of custom fields.

Before upgrade

1) Check there is at least one request type for each combination of "project-issueType" that you would like to be accessible via HelpDesk.

2) Ensure that the request types the can be created via Portal are included at least in one group of requests. Ensure the requests types that customers must not create via Portal are excluded from any request groups.

3) Ensure that you don't use the Advanced HelpDesk E-mail Handler. If any – set the HelpDesk E-mail Handler instead before upgrading.

4) If HelpDesk Settings → Customer Area → Portals → Screen schemes & Restriction For Issues contains any entries, ensure that there is no more than one entry per issue type. If a rule is set for more than one issue type set rules per issue type instead.

After upgrade

1) Check the fields settings for all types of requests. Add the system fields (if required) on the view screen of requests. 

2) Add the Request Type custom field to the relevant issue screens.

3) For each HelpDesk E-mail Handler select the target Request type in their settings. So the issues created by the handlers will get their Request Type set automatically.

4) Optionally use Bulk Update to set the request type to the existing issues (especially if you are going to change the request type settings significantly after the update).

5) Ensure that all settings are correct and delete the unnecessary screens and screen schemes.