How to jira custom field edit with a modal dialog?

Forge Forge UI Kit and Custom UI
,
1

This topic is related an answer I gave to CustomFieldEdit throws error unknown component, but as that one is already resolved and I haven’t found a solution, I decided to create this topic.

In a custom field I currently have the following code to facilitate the edit functionality:

  • edit section like described in the docu of the jira.customField manifest entry.
    edit:
   resource: some-resource
   render: native
    where the resource is
    resources:
    - key: some-resource
      path: src/jira/frontend/edit-field.tsx
  • src/jira/frontend/edit-field.tsx
    In this file I render the edit dialog like this:
    // ... Imports
export function Edit() {
  // ... Setup

  return (
    <Form onSubmit={handleSubmit(submit)}>
      <FormSection>
        <Text>asdf</Text>
      </FormSection>
      <FormFooter>
        <Stack grow='fill'>
          <ButtonGroup>
            <Button onClick={async () => await view.close()}>Close</Button>
            <Button type='submit' appearance='primary' isDisabled={!editAllowed}>Submit</Button>
          </ButtonGroup>
        </Stack>
      </FormFooter>
    </Form>
  );
}

ForgeReconciler.render(<Edit />);

This however seems to use a deprecated functionality. (See https://developer.atlassian.com/platform/forge/changelog/#CHANGE-2536 and https://developer.atlassian.com/platform/forge/changelog/#CHANGE-2023)

Reading the changelog, it was not clear to me, that this is the functionality they are talking about.
I only realized it when a red depreciation message showed up in production.

Now how do you migrate to the new version of doing this???
Absolutely no idea. Dokumentation does not help.

From the Documentation:

If you still want to use modal experience in your fields, use the Modal component for UI Kit fields and the Modal bridge API for Custom UI fields.

(See https://developer.atlassian.com/platform/forge/manifest-reference/modules/jira-custom-field/#issue-view)

I did wrap my component in an explicit Modal and set isInline to true, but that just resulted in a flashing pop-up with the red depreciation message followed by the Modal dialog covering it. Seems like that does not resolve it.

Then I tried to use <CustomFieldEdit> wrapping a Modal dialog, which resulted in “Error rendering app - encountered unknown component CustomFieldEdit”. (I made sure all forge dependencies were updated first.)
See also: Error rendering app - encountered unknown component CustomFieldEdit

TLDR:

  • Edit for jira.customField is confusing and the depreciation notice about it is not clear about what is being deprecated.
  • CustomFieldEdit usage is unclear or broken.
1 Like
2

If someone could clarify how you are supposed to implement it after the depreciation, that would be greatly appreciated!

3

Like I mentioned, using an explicit Modal from UI-Kit for the edit function results in the red depreciation message showing below the Modal.

Example

// ... Imports
export function Edit() {
  // ... Setup

  return (
   <ModalTransition>
   <Modal label='asdf' width='small' height={100}>
   <ModalBody>
    <Form onSubmit={handleSubmit(submit)}>
      <FormSection>
        <Text>asdf</Text>
      </FormSection>
      <FormFooter>
        <Stack grow='fill'>
          <ButtonGroup>
            <Button onClick={async () => await view.close()}>Close</Button>
            <Button type='submit' appearance='primary' isDisabled={!editAllowed}>Submit</Button>
          </ButtonGroup>
        </Stack>
      </FormFooter>
    </Form>
    </ModalBody>
    </Modal>
    </ModalTransition>
  );
}

ForgeReconciler.render(<Edit />);

With this approach, the red depreciation message shows below.

custom_field_edit_modal_red_message_below
custom_field_edit_modal_red_message_below655×309 20.8 KB

My current Workaround

<Modal label='Edit asdf' width='medium' height={900}>

Making the Modal big enough will cover the depreciation message entirely.
That is an acceptable workaround for now. However, it doesn’t feel like this is the way to do it because of the message rendering behind the Modal.

4

Hi everyone,

I’m running into exactly the same deprecation warning when trying to launch my custom‑field edit form as a modal in Jira Cloud Forge. I’ve tried both the old implicit modal and explicitly calling the Bridge API’s new Modal(...), but I still see the warning.

Has anyone successfully suppressed that warning or migrated their edit dialog so it no longer appears? I’d appreciate any pointers, sample code, or workarounds you’ve used

thanks in advance!

5

We have a newly developed modal app to replace the deprecated asset panel, and now they’ve deprecated this as well. What an awful way to treat your partners

6

Hello everyone,

Sorry for late response and for the confusion. I’ll review the documentation and update it to make it clearer. However before that @MaximilianSeidler you mentioned:

I did wrap my component in an explicit Modal and set isInline to true, but that just resulted in a flashing pop-up with the red depreciation message followed by the Modal dialog covering it. Seems like that does not resolve it.

Are you sure you added the isInline property in the right place? It needs to be added in the resource in app’s manifest:

modules:
    jira:customField:
      edit:
        resource: key
        render: native
        isInline: true

like it’s mentioned here.

Deprecation message shouldn’t appear when you have this property added to your app manifest. After the deprecation period is over isInline property won’t be needed anymore, cause by default it will use this experience. For now isInline can be treated as a property that let’s us know that the app is ready to be rendered in the “new” way.

I believe that the combination of isInline property name and a usage of Modal component might be confusing cause in the app manifest you specify that you want something to render “inline” but you are still rendering a modal when using this component. However, the “inline” in the app manifest means that the rendering of it’s content starts in inline space you occupy on the issue view (including modals). You can still render other stuff inline and have the modal opened up. Here is some code examples that will show you 2 ways for rendering modals with UI Kit and 2 ways for rendering modals with Custom UI. I hope this will answer your questions and help you transition your app. Additionally, I recorded a video about it (I suggest watching it at 1.5x speed :sweat_smile:). Please let me know if this helped you and answered your questions.

Best regards, Paweł

7

Thanks Pawel!

You are right. Putting “isInline” within “edit” and Wrapping the component in a Modal works fine!

I didn’t put enough thought into the “isInline” property. I should have looked it up, but for me it did make sense to put “isInline” at the root of the module. Similar to “readOnly”, it could have effects outside of the edit UI itself.
That being said, I also expected there to be a schema for each module and that forge lint would check the manifest against it. However, I do understand that the versioning of that schema would be difficult.

But honestly: Why the approach with isInline? You essentially deprecated the default behavior for custom field edit without any feedback for developers. The snipped in the documentation of jira:customField without isInline in jira:customField:edit is essentially broken until you make isInline the default.
An easy improvement would be to add a warning to forge lint that makes sure you use isInline in jira:customField:edit until isInline is the default. That would have informed me that I am deploying deprecated functionality. But from my point of view, the main problem with the isInline approach is that long term you are trying to make the exactly same manifest behave differently across versions just for the sake of keeping it clean I guess? Why not jira:customField:editv2 for example?

Anyways, thanks for clarifying the use of isInline and also showing the use of CustomFieldEdit, which is very much confusing as well.

Kind regards,
Maximilian Seidler.