Multiline input in text box is changed to single line

Brett

I made the change to the Cireson portal from the Microsoft portal and have been validating all my current requests are still behaving as intended in our DEV environment.  We have a form that users enter multiple lines of text into, once the service request is submitted I take that data, parse it and enter it into a SQL table so I can reference it as I build out a service request with the information.  With the Microsoft portal the line breaks would stay, in the Cireson portal it sends the data as one line so when I add that text into the service request it becomes hard to read.

Text entered into form
Source:  TEST
Destination:  TEST2

After applying this text to a service request
Source:  Test Destination:  TEST2

Is there any way I can prevent the Cireson portal from doing this?  I have researched possible CSS changes and formatting the data with powershell but have come up empty handed.  Any help would be greatly appreciated.  Thank You. 

Konstantin_Slavin-Bo

Okay, I see. Maybe something gets lots in translation to/from XML? We are (rather were before Advanced Request Offerings, which you really should check out!) doing it the same way, just without any SQL, which I honestly don't understand why are using? In Orchestrator, you can simply get the SR with all the custom properties and input those directly into the Description or whatever of the SR, with any formatting and ordering you want. What do you need the db for? 

Also, you say you are parsing the user input by parsing the XML. Why is that? Why don't you just access the properties directly in a Get Object activity and then update the SR with an Update Object activity? This should get you the raw input as strings, so any line breaks etc should be preserved.

Here's a simple example from on of our (old) runbooks, where the editor is for Description:


I realize this doesn't answer your actual question, but it seems like you could do this whole thing a better way. I can of course be missing out on why you are doing it the way you're doing it, in which case just ignore what I said, and lets find out why it isn't working. But if not, you should design your runbooks this way, in my opinion of course.

And I would like to give another shoutout to Advanced Request Offerings, which is really awesome, because you get to skip all these custom properties and runbooks for every RO, as you can simply map every prompt / question to e.g. the description field or anything else, ordering it the way you want, writing additional text, anything you want. And that's not even talking about the dynamic-page prompts!

Konstantin_Slavin-Bo

So you have one text prompt in a RO, where users enter multiple lines of text and you store the text somewhere in a property on the SR? And you experience, that the input loses the line breaks? We don't experience that, when mapping a text prompt to a custom property nor the description field but we do when mapping to e.g. the title field (we are not running community edition, though). I'm actually not sure what the difference between the properties are, as they all just are of type string.
Which property/field are you mapping the input to?

Brett

We are mapping the user input to a custom field on the service request, data type of string.  However, those custom fields are only used so I can map the questions on the ROs.  After the request offering is submitted on the portal, it actually goes to Orchestrator where I parse the XML (User Input) and insert the answers into a SQL table.  In Orchestrator I then pull my answers from the SQL table so I can update the titles and descriptions of the SR, RA and MAs.  Seems kind of complicated but it was the best way I found to build out a service request with a 15 question RO instead of mapping a single question to the description field

From what I can tell the issue is between the submitting of the RO and Orchestrator parsing the XML.  In the portal the input stays as multi line, but as soon as it is submitted the input is transformed to one line.  The input stayed as multi line with the Microsoft portal and I really don't want to go back to that, as the Cireson portal is much nicer.

Konstantin_Slavin-Bo

Okay, I see. Maybe something gets lots in translation to/from XML? We are (rather were before Advanced Request Offerings, which you really should check out!) doing it the same way, just without any SQL, which I honestly don't understand why are using? In Orchestrator, you can simply get the SR with all the custom properties and input those directly into the Description or whatever of the SR, with any formatting and ordering you want. What do you need the db for? 

Also, you say you are parsing the user input by parsing the XML. Why is that? Why don't you just access the properties directly in a Get Object activity and then update the SR with an Update Object activity? This should get you the raw input as strings, so any line breaks etc should be preserved.

Here's a simple example from on of our (old) runbooks, where the editor is for Description:


I realize this doesn't answer your actual question, but it seems like you could do this whole thing a better way. I can of course be missing out on why you are doing it the way you're doing it, in which case just ignore what I said, and lets find out why it isn't working. But if not, you should design your runbooks this way, in my opinion of course.

And I would like to give another shoutout to Advanced Request Offerings, which is really awesome, because you get to skip all these custom properties and runbooks for every RO, as you can simply map every prompt / question to e.g. the description field or anything else, ordering it the way you want, writing additional text, anything you want. And that's not even talking about the dynamic-page prompts!

Brett

We are parsing the data and putting the answers into SQL tables so we can reference and make decisions based on the answers in the request across multiple runbooks (The complicated ones at least) along with using it to dynamically add reviewers, add additional information into the request without having to ask it on the ROs and all the automated tasks like adding users to groups etc..

However, I did not know that you could reference the extensions of the service request in Orchestrator.  I was always using the default Class 'Service Request' and not my saved extension class therefore I never saw my extension as options.  I changed the runbook to update the description field from my extension class and it now comes in on multiple lines as typed in the RO.  Thank you very much!  Based on this, the SQL and parsing does seem unnecessary.

I have looked into the Advanced Request Offerings and it looks great, would love to have dynamic forms!  Maybe one of these days...

Thanks again!

Konstantin_Slavin-Bo

No problem! You gain a lot of easy and powerful functionality this way, I'm sure you will find new, fun stuff to do now. I can't image having to go through the default SR class and parse XML each time a RO comes in!