It's so funny coming back to this in 2023 and seeing all these complaints are still valid.

This would be useful for ticket submission, and havibng end users be able to select the project to know where changes may need to be made.

It still appears in JSM v4.20.11

+1 for Project Picker fields

+1 Adding onto having Project Picker for Service Desk. Would be really helpful for certain automations we're trying to run.

Adding onto having Project Picker for Service Desk. Would be really helpful for certain automations we're trying to run.

This ticket was closed based on the addition of a very few custom fields... whereas in my mind at least the request here was for the ability to use any and every custom field in the portal.

Of the 20 or 30 linked tickets, which ticket best emcompasses the above requirement? My fear is that the votes and interest are being spread over a whole bunch of issues, so Atlassian is not seeing the true need for this.

I'm going to plump for JSDSERVER-100.

It's a shame you didn't add the Group Picker given this was mentioned back in 2015 as one of the popular fields.

Also, will you be releasing these into the LTS version?

I shall track https://jira.atlassian.com/browse/JSDSERVER-7097 but I hope it won't take another 6 years. 

I need the Group Picker for a Customer Request type that triggers a REST service to add users to (or remove users from) a Crowd group.

(This in itself is a workaround for the fact that group creation/management is restricted to Jira Admins.)

Using a free text field will increase the chance that a user's request fails because of a typing error.

What I think Atlassian need to understand is the extent to which users are using Service Desk requests to drive self-service automation for customers.

One of my Use case for having a project picker in the service portal is to have the mechanism to control access to projects. 

Currently, we only allow people assigned to projects to be able to view and browse the projects. this is to minimise their clutter as well as for restricting what external users can see.

Having a mechanism to request access to projects so that a service request can be raised and fulfil is the logical step. can access be requested by or on behalf of a user. 

Currently done by email.

Thanks

I don't get why not letting the customers decide to use a field or not. Why banning an entire type?

> Yes, that, or re-use Jira's standard custom field rendering pipeline

Yes, I didn't say that because JSD form controls look slightly different, and I imagine it's important to the maintainers that the look and feel is in keeping with the rest of the controls on the page... so it may be useful to allow field types to opt-in to allow them to provide consistent styling etc.

But I'm probably over-stepping the mark, it's clear what app-providers want, how Atlassian do it is their business.

> we were horrified to see how it was actually done!

Indeed, although in fairness, vendors are pretty constrained here because of the current implementation of JSD.

It would be straightforward enough to allow custom field types to implement an interface which describes how to render the field value for the various contexts

 Yes, that, or re-use Jira's standard custom field rendering pipeline.

The JSD(JSM) code is all hard-coded for implementing specific Jira field types and it's not an evolutive design. The sooner this codebase is changed the better!

We will otherwise need to inject Javascript to be able to add our HTML to the page, and will need to update the VIEWPORTFIELD table so JSD thinks our field is managed. When we had customers tell us that "Insight does it", we were horrified to see how it was actually done!

Cross-referencing https://productsupport.adaptavist.com/browse/SRJIRA-4914. 

I understand the disinclination to provide full support for all custom field types including third-party ones, nevertheless several vendors are already jumping through multiple hoops in order to provide this to customers, for example injection of javascript on the "edit request type" page, direct updates of the database (updates to AO_54307E_VIEWPORTFIELD), and so on.

I know that Insight does this, ScriptRunner does this... in our case (ScriptRunner), for the most part this works well, but we are not able to workaround this lack of support for custom fields when it comes to generating service desk emails. Specifically in the code at com.atlassian.servicedesk.internal.fields.renderer.CustomFieldFieldValueRenderer#getRenderer which enumerates the supported field types. It would be straightforward enough to allow custom field types to implement an interface which describes how to render the field value for the various contexts.

Agree with Michael. We have the exact same situation for our service desk, if users (employees) want to have a new project and want to provide a sample project (to copy configurations from). It's been five years. How are you doing Atlassian? Need a hand?

automize project creation, so it can be requested from portal -> the user could pick the template project as starting point for his/her new project

We have a requirement of group picker field as a dropdown in customer portal. Please suggest if it is possible.

We have an issue where One field called Application Group(s) (Group Picker (multiple groups) field) does not display on the portal but does on the main UI.

Please advise:

We'd really like to use some of our favorite external custom field types (e.g. Tree Custom Field) on multiple service desks. Is there a path towards allowing external field types?

Yes, having a project picker on the customer portal will enable standard users to request access to specific projects, and through the approval process, a manager can execute with a single click.

Needs:

Project Picker

Automation to grant access for User to Project

We use Tempo and need our requesters to identify the charge account that will be used.  Without this ability, Service Desk is a non-starter for us.

Hi Everyone,

