Self-service action user input types
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
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?).