More customization in Email to send User Options by Email in SMA SM

[Tamer_Saber]

Customer would like to have the ability to send user options in Email in SMA SM currently email will send user options as XML extension and doesn't look good so customer is looking to have the option of sending user option by email in a customizable way.

This will be very useful specially for approval by email and approvers can know exactly what is requested

[Alan Gross1]

The User Options (Dynamic Format) is nothing else than an XML String.

You can quite easily transform the XML String to HTML and include it within an email.

But it requires some JS coding - see the JS programming reference regarding XML Objects:

https://docs.microfocus.com/itom/Service_Manager:9.63/JavascriptObjectxml

[Tamer_Saber]

Yes i understand @Alan Gross1  however this method will need to be implemented so customise per catalog item per Email which will take ages because the user is using multi language service manager Arabic and english in which one of them is left to right and the other is right to left so yes this could work however it will not provide the level of information the customer is looking for 

[Alan Gross1]

@Tamer_Saber 

No, you don't need to implement this per Catalog Item.

All you need to do is to write a generic JavaScript function that transforms a dynamic form into some Parameter/Value format. It will require a bit of time to write this function since you need to deal with the different user option attribute types Text, Multiline text, Pick List etc.

In your email html template expressions you call this function include the output in your email as a variable. I have implemented the same previously for customers and I can confirm that this is not a huge challenge.

There are also some OOB Libraries which more or less provide exactly what you need - e.g.

lib.UserOption.getOptionsFromXml - returns multilayer array with Structure: optionName, OptionLable,  OptionValue, isMultiline, type

Regarding the multilingual support - this some additional challenge. The problem here is, as far as I know (it has been a while since I dealt with multilingual SM systems), that the OOB implementation is only supporting multilingual Catalog Items Options from the "Requester Role" perspective - means that the user options are always persisted under the language of the user that has requested the catalog item - which is complete non-sense since users using different languages might be looking at the same record (Requester, IT Service Desk, Fulfilllers etc.)

However - you are able to deal with this issue using the svcDisplay table. This table contains the dynamic form definitions per catalog item and language. Therefore all you need to do is to evaluate the email recipients language first, select the svcDisplay record of the corresponding language and now parse the dynamicForm for the corresponding attribute id and grab the label in the corresponding language.

[Barry Wood]

This gets my vote - I completely understand that this could be achieved by customisation but this should be standard capability for the product.   The ability for users to approve requests via email is in my opinion very much missing the point if the users can't see what they are meant to be approving.