Idea ID: 2826578

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

Status : Waiting for Votes
Waiting for Votes
See status update history
10 months ago

 

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

Labels:

SMA-SM
Parents
  •  

    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.

Comment
  •  

    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.

Children
No Data