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!!!

any news

+ 1,000,000,000 for project picker, group picker, time tracking fields, labels, participants, multi-level select.

Atlassian, how many years need to go by or how many customers need to complain about basic functionality being intentionally omitted before you do something?

+1 Time Tracking fields

We have JSD forms where the customer requests time from the team. E.g. I am setting up a thingy where I would need 2 hrs of your time to be allocated

Today we solve this with a simple text field but it would be awesome if the customer could add this to Original Estimate field in the Time Tracking feature 

Support for Multi Level Cascading Select would be nice as well. (Having Multi Level Cascade Select in SD w/o a plugin at all would also be great, but that is for a different ticket)

 I am currently using the below for some selection lists which I cannot surface on my Customer Portal.

https://marketplace.atlassian.com/apps/5008/multi-level-cascading-select?hosting=server&tab=overview 

*Edit - Just noticed that Multi Level Select is already on the list, unsure if this is related?

I have a SD Server instance where a number of my Request types require changes to a specific project hence the need to display the Project Picker on the Customer Portal. 

The alternative is to give the user a hand cranked single select list but as the project list grows this is an administrative overhead we don't need and will become unwieldy for the users as the list grows.  Please can we have the pickers visible and not 'hidden' to customers.

I use a Service Desk project to manage requests for changes to Atlassian tools. The SD project then becomes the change log for tracking changes to the suite - why was the project added? who wanted it? why is it using the schemes it's using? Or changes to access - why was x added to the project admin role? who approved it? Or to request a project be archived - when was it archived? who approved it?

I would expose a project picker to users so they can indicate the project they are having trouble with/requesting changes to/asking to be archived. I would also expose it to them so that when they are requesting new projects they can indicate the project they'd like to share configuration with. I would also use it for tracking spaces that need to be linked to a Jira project.

I absolutely need this the ability to have group pickers on the portal. I am using the Active directory Attribute sync plugin from Devinity https://marketplace.atlassian.com/apps/1212162/active-directory-attributes-sync?hosting=server&tab=overview

I want to have a "request to be added to an AD group" request type on my service desk, where the submitter can pick a user, and group to add them to. After getting approvals, I would use the supplied post function to automatically add them to the group.

If I dont have the group picker, I cant give the user an ability to search for a group.

I was stunned to see that this wasn't available. Seems like a major missing feature that should be easy. If you can have user, pickers, why not group pickers.

Use Case example for Project Picker:

We are adapting the Service Desk not for customer use, but internal requests to our DevOps team. In order for the devops team to identify which project team is making the request, we need an easy drop down of the running projects that our teams can pick when putting forward said request. 

4.5 years later and this is still gathering interest? This is #1 on the votes with over 400 votes today. Over 150 comments as well...

Please implement the ability for admins (the ones advocating for your product) to add what they need to the Customer Portal. A container field that allows admins to select which of the available issue fields they need to be present on the Portal would be fine.

User Picker works on Service Desk, Group Picker should absolutely work as well.

our instance of Jira Cloud service desk has internal groups and our customers want/need to be able to add a CC to those groups at ticket creation.

please add this feature ASAP.

i can't believe i need to even request such functionality. this is basic stuff.

-RMT

+1 for calculated fields (those extending CalculatedCFType class). Txs!!

Hi!

Parent link from Jira Portfolio would be excellent. We have Initiatives in our customer portal, and we would like the users to create issue types on an initiative, i.e. they neet to enter a Parent Link!

Thank you!

Riada's Insight for Jira has support for custom fields on Service Desk and will likely work for many needs.

Seriously Atlassian guys?

This field type cannot be shown - you must provide a preset value

You are facilitating the plugin business and the same time you are completely forgetting about customers satisfaction! Do something

For internal usage, project field is relevant field we would like to use.

<shameless plug>
Hi Pedro,

The multi-level cascading field of the table grid editor can be used on a customer portal. (Note the table grid itself not yet - but we are working towards that goal)

Francis
</shameless plug>

Multi-Level Cascading Select by Sourcesense, please.

