Hide Ticket Form Based on Customer Organisation - Copenhagen 4.2

A company using Zendesk will often have many different ticket forms available and may want to limit which forms are availble to end-users submitting requests from the Help Centre for myriad reasons.  One common request is to be able to restrict form visibilty based on an end-user's organisations.  So common is this request, that there are many how-to guides published to help accomplish this workflow.  Recently, Zendesk has upgraded the default Copenhagen theme to version 4.X, and this has resulted in the solution provide by the most commonly used Help Centre article to no longer function as intended.  Thus, we have created the following article to show how this can be accomplished with the newer Copenhagen themes.

Original Solution:

The original solution detailed here has provided an excellent solution, and we have used it in the past and even referenced it when looking to answer a user's question about Copenhagen 4.2. However, our testing showed that this solution did not work for the newest Copenhagen theme versions, so we decided to build out a new solution.

Premise:

There may be many attributes that can be used to determine which forms should be shown to any end-user.  For the purposes of this tutorial, we will be using organisation.  Please feel free to leave a comment if you have questions about other types of workflow requirements.

The Process:

Zendesk does not provide a default feature to hide ticket forms based on a user's organization, but fortunately it is possible to modify the source code of the Help Centre theme to do just that.  To learn more about modifying the source code, please refer to the Zendesk Help Centre article here.

For our case, we will be modifying the script.js file, but the code could also be placed in the footer.hbs if so desired.

The Code:

 const userOrgs = window.HelpCenter.user.organizations;
 const userOrgNames = userOrgs.map(org => org.name);
 if (!(userOrgNames.includes("ZENDESK"))) {
   $('head').append('<style type="text/css">#id\\:0--option-2 {display: none;}</style>');
 }

The code we use is relatively simple and straightforward.  An explanation of each part is below:

const userOrgs = window.HelpCenter.user.organizations; -  This line will grab the currently logged in user's organizations from the Zendesk provided HelpCenter object.  To learn more about the Help Center object, please see here.

const userOrgNames = userOrgs.map(org => org.name); - We will be using the name of the organization for the rules, so this line will extract the names of the user's organizations.

if (!(userOrgNames.includes("ZENDESK"))) {
   $('head').append('<style type="text/css">#id\\:0--option-2 {display: none;}</style>');
} - this will check if the user belongs to the organization we want to target, which in our case is ZENDESK.  If the user doesn't belong to this organization, then we will add a new style element which will hide the targeted form.

Targeting the form is a bit more complicated in the new Copenhagen theme, and for our use case, we are targeting based on the form's position in the dropdown.  In our case, the form we want to hide is the JIRA Problem ticket form, which is 3rd in the list.  So, based on 0-index we will target option-2. 

Further Explanation:

For the curious, I will also explain how we were able to dig into the HTML in the form picker here.  If you open up the form picker and then try to inspect the HTML, the picker will close on you.  This is because Zendesk has a javascript-based component to show the form.  So what I did was to first examine the nearest element I could - an invisible placeholder for the form dropdown, which is a UL element.

Then, I set a breakpoint on that element when the Subtree elements are modified.  This allows using the debugger to pause execution of the javascript at key moments so the HTML can be inspected when the dropdown list is visible on the page.

Next, click on the ticket form dropdown.  You should see that the script will pause after each form is added to the list, so you'll want to continue until each form is visible, or at least until the form you want to modify is visible.

Next, you should be able to go back to the Inspect Element tab and start taking a look at the elements in the list.  We are focusing on the <li> element, and then running a few tests on this.  For example, I can delete the node directly to see if that is in fact the necessary element to target.  After confirming it is, I can proceed to test out different CSS, such as adding a display: none; rule, which in my case worked just swell.

The last part was to figure out how to apply a rule to target this element.  I saw that there is a unique id for each li, and so that is a good option.  You could probably choose other selectors as well, such as using nth <li>, among others.

The hardest part for me was to figure out how to target the CSS for that element specifically, because it doesn't appear to exist in the DOM until the user opens the drop-down list, so if we were to use JS to target the element on page load, it would fail because the element is not yet loaded in the DOM.  Instead, we should be able to apply a CSS rule to the page directly, so that way it will apply as soon as the element is added to the DOM.  In this case, I learned how to use JS to add a new style rule to the page, and also that the colon (:) needs to be escaped in the selector in order to work.  The result is this line of code:

$('head').append('<style type="text/css">#id\\:0--option-2 {display: none;}</style>');

In this case, I am using jQuery to append the code because it has already been loaded by Zendesk, but I did see other users mentioning about VanillaJS solutions, which should be able to use document.querySelector instead.

We hope this article has been both helpful and informative.  Please feel free to leave a comment below!