Last week, we launched a beautiful new app [Project Version Picker for JSD |https://marketplace.atlassian.com/apps/1222573/project-version-picker-for-jsd]. It's another step in our master plan to highly couple different Jira applications and projects.

This custom field can be used on Jira Service Desk portal to prompt your customers for desired Jira projects, and supports to prompt for version and components.

The custom field is highly configurable to match most use cases.

Give it a try I am confident you'll love it.

yeap, me too.

Hi! i have the same case (to add the "Linked issues" field) and i hope to early solution

Our service desk is designed for our company internal users and they can ask for some configuration changes on their project that require administration privileges.

So we definitely need to be able to use a Project picker field in our customer portal  to let the user select the project he wants to be configured.

For our use case, our department uses Jira Software for software projects. My team are the Jira admins. We support the department. We want a service desk to track issues related to changes/tasks for specific software projects and would really rather not have to have a custom select field that has to be maintained. The project picker already exists, so we want to use it.

Essentially the same for linking issues.

We need project picker because customers are associated to several different projects and not knowing which project to charge to right off the bat is not ideal.

We want to get the project from the user and after they choose the desired project we would want to query the affected version for that project.

This feature would be a breakthrough to our long sophisticated customization.

We're trying to use the group picker fields in the portal to support automated access request forms.

I'm looking to be able to include an Issue Picker Search custom field into my portal.  This will allow my customers to use a current issue as a reference in their new request.  

We are currently needing the version picker. We are tracking client upgrades who have 3 environments (Dev, QA, Prod) and would like to be able to track them separately, but still be able to query by it.  

We haven't heard many customers asking for groups and versions and therefore they are not on our current roadmap. We'd like your use case for these ones, esp. the group field. 

We are using Service Desk (in conjunction with a webhook framework) to provide automated request types that enforce business logic. An example of this is that users are allowed to create tickets for creating and managing LDAP groups.

At the moment, the request type for adding members to a group is a multi-line text field and the requester has to use the email addresses of people or groups that they want to add to an existing group. That can lead to problems because requesters often copy/paste and this can lead to textual errors in the format of the email addresses.

We can clearly start using the multiple user picker instead and that would be a significant improvement but, without a multiple group picker, we're still stuck with using a text field and that is not a good user experience.

Hopefully this use case makes sense to you and helps drive the impetus of getting it delivered.

?? [Adaptivist |https://marketplace.atlassian.com/apps/1213102/kanoah-checklist-for-jira?hosting=server&tab=overview]/ [Elements|https://marketplace.atlassian.com/apps/1217646/elements-checklist-smart-grid-in-jira?hosting=cloud&tab=overview] ? wich one ?

+1 for Checklist plugin. Vendor just confirmed that it would be possible to display Checklist CF once this issue is resolved. Is there any update from Atlassian available?

I understand from https://community.atlassian.com/t5/Jira-questions/Why-is-the-JSD-service-portal-not-able-to-present-fields-of-type/qaq-p/865991 that groups are deemed internal-only information. So what if the Service Desk is an internal Service Desk used for internal IT requests and needs a group picker?

Limiting a field's availability based on Atlassian's use case for it seems, at best, short-sighted. At worst, it's heavy handed because it feels like Atlassian is dictating to its customers how to use its products because Atlassian knows better.

I really need the ability to add a group picker field to my customer form.

An issue picker would also be nice to have as a field on a request type imho.

This would allow a end user to link for example a incident to a previously made request or a request to another request (indiciating a relation)

We need an update from the Atlassian team on this. The last one was three years ago.

Portal Picker Use case:

We have 150+ Jira projects, it would CERTAINLY be helpful if a user can report which project they're having problems with on their Service desk ticket, some users work on 12+ different projects.

4 back and forth messages later I get the answer.

I really have a hard time understanding why isn't it even an option, if only say 506 customers used it, thats still adding some value, so just make it an option?

Update - We upgraded and the Portfolio fields are now available, they just don't work. 

We required that Portfolio fields are available on JSD (e.g. Target Start, Target End, Parent Link etc) and it's becoming more urgent. I assume that this would be included in this request.

it's sad to see nothing changes related with this request.

It would be great to add support for custom fields developed by add-on vendors, like CF++ (https://marketplace.atlassian.com/apps/1216682/custom-fields-for-jira?hosting=server&tab=overview)

Hey all, 

Not supporting all custom field types with the argument that they are not relevant to the portal users is weird! Is there a definition somewhere what all portal users are needing?

I can understand the argument if JSD is only used with external customers, but in our organization we have 500 agents supporting the rest of the org (3000 users) with all kind of service desks. We have 35+ service desk projects active and many of these would benefit a lot if e.g. the Group Picker field type was available.

Example Scenario: Access Management, you need a specific in-house service to be available for your team. In the JSD form you can select the system and write a motivation, but you cannot select the LDAP group you want this access to be granted to. We are forced to use a multi-line text field instead where the user types in the name of the group. Extremely error-prone and un-efficient!

So, please add the last missing custom field types to the JSD request type and let the admin in each instance decide what is relevant or not.

// Cheers! 

Message++ from CustomField++ plugin doesn't work either

Not providing a solution for this with almost 500 votes is just a disgrace

Insight has functionality for this with all of their object fields; however, it appears this functionality has been broken in Jira Service Desk 4.0.0

This is something Atlassian should really take seriously as they are now breaking the functionality of other, paid services.  Being a large Government customer, I'm always fighting to justify the use of Jira over other alternatives; however, this fight has suddenly become much more difficult!

Hi Atlassian, any updates?
Unable to use Multi-Level Cascading. Wont allow a preset value to be set, thus the field type cannot be shown.

Hi, my interest is about file type custom field, for example, the custom field created using Apwide add-on (https://marketplace.atlassian.com/apps/1217971/apwide-file-field?hosting=server&tab=support) are not shown correctly inside Service desk

There is a specific ticket created on their customer support portal: https://bitbucket.org/apwide/file-field-for-jira/issues/6/apwide-file-field-does-not-work-with-jira

 it seems there are 475 persons who vote for this issue, is this number enough to have this fix?

Correction it's been over FIVE years!

This has been a feature request for over 3 years with HUNDREDS of votes.  Why is this not being done?  Why in the world would JSD ommit these simple field types?  If a customer is requesting us make changes to their project we need them to be able to tell us which project they need help with!!!