Adobe's use Case - which I think will be relevant to ANY team supporting Jira that wishes to use JSD.

Our Jira customers submit Jira support requests to us. Requests to create/manage fields, workflows, screens, etc. You know, the day-to-day. Well on our intake form we include the Project Picker field to allow the user to specify which Jira project they would like these changes to apply to. This works really well for us and maintains a great level of traceability. 

This is blocking our Jira Support Team from using the very tool they support themselves. It's ironic, really. Simple use case, and certainly not hard to see it's value. It's also not hard to see how it is negatively impacting our adoption and proliferation of JSD throughout Adobe. 

We really want to run "Internal service desks" at enterprise level. One development team delivering a portal logged issue with help text to another remote development team so it can be triaged and managed etc.

Without the customer version picker, we are struggling. We need to complete a "Last known good" and do not want to use a manual select as they are on CI and the upkeep would be untenable. is there any scope to add version picker to portals?

I agree with Steven....

"Often I need to use Groups for approvals, notifications. Again, not supported at all. This seems obvious. I need to be able to provide a list of groups so that a customer may select the owner, department, group, etc."

This issue was created 4 years ago, and one update from Atlassian on 13 March 2015 - this is really limiting.  Please advise on when this will be updated?

Needed feature and solution for it cause predefined fields do not fit needs. Very important cause such information that could be added to usual Edit/view screen MUST HAVE possibility to be shown on Customer portal as well. 

I am trying to use "Multi-Level Cascading Select" in JIRA Service Desk(3.5) customer Portal but unable to add that custom field in Customer Portal. It is not letting me to add it to visible field and keep asking to set the default value unless I have set the value already.

Does anyone knows when this add-on will be compatible to Customer portal?

Thanks,

Kishan

Hi Team,

I am not able to add "checklist"(this field is created by using Checklist plugin) field in request type

while adding, I am getting "This field type cannot be shown - you must provide a preset value" but after clicking on "edit Value" i keep on getting loading kind of page.

So kindly confirm what are the fields type supported by JIRA service desk 3.5 version and which are not supported and any future plan when it will be implemented. 

Thanks,

Bavant

Many of the Service Desk's I set up desire the customer to refer to a previous support request: There's zero support for this since you didn't provide the Issue Links field for the portal and plugin fields of the same type don't work. Since Atlassian hasn't provided this, my only option is to insert JS into the portal and handle it all myself. Painful at best.

Often I need to use Groups for approvals, notifications. Again, not supported at all. This seems obvious. I need to be able to provide a list of groups so that a customer may select the owner, department, group, etc. Right now, I only accomplish this by scheduling a job that reaches out to LDAP and updates options in a normal dropdown menu. This sucks. Badly.

We use Service Desk internally to manage support for our many, large, JIRA instances. Not having access to the normal Project Picker is dumb. Yet another field I need to dump a ton of time into since Service Desk decided to whitelist specific types of fields and re-render them.

Stop arbitrarily limiting what fields I can add to Service Desk Portal and Software Boards! 

I really need the ability to link a JIRA ticket to my internal customer support portal. Looks like its not pssible. Can someone address this please?

Hi,

I really need project picker in service desk, because when i receive a request to create a Bitbucket repository i have to assosiate the JIRA existing project; so i don't wanna the user capy and paste everytime the project name, but use a project list.

please update this issue

thank you

Hello.
I can't find Multiple value customfield support.

Better is enable ability to insert custom html that can format customfield values or get that code from customfield plugin.

Please specify what fields you would like to see in the Customer Portal by adding comments to this issue.

We would like to add a our own(custom implementation) customfield type to customer portal. Custom field type is implemented for specific needs.

So, we would like to have ability to add any custom field type to customer portal.

But, for developers, there isn't any Public API/SPI to do that.

Hello Anupam Srivastava,

With nFeed you can populate custom fields with data coming from external datasources, including user directories. It should be able to answer your need and it is compatible with JIRA Service Desk .

