"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

We need cascading select and single select in the customer portal.

It cannot. We use it, but we can't use Customer portal because of this.

Can someone confirm if "Database custom field" be displayed in Customer portal?

https://marketplace.atlassian.com/plugins/com.keplerrominfo.jira.plugins.databasecf/server/overview

Thanks in advance

I have found that the Tempo Timesheets Plugin "Account" field is not currently supported. I would like to see this made available.

As an aside, this is also not working when added to a JIRA Software issue type/screen AND then used with Zendesk integration where Zendesk pops the screen. I have reported to Zendesk also.

+1 to nFeed

It looks like cascade select is working on cloud now.

Any word on what version of server this will be available?

Version pickers please

Single autofill issue picker

+9999 Customer request type Not needed on Customer Portal, i need it when i create a ticket on BackOffice...

+1 to nFeed

Cascade Select seems to still be an issue in v3. When can we have this feature?

+1 Multi Cascade Select
+1 Calculated number

+ Table Grid

Valiantys nFeed please

+1 Multi Cascade Select

Version selector should be nice!

Need Versions to be available.

Any custom fields related to the Kepler ROM add-ons.

+1 for multi level cascade select. Are there any plans for a release?

This "Suggestion" issue should really be set to something like: "Requirements - Bug". Come on, did they really intend to design JSD with a restrictive set of JIRA Issue functionality/compatibility?

+1 for nFeed

For my organization it is also a need to have a custom field to be visible in Customer Portal. The field we need is the component field.

Is there a planning in which release will this be available?

We definitely need this feature. As a matter of fact, all fields that works in JIRA should work in JSD, it's a plugin to JIRA. I understand all the problematics around getting that to work, but you're going to fix this please fix this the right way.

Adding a few custom fields types to the list of "accepted" fields just won't cut it, since you'll have another issue opened 2 days after requesting for more, so please just fix this once and for all, and make all custom fields works in JSD, no matter the type (even from marketplace Addons).

Thanks,

This is an interesting plugin. I'm not surprised it works on the customer portal since it's simply creating a JIRA-baseline option list for you. My problem is that there's no way to run dynamic options on the portal. For instance, the Kepler database value custom field allows you to use fields like "reporter" in your query. So we have the ability to show the customer a list specific to them (e.g. hardware they own). But right now that only works for technicians on the customer portal (i.e. jira users).

We swiched to the "Custom Field Option Synchronizier" Plugin:
https://marketplace.atlassian.com/plugins/ch.bitvoodoo.jira.plugins.customfieldsync
Til now we have over 30 CFs with synced options, some of the CFs have even several thousands of options.
Works like a charm for us.

We are also developing a Service Desk and having the same issue. I am using the Query Issue Linker plugin field to pull a list of application from our CI "Configuration Items" project, so that the person logging a software issue can select the software they are having issue with. We can then use that information to route the incident or SR though to the correct queue so that the right team can respond to the issue.

Without this we would have to create a manually updated drop down list for each item of software we have. (double up of work). We would like our config management project to be the single source of the truth.

We are currently developing Service Desk to launch in the August time frame. It was a shocker to see that advanced custom fields don't work on the customer portal for users in the customer list when they work perfectly well for jira users. This will mean a huge downsizing of plans to automate processes right from the customer point of use.

We are using the Kepler plugins and in particular the database custom fields.

JIRA option: Add Custom Field -> Advanced -> JSON Request Custom Field (with the description: Feed select list option using http via JSON). Is the custom field type mentioned by Oliviu.

The link from previous comment suggests to a a single choice select list for this moment.

I have added such custom field and this is still not returned in JIRA service desk. Is there a way to workaround this?

In addition I tested I have tested with checkboxes; select list (multiple choice); select list (single choice) and all field types are not visible in JIRA service desk customer portal

After configuring the fields on the screens automatically generated by service desk the fields are visible for me

I was advised by Matthew McMahon [Atlassian] to add my requirements here.
Please see: https://answers.atlassian.com/questions/17434154/answers/17440476?flashId=1379308788
If not appropriate let me know.

Cheers.

Is there a timeline when custom fields will become available in JIRA service desk request types?

We are currently setting up and configuring service desk projects for our customer as external service desk. This functionality would be required to address some specific scenarios where customers report certain issues and incidents.

Hi Joshua

Our customers have been requesting the Tempo Account custom field and the Tempo Team custom field. We would much appreciate these fields in JIRA Service Desk. For an example request please see: https://tempoplugin.jira.com/browse/JTMAC-186.

Thank you for your assistance and a great product.

Best regards,
Heiða Dóra
Tempo Team

+1 for XML Request Custom Field (This can also show the database related possibilities with an easy server-side script with XML outcome)

still open

can your provide an update on the dev status of this issue ?

+ 1 for nFeed

+1 for Project Picker
We want service desk users to be able to select the project that the request related to. It can be a hidden field with a preset value, but we need them to choose.

+1 for Labels (existing labels do not appear in customer portal)

+1 for Security Level (form and comments, just like JIRA already does...)

+ 1 for nFeed

+ 1 for nFeed

+1 for nFeed

+1 for nFeed

+1 for nFeed compatibility

+ nFeed

+∞ for nFeed

Where is the like button for comments?

+∞ for nFeed

+1 for nFeed

+1 for Group picker
+1 for Labels
+1 for Multi level select
+1 for Calculated number
+1 for nFeed

You forgot nfeed!
We also have CRM by Teamlead and we need the CRM-custom fields.

Situation:
Within company A there are five help desk individuals supporting 500 users. When user 1 submits their ticket they will be able to watch the progression of their ticket through the customer portal. However if they had an emergency regarding this particular case and needed to speak with the Assignee, they are unable to determine which of the five members of Help desk have ownership. So they either have to ask each individual or a new help desk member must become acquainted with the details of this case.

