URL doesn't seem to be displayed properly in manual task.

[zl6977]

My environment

Thanks for this great low-code platform.
I am using spiff-arena in docker on windows platform, and my browser is Chrome 113.
I install spiff-arena following this article.
I think I found a bug that URL is not displayed properly in a manual task.

Here is an example to reproduce the bug.

Fig.1: a simple workflow

Fig.2: the configuration of the manual task.

Note “Pre-Script” and "Instructions". I paste them here:
“Pre-Script”: d = {"a_url": "http://example.com/a.json"}
"Instructions": {{d}}

Fig.3: What I see when executing this BPMN.

The related HTML is <p>"{'a_url': '"<a href="http://example.com/a.json&amp;#39;%7D">http://example.com/a.json&amp;#39;}</a></p>
What I am expecting is a clean string without the HTML code, and that the URL is a valid one also without the HTML code.
I.e., <p>"{'a_url': '"<a href="http://example.com/a.json">http://example.com/a.json'}</a></p>

I think this is a small bug, please consider fixing it.
Thanks in advance.

[burnettk]

Hi, thanks for the wonderfully-detailed bug report! It would probably make sense to do something a bit better by default here when a dictionary is rendered. We will think about how we might do that. I also just wanted to point out that you can do something like this in your instructions to give the user a nice link:

Check out this [awesome url]({{d['a_url']}}).

This uses [markdown](https://www.markdownguide.org) link syntax alongside the jinja. You had probably already noticed that this was possible, but just in case!

Also, thanks for your kind words about the product. If there is an opportunity to work together in the future, please just let us know. We're always looking for sustainable ways to fund the project. :)

[zl6977]

Your great work deserves the kind words, as everybody likes an opensource solution :)
And thank you for providing a workaround. I can modify some of my instructions in my demo project.

Still, as you mentioned, if it is not a heavy workload, please consider doing something here when rendering a dictionary by default. As the dictionary to be rendered may contain many URLs.
For example, I am running a demo server to provide some web APIs and the outputs of them are some files on a file server. The returned JSON is something like this:

{
"file_qwer_a":"URL_a",
"file_mnbv_b":"URL_b",
......
"file_asdf_n":"URL_n"
}

When there are many URLs, modifying instructions one by one maybe not be the best way :)
Furthermore, sometimes you may not know the keys in the dictionary in advance.

Certainly, you have your own concerns and priorities. This is just my suggestion based on my limited experience.
I will follow this helpful project.
Good luck and thank you again :)

[jbirddog]

I played around with this and while not exactly what you are asking for, this may serve as a decent work around. Given task data such as:

d = {"a_url": "http://example.com/1", "b_url": "http://example.com/2"}

The instructions:

| Key | Value |
|----|----|
{% for k, v in d.items() %}
| {{k}} | {{v|safe}} |
{% endfor %}

Will give you a table such as:

Key	Value
a_url	http://example.com/1
b_url	http://example.com/2

Not saying that we should not change the default output, but one advantage to an approach like this would be that you have more control over the output.

[zl6977]

@jbirddog Thank you for providing another useful workaround. I am not familiar with Jijia, thus I did not think of this workaround :)
Good to know you plan to do something here and good luck with the bug fixing.
By the way, looking forward to more articles at "https://www.spiffworkflow.org/posts/article" or somewhere else :)

[danfunk]

@zl6977 - be sure to check out our videos on youtube as well (https://www.youtube.com/channel/UCtDHzDfhyvnAb8CFmdwucUA). If you would like to help us out, please consider writing a few sentences that we could use on our website (along with a picture, your name, and your company). Star our projects on GitHub. Follow us on Twitter and Linked In and repost some of our stuff. Sign up for our newsletter, which will come out this week with a long list of features and bug fixes for the last couple of months. You can do much of this on our website. You can send me the endorsement over email to dan@sartography.com. These are great ways to show us you really do appreciate the work we are doing on the project.

[danfunk]

We reviewed this ticket as a group today and determined that the "safe" pipe is a wise requirement when injecting variables into the markdown - as this could be used to inject javascript into a webpage by a bad actor completing a web form. By using the "|safe" it encourages the BPMN author to assure that the data they are displaying the markdown will always come from a trusted source (such as a dmn table or script task) and not from a user form. Closing, but please re-open if you would like us to consider this in the future.