Self-service action user input types
complete
R
Rich Rein
Is it possible to differentiate between the existing "Text" (which translates to a simple input field) and a more expansive "Text area" (which would translate to a text area input field)?
We have a few use cases where we were trying to avoid the overhead of formatted text/adding an extra click to interact with the markdown editor, and really just focused on a bit more visual space for both the input and display of plain, unformatted text. Consider the example of the description for a portal feedback item in the demo site - something like this, where I was imagining that the description might render on multiple lines and/or two columns, instead of needing to hover to see the full text.
R
Rich Rein
Aaron Taylor This request was about asking for a rendered multi-line block of text - initially merged, and then intentionally separated from this similar request. If anything, it seems like the usability of longer text strings has gotten worse (because the "hover to see the full text" capability no longer exists)?
Aaron Taylor
Rich Rein: You're right. It's only been partially solved. We're aware that viewing long text is sub-par and we're working on it.
You can track that here: https://roadmap.port.io/ideas/p/multi-line-field
Aaron Taylor
complete
You can now achieve this by toggling on "Multi-line input" when creating a text input.
R
Rich Rein
Update:
After further investigation, it appears that the data provider was the one truncating the data, not the text field. Who knew that Opsgenie only sends the first 1000 characters of a description when firing a webhook event??-----
Another wrinkle that we have run into: the max size of the existing "text" field has also been a limiting factor, trimming data coming from a datasource - so ideally a "text area" would also have a larger max size than a simple text field.
Example: We currently have a datasource defined for Opsgenie Alerts, which includes a "Description" property. Set as a "string" type, this field accepts the incoming Opsgenie alert description - which, per the vendor's documentation, can be up to 15,000 characters. While this might seem overly excessive, some of our current automated processes that generate alerts use the description field to house log file snippets and other information initially useful to the notified team as they begin troubleshooting. Today, these same alerts are having the description significantly truncated when sent into Port (we currently have no max set on that property, so I am assuming that it is simply bumping against a hard ceiling in terms of the maximum number of characters?).