Please also add support for Kepler Custom Fields PRO or provide functionality to pull external AD Users and Groups into custom fields....This would really help our use case and enable us to promote the adoption of service desk at an organization level...

We intended to use this custom field to help eliminate the need to verify information relating to a user account.

As an example, take a user that would like to modify their user account information. By providing a custom field connected directly with our AD the user can simply select the appropriate user to be modified. If there are 2 Lisa Smiths...they would select the correct Lisa Smith account.
In order to work around this limitation that we have just discovered, we will now simply present a text box for the user to enter their user account. This could result in getting the log in user name or the users full name and even spelling mistakes. This will now impact the service agent who will have to verify the exact AD account with the customer before sending the task to the implementing team. This is an extra step that would be unnecessary if we had the custom field.

We also wanted to dynamically pull in our department & branch listing's from AD which are centrally managed to be displayed and selected so we are not managing a separate listing of static information.

There were various other custom fields we wanted to create as well pulling from AD that we will now only be able to present a text box requiring service agent effort to validate prior to sending tasks to our implementing teams.

I hope that this can be addressed in the near future to support us rolling this out further...

We have about 800 JIRA projects to support. We use 1 Service Desk portal to receive all kinds of support request for these projects. It would be more than useful for the user to use the "Project Picker"  and choose on which project he needs support. It would also ease our support management and reporting. 

wtf, no Group Picker support??

RE: Update as of 16 Aug 2016

Many of our workflows are initially assigned to teams (which we have sorted into groups).  As groups cannot be added as 'Assignee' we have created a Group Picker field into which the user creating the request would 'assign' the group.

Without the ability to add this custom Group Picker field to the Service Desk for the user to select the initial assignment of a team to the request, Service Desk becomes unusable, as we are then left with orphan issues (no assignee no assigned group).  Potential work arounds, such as adding a loop transition to the first status of the workflow to set the team, would require exposing JIRA to our service desk customers and is not a valid option.  Creating a catch all team for initial assignment or an individual to filter requests also becomes cumbersome and not a valid option.

Hopefully we are not the only ones that assign to Teams on initial create based on user selection and we look forward to the Group Picker field being a valid addition to the Service Desk interface.

@lucas.dussurget

Now you made us very curious - how did you guys pull it off ?

Francis

Thank you guys! We are super pumped on this. 

Hi there,

I saw many of you asked to be able to use nFeed feeds on the JSD portal.

We've just released nFeed 5.9 today which finally makes this possible.

See more on the Marketplace and in our documentation

Hi, there.

It is very critical to me to have Scripted Fields and Behaviours in Customer Portal. 

+1 for adding the version pickers on request types. I have different clients on different versions of our software and in some cases they are in the process of going through an upgrade and need to ability to specify which version of our software they are running.

I do have a current workaround but, it seems redundant. Create a generic select list and populate with the project's versions. You end up having to maintain the versions in 2 places but, its what I am able to do at the moment to give my customers and agents what they need.

+1 : we need to be able to use all types of custom fields (not only nfeed ones). I completely aggree with Jan : we need a way to integrate new type of custom fields into Service Desk the same way it is possible to do it in basic JIRA server.

We desperately need nfeed on our customer portal. Please Atlassian, work on this. It will enhance JIRA's capabilities massively!

+1 to adding support for third party data plugins like nFeed. I am disappointed this is not on the roadmap.

I don't get that too. Why you do not publish development api to enable us to develop field that is possible to use in customer portal? What is the issue there? I understand, that it probably uses different layout for field in customer portal then in jira itself, but what else is blocking us? I belive you should reconsider your roadmap while this is must have feature, not just nice to to have one.

"In terms of add-on fields from our partners, e.g. nFeed, this is something we would like to have in JSD in the future but are currently not on our short to medium term roadmap." -JSD

Are you kidding me?  Really, I understand you need to prioritize your feature requests, but what other feature is more important than this one???