Suggestion:
Have a field within the customer portal so they can view who the Assignee of this case/request is.

Opinion:
This would assist my user base and increase efficiency of the communication between reporter and Assignee. Any verbal conversations can then be added by the Assignee to make sure the case remains up-to-date.

When will this be implemented ? there are enough votes to do something about it.
This ticket is 2 years old and nothing happened. So whatfor should we vote ? I will be dead until this get implemented and that i do not need it anymore.

nfeed please!

+1 for nfeed

nfeed, please. we'd love to be able to integrate our nfeed fields into service desk to pull institutional data in.

"Request Partecipiant" field.

Thanks

Dear Atlassian

We would gladly welcome the possibility to add Group Pickers type (both Single and Multi) fields to the field screen.
[SDS-3179]

One of the usage would be a jira-project creation automation. ( The requester create a ticket about the project details, among others the set permission schemes, ticket types, roles for users and groups), and with an approval workflow we wanna implement the automatic creation.
But there are so many other way to use multiple group selection... please implement it.

Best Regards:
Peter Cselotei
Tool Master of InfomatX Ltd.

any update about this ? a workaround to implement a Multi-Level-Cascading Select Custom Fields (from 4 to 6 levels depth) would be also fine

We still need Multi-Level-Cascading Select Custom Fields (from 4 to 6 levels depth)

Hi JSD Team,

Again, regarding to Level Security field, IMHO there are 2 distinct problems around this topic:
1. Because Level Security field is not currently supported, after activating JSD for a given JIRA project, it turns off such control inside JIRA. Such behavior is really bad, cause it leads JIRA to lose control relating to issue isolation;
2. (Again) Because Level Security is not currently supported, it also turns off (or replace) the possibility to use security level on comments (inside JIRA), and it's bad as well, cause it disables an important feature.

Suggestion:

• Create a new configuration on JSD and let the user decides in using JIRA Level Security default or accept the new control implemented on JSD (Level Security disable).

Opinion:

• I think it's pretty OK the JSD has its own behavior (inside Customer Portal), but it should not disable so important controls, as Level Security, inside JIRA.

Hope your considerations. Thanks in advance.
Michel Barros

This one is rly Business Critical, we are currently in process of evaluating SD to provide a new solution for worldwide Handling & Operation Support, thus we need to implement different kinds of Online Request Forms containing Multi-Level-Cascading Select Custom Fields (from 4 to 6 levels depth). We identified the Multi-Level Cascading Select PlugIn as usefull - but actually we run into that impediment, it's not currently not possible to add the custom field to SD Customer Portal.
Please provide an estimated date for a fix or a hint for a workaround.
Thanks!
Dennis

Hi JSD Team,

Here you have my particular scenario and thus why Level Security field is so important for us:

in JIRA

Users

• john.smith (as customer working in company A)
• paul.evans (as customer working in company B)
• bob.farewell (as a help desk attendant)

Security Level Scheme using the following levels

• Company A, which has the following users in its group (john.smith, bob.farewell)
• Company B, which has the following users in its group (paul.evans, bob.farewell)

in JIRA or in JSD when user needs to create an issue, we'll face the following possible scenarios:

• if john.smith try to create a new issue, since JSD disable the possibility to set the respective level security... OK, using some script (by Script Runner or other similar plugin) will be possible to programmatically set the respective level security.

• if paul.evans try to create a new issue, (again) since JSD disable the possibility to set the respective level security... OK, using some script (by Script Runner or other similar plugin) will be possible to programmatically set the respective level security.

• However, if bob.farewell try to create a new issue, since he is part of help desk team as an attendant, he is in both Security Levels and, due to that, even using script coding, is not possible to programmatically decide which of the two levels security to set or use.

After saying that, please help me to address such tricky scenario. Cause, actually, for us one of the main purpose of installing JSD was to control customers SLAs and thus not to change the current process to create issues in JIRA, or even start to creating issues through Customer Portal.

Hope your considerations. Thanks again. Best,
Michel Barros

Hi JSD Team,

As a MUST HAVE field, please consider the implementation of Level Security JIRA special field for customer data isolation control.

It's pretty much necessary in order to avoid breaking security issues inside JIRA. I'll write an use case exposing our current scenario.

But, for now, please consider such urgent implementation. Thanks in advance. Best,
Michel Barros

+1 for nFeed

This is literally one thing that prevents us from buying Jira SD for 2,5k users. We need a custom field - multi-level cascading select to let users choose a job on which the ticket will be charged. Too bad it looks like there's no progress on this issue.

nFeed would be great!

I have a need for Custom Calculated Number Fields to be part of the Service Desk portal.

Create an option for a cascading select list with at least two levels. When the user selects a value from a list, another corresponding field populates allowing the user to select another value from a different list. The current cascading select list plugin does not allow for this. I would need at least 2 level for our ticketing workflow to be managed in jira.

All jira fields should be candidates to include in the service desk. At a minimum I need "issue security" to be able to be set by the user NOT a hidden field with a preset value. Hidden fields with preset values largely make custom fields and fields like issue security useless in the SD arena.

Hi there, from my perspective Service Desk needs to support other custom fields from 3rd Party addons (nFeed, Multilevel cascading select list).
In my oppinion it's a must to be very flexible in configuring the different input values in the customer portal also allowing more data logic than possible with the standard built in JIRA fields.
As long as this is not possbile - beneath some other major issues like licensing model and multi project association - I get the feeling that Service Desk is not realy ready to be used for professional Service Desks / in bigger companies.

nFeeds support would be greatly appreciated – we're trying to use Service Desk to drive internal operations and we need to pull values from a number of data sources.