I think it will not be fixed, as value unclear to vendor

I had forgotten about this until trying to flesh out a new service desk. My question still bbaker, help me get the outcome I'm looking for? Are you recommending I go the marketplace? You've told us why you aren't implementing HTML or JS in field help, can you provide some context as to why the Text Formatting https://jira.atlassian.com/secure/WikiRendererHelpAction.jspa?section=all is only partially implemented in field help? Haaaaalp us please.

I don't understand why no one from Atlassian would reference this, but we found and are using the formatting notation found here instead of HTML due to this limitation: 

https://jira.atlassian.com/secure/WikiRendererHelpAction.jspa?section=all

The top section of the image I attached is from the Create screen in JIRA, the bottom from Service Desk.  How can I get similar behavior on service desk?  What options do you have for me to markup the text in the field description so I can provide valuable information to the end-user filling out the form?

If Atlassian ultimately decides to not allow HTML or JS, could we at minimum have a type of markdown/markup implemented?

"We want to offer more delegated admin control in Service Desk"  and "Project Admins are not as trusted as Global Admins and hence adding "code execution" via HTML / JavaScript is a bad in security terms."

If these are your concerns, then why not make the ability to add executable code a Delegated permission . It is true that some organizations may not trust their project admins, but we do. 

I'm not sure how taking the option away completely grants anyone more control. It seems to me that this in fact results in less delegated admin control, not more. 

At the end of the day, it's our server and we paid a hefty price for the software . We should be able to add javascript if we need to. 

We have 3 major architectural reasons as to why the Service Desk portal does not allow custom HTML and JavaScript and they are all about security

• We want to offer more delegated admin control in Service Desk

Hence Project Admins are allowed to create request types to be presented to end customers. This means that people can get more done on their project without having to bug a central admin to do configuration work for them. We think this will scale better in customers organisations.

But now we have a delegated trust relationship in play.

Project Admins are not as trusted as Global Admins and hence adding "code execution" via HTML / JavaScript is a bad in security terms.

• We want to learn from the security mistakes of the past

Previous versions of JIRA allowed custom HTML / JavaScript on any page via field descriptions and banners. This turned into a security problem because a compromised JIRA could be changed to put more attack vectors into every page. All form the JIRA UI without any code installation needed.

Service Desk started out with the intent to not allow this HTML customisation to happen via the JIRA UI.

• We want a secure OnDemand offering of JIRA Service Desk

The OnDemand offering of Service Desk needs to be even more secure than a On Premise installation because it is public to the Internet and its also in a shared environment.

Allowing custom HTML / JavaScript has been removed in JIRA OnDemand for those reasons and Service Desk is following suit in that regard.

Cheers
Brad Baker
JIRA Service Desk Architect

Since Message Custom Field (for edit) with HTML is JIRA's basic feature, I believe this must be implemented. Many of our custom fields that is using this feature will be broken when using in Service Desk. I hope you can fix this issue soon. Thank you!

Regards,

Rakuten

@Nitram
You can do it via our plugin: https://marketplace.atlassian.com/plugins/com.intenso.jira.plugins.jsd-extender
Best regards,

Can you provide any alternative solution for this issue, then it will be good, cause I just need to make my service desk dynamic using JS.