Is There A Way to Submit A Modal Form Without Having to Attach a Resource

Sorry if this has already been answered elsewhere: I just couldn’t find anything that really answered the question.

We have a private app that uses modal forms to generate project tasks based in a similar way that a template would (we quickly found out we would need far too many project templates to be practical or manageable), to require necessary information to minimize digging for information, and to propagate critical information across all tasks in the project without having to switch between screens. It’s worked wonderfully for us so far, and I’ve been working on some quality-of-life improvements. I’m running into the same annoyance I had when I was first building the app that modal forms require an attachment to be sent back on submission to avoid an error. We have no use for them, and I’ve ended up just dropping in project information pages no one will ever bother looking at all over the place every time a form is used.

I’ve tried returning a resource name like a message with a null resource URL. I didn’t have high confidence, but I figured I’d give it a try. Is there no way to return something like an { action_result: “ok” } (tried this too) like you can with webhooks, or am I just stuck with a pile of pointless links cluttering up my activity logs?

It’s been a few years since I learned the ins and outs of App Components, so I’m struggling a bit to remember.

Are you using a modal form in conjunction with displaying a widget on the task, or no? If not, what’s the context in which you’re displaying it?

No, we really don’t need the widgets. We’re pulling a form from any task, filling out the form, and then working in the tasks it generates.




I don’t need that Show Page link in there, but I’m forced to return some kind of attachment when the modal form is submitted in order to avoid returning an error.

Hi @Kariah_Petrille,

Unfortunately our API requires that you send an attachment response when we make a call to your app server’s On submit callback endpoint. Hence why we marked it as required in our docs:

The reason for this is because the modal form and widget are tied to the attachment.

That being said, when we make an API call to your app server’s On submit callback endpoint we send an attachment ID in the POST request body that you can use to look up the story on the task (Get stories from a task) that has the attachment on it and delete that story (Delete a story).

NOTE: this is a documentation bug we should have attachment shown under the “Body Params” section of our On submit callback endpoint

EX: req.body of Asana’s API call to your app server’s On submit callback endpoint:

{
  data: '{"attachment":123,"user":456,"workspace":789,"expires_at":"2024-08-06T00:58:54.770Z","values":{"single_line_text_full_width":"","single_line_text_half_width":"","single_line_text_full_width_is_watched":"","multi_line_text":"","rich_text":"<BODY></BODY>","dropdown_half_width":"","dropdown_full_width":"","radio_button":"1"},"task":91011}'
}

You can take the "attachment":123123 response and make a call to Get stories from a task endpoint to get the stories on the task. Then filter for the story that has the attachment on it and call Delete a story endpoint.

NOTE: for your Get stories from a task you’ll probably want to specify html_text for opt_fields since the content from the html_text will contain the attachment_gid

Example response from request to Get stories from a task with html_text in opt_fields

{
    "data": [{
        "gid": "789",
        "html_text": "<b><a href=\"https://app.asana.com/0/profile/456\">Demo</a></b> attached <a href=\"https://app.asana.com/app/asana/-/get_asset?asset_id=123\">I'm an Attachment</a>"
    }]
}

Thanks, John! I think that will be a quick fix to the problem.

Not 100% sure but my memory tells me the reason an attachment is required is that the modal form was designed to really work in conjunction with setting up a widget on a task, and the attachment is what tells Asana to display the widget. @John_Vu am I remembering that accurately or no?

1 Like

@Kariah_Petrille . @Phil_Seeman made a good point. I did some experimentation and it looks like what Phil said is true. The modal form and widget is tied to the attachment which makes sense why we require the attachment response for On submit callback. I also confirmed this with our team. I’ll fix my previous answer.

@Kariah_Petrille instead of deleting the attachment, I would delete the story that mentions the attachment instead.

See the video’s I’ve linked for the behavior:

1 Like

Since we’re not using the widgets at all, would there be any practical reason for doing it this way? What it’s returning is a throw away webpage as an attachment. If we were using the widgets, I see this would probably cause a host of problems, but we really have no need to display data like this, and I don’t see any time in the next few years where we would.

The problem that made me bring this up in the first place is that there is no simple way to identify which story it is that needs to be deleted until after the process is done, requiring me to go back and sort through all the stories on a task to find the one I need. There may be just the one, or there may be a dozen. There also aren’t any other UI options that can fulfill the same function as this one is able to even if this isn’t what it was necessarily designed to do.

Hi @Kariah_Petrille, it seems like you just want to use the app component modal form to add the functionality to fill out a form on a task and don’t care about the widget or the association of the modal form being filled out to the task. If that’s the case you could probably just delete the attachment. In other words, you are ok with deleting the attachment and if the user de-auth your app and re-installs the app again they won’t see anything associated with the form they previously filled out for the task that had the app component attachment on it.

If you however, want the form being filled out to be associated with the task and don’t want the story to be there you would have to delete the story.

1 Like

There’s stuff saved on the server that changes the form, but it’s associated with the project as a whole and not the task requesting the form. Project data isn’t specific to the user, so de-auth shouldn’t affect it.

I see, so your app server changes the form based on the project and doesn’t care about the form being associated with the task. Thanks for the explanation. This is unique use case to solve with app components but it seems like you figured out a way to use it that’s best for you workflow.

It’s basically a replacement for a bunch of project templates to make it more manageable to keep up with when things change + a way to guarantee that all needed information gets put in and ends up where it needs to be.