I love JIRA.  It's a great product.  But it's a product that benefits from add-ons to fill in the gaps.  We've invested in add-ons to support custom fields to get business done.  Not being able to use those on the customer portal has left me telling my customers "I hope we can do that in the near future..." for the past year.  I wish you would re-evaluate getting this feature implemented sooner rather than later.  It would help us (and I'm sure others) make our Service Desk portals AWESOME!

We're in a process of introducing a service desk software for our non-IT service teams. For them it is vital to have the customer pick / select a certain value from a nFeed custom database field. Not being able to do so, is a major stopper for using JSD in our company.

So please rethink the short/medium term decision to not support 3rd party addon custom fields.

Please add Version Pickers to those to be included.

We support multiple versions of our software and require JIRA Service Desk to support Version Pickers so that customers can advise the version they are raising a ticket against. Currently we have had to create a custom drop down picker and populate it with our versions so that customers can select. This really undermines the JIRA version functionality and I'm surprised it wasn't implemented out of the box.

Are there any plans to allow 3rd party Fields to be used in the Customer Portal. If not is there any plans to allow a multi-leveled Cascading field (single select) in the works.

ability to use one field to control
SITE>Product>Component>Common Problems

With Varying information at each would be crucial.

Thanks.

+ Multi group picker
We using Service Desk for IT management, sometimes automation.

Example: A newcomer needs some basic groups, and some special group depending on his role. These groups needs to be selected from the AD group picker. (Right now these information are written to the description).

Best:
Peter

We're in precisely the same boat as Cameron Birdwell. Our group management is necessarily in Active Directory, and JIRA is great for its ability to read and use that information. Having it missing from Service Desk Customer Portals is very frustrating! (i.e. Users who want to subscribe to a Distribution Group, be granted access to a department's network share or SharePoint, etc.)

We are using service desk for our infrastructure project which provide access to file shares, vm's, and many other things controlled by groups. These groups come all the way from AD. We would like to be able to let the user pick from the available groups to who should be able to access, R/W, or R/O.

Also, we allow the creation of Stash project through our JIRA project (we have to approve and check config of course) and we allow them to select which groups should be able to R/O or R/W to that Stash project. Since I can't put the group field in service desk it keeps my whole project out of service desk (along with no nFeed)

Hi all,

Just to provide some update on this ticket. Currently JIRA Service Desk supports all custom fields except Group pickers, Project pickers and Version pickers. The Project one is not relevant to the portal's users – please let us know how you'd use it if it's relevant to you so that we can understand your use case. 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.

In terms of add-on fields from our partners, e.g. nFeed, this is something we would like to have in JSD in the future but are currently not on our short to medium term roadmap.

— JIRA Service Desk team

Multi-Group Picker +1

multi-group picker!

Kepler Database custom fields. Actually, any database-connected custom fields and the like, NFeed or Kepler doesn't matter.
It's really disappointing to find out after creating elaborate system using db custom fields that Service Desk breaks them all.

Version picker!

date fields +1

nFeed +1

Multiple user picker

Message Custom Field

+1 for Multi-Level Cascading Select

nFeed +1

Table grid editor

Nfeed +1

Please,

-Tables for JIRA (by E7 Solutions)

-nFeed

-any 3rd party custom field

.
Thank you very much,

I also believe the NFEED support is a must, along with other custom fields.

NFEED support is a must except if there is an other way to feed list fields dynamically calling a webservice, a database or a LDAP.
This request is common and asked by customers.

Thanks

Pierre

I looking for Nfeed type of fields for integration with JSD.

Thanks,
Sumit

A custom field type with the ability to create multiple levels would be great. We are actually unable to move forward on a cloud implementation of the product because of this lack of functionality. By this I mean dropdown 1 has choices A, B, and C, and dropdown two displays only choices A1, A2, and A3 if A was selected in dropdown 1, B1, B2 and B3 if B is selected, etc.

Also interested by nFeed implementation!

FixVersion for sure should be there

erna: There is no timeframe attached to the TODO tickets. The TODO tickets are actually Feature Requests towards Atlassian, and Atlassian has its own will. Even tickets with 500+ votes are left open for years without any comment from them.

+1 to nFeed