nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Display Conditions for JSM Portal Request View Action

Harrison Ponce

We've been really trying to use Forge to do some cool things, but run into some limitations here and there. Here's the current situation:

We'd like show a custom JSM portal request view action alongside other of the buttons that the customer can interact with (e.g., Cancel, Notifications, etc.)

For our use case, we'd like a customer to be able to re-order something they've done in the past, simply by going to a past (statusCategory = Done) order and seeing the option. The rest of the app functionality we have working.

The problem we're running into is that there is no way to display this only for the specific service project, issue type, and statuses we want them to display for. This is possible in Jira and other modules via display conditions, but not for JSM yet it seems. So, this would be an all-or-nothing custom request view button across every single service project. This is a no-go for us.

We could slide this service project into another site, but that doesn't solve all the problems and seems more hassle than it's worth.

We might explore some other options with links in automated comments, but for now I'm curious if anyone else has a workaround for this or any ideas.

Thank you!!!

Accepted answers

Tim Pettersen

Hi @Harrison Ponce

Unfortunately as you've observed we don't yet support conditionally displaying actions in Jira Service Management.

A couple of options you could consider are:

- Adding a Portal Request Detail Panel named "Re-order request" and display something like "This is not applicable for this request type." for unsupported request types / projects.

- Removing the action from the request view entirely, and adding a "Re-order request" action to the JSM user menu. You would then need to present the user with a search for previous issues, perhaps a Select component populated based on a JQL query based on something like `reporter = currentUser() and issueType in (x,y,z) and statusCategory = Done".

The latter seems more appealing if most of your service projects won't support the re-order feature. The user menu isn't very discoverable though, so you could consider calling attention to the re-order feature using a Portal Header.

Hope this helps!

cheers,

Tim

All comments

Tim Pettersen

Hi @Harrison Ponce

Unfortunately as you've observed we don't yet support conditionally displaying actions in Jira Service Management.

A couple of options you could consider are:

- Adding a Portal Request Detail Panel named "Re-order request" and display something like "This is not applicable for this request type." for unsupported request types / projects.

Hope this helps!

cheers,

Tim

Harrison Ponce

Thanks so much, @Tim Pettersen for your detailed response. I'm pleasantly surprised and appreciate the partnership here!

Thank you for giving me ideas for alternatives. We are able to pull off a JSM user menu without too much distraction/impediment to the other service projects' customers. I might write up an article on our use-case and how we used this nifty trick to solve it.

As far as display conditions for JSM, I know that JSDCLOUD-16190 is out there gathering interest. Can you share if the team has acknowledged this as a future roadmap item and roughly when we might expect it? (Knowing that whatever you say is not a promise for work from Atlassian on any specific timeline 😁).

Seems like good parity with the other product (app) modules and I'm not sure what's on the roadmap currently or ahead - or if there's even a good way customers can see that for Forge.

Tim Pettersen

Glad to hear it @Harrison Ponce

Unfortunately displayConditions for JSM are not on the short term roadmap, but I have seen it crop up in a number of customer use-cases recently (including yours). I'll re-raise this with the JSM team for consideration.

In the interim, for most modules you can return an empty UI Kit component from your app to effectively "hide" the user experience.

For example to conditionally display a portal header (as in your more recent comment) only on request portals with id 4 or 9, you could do something like:

import React, { useEffect, useState } from 'react';
import ForgeReconciler, { Text, useProductContext } from '@forge/react';

const App = () => {
  const context = useProductContext();
  const [portalId, setPortalId] = useState(null);

  // only display the banner for these portals
  const enabledPortalIds = [4, 9];

  useEffect(() => {
    // Ensure context is available before proceeding
    if (!context) {
      return;
    }    
    setPortalId(context.extension.portal.id);
  }, [ context ]);

  // If the portal is not in the enabled list, return null to render nothing
  if (enabledPortalIds.indexOf(portalId) === -1) {
    return null;
  }

  return (        
     ... Your portal banner experience goes here ...
  );
};

ForgeReconciler.render(
  <React.StrictMode>
    <App />
  </React.StrictMode>
);

Unfortunately you may see a brief flicker of the panel loading bar appearing and then disappearing when the panel initially loads.

This technique should work for pretty much any UI Kit-enabled extension point that doesn't require a `title` property in the manifest. Unfortunately there isn't a currently a way to suppress a module title from being displayed without displayConditions.

cheers,

Tim

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

cloud

customer-portal

jira-service-management-cloud

jira-service-management

forge