locked
SCSM Portal not displaying "Default" values from incident template in Request offering RRS feed

  • Question

  • Hi,

    OK here is the situation:

    1. Extended Incident class and modified the Incident Form (2 new fields) and saved them in new MP (unsealed).

    2. Created new Incident template and prepopulated some of the fields with default values (saved in the new MP).

    3. Created Request Offering using this new template and on "Map Prompts" page I can see the default values. Published.

    4. Create and assign it to Service offering. Published.

    The problem is when I open the Request Offering in the SCSM Portal, the default values are not populated...

    I've tried to create request/service offering even with the "Default incident template" (without modifying it), but the situation is the same...

    The Infrastructure is:

    First server :

    SCSM 2016 RU3 + SCSM 2016 Portal

    Second Server:

    SCSM 2016 RU3 DW

    Third Server:

    SQL Server 2014 SP 2

    I'm new to SCSM and maybe the problem is in me and I'm missing something.

    If you have some ideas with this, please share :)

    Thanks !

    Georgi

    Tuesday, September 5, 2017 7:16 AM

Answers

  • Hi

    To be honest I am not sure what the expected behavior is, it was just the behavior I was getting in the quick test I did. And it is easy to see why it is confusing - I got different results from the fields being optional and required and neither matched what was displayed in the Request Offering wizard.

    Regards

    Glen


    Web: www.xapity.com  |   Twitter: @xapityapps  |   Facebook: xapityapps

    • Marked as answer by Georgi_M Thursday, September 7, 2017 11:54 AM
    Thursday, September 7, 2017 11:04 AM

All replies

  • Hi

    The first concern I have is the management pack used to extend the class and form is unsealed. A sealed Management Pack can be referenced by other management packs and so when making extensions like this, they need to be stored in a sealed management pack.

    I would then create a new management pack (unsealed) to store the template. Unsealed management can be updated ie in this case add new templates or modify the existing ones.

    I would then create another management pack (unsealed) to store the request offering. But this is a preference and depends on how you want to organize and group the configuration\customization's in Service Manager.  

    This is where I would start. These guides that I wrote might help:

    Regards

    Glen


    Web: www.xapity.com  |   Twitter: @xapityapps  |   Facebook: xapityapps

    Tuesday, September 5, 2017 8:34 PM
  • Hi Glen,

    I was thinking like you, that there is some problem with this new MP, so I've deleted it(MP) together with all customization. Now there aren't other MP except the original ones.

    Deleted all Service/Request offerings and created new using the default Incident template with 2 field for Urgency and Impact, to check if the Default values are working.

    But unfortunately  the situation is the same. I was expecting "Medium" as value, and get "Low" on both.

    Do you have any other idea?

    Regards,

    Georgi

    Thursday, September 7, 2017 7:18 AM
  • Hi

    As you have gone back to a out of the box basic step up, it does seem likely that you are missing a step in the process. 

    I am not sure what is happening exactly, but hopefully I can explain what should be happening and it might help you work out what the problem is.

    It sounds like you have an incident template with some values filled in - Impact and Urgency.

    Usually, any values I set in the template I do not expose to the Portal. These are not default values that can then be overridden by the user. Instead they are values I want on the Incident\Service Request regardless of what the user fills in on the portal. A good example is: Source = Portal. I do not want this changed by the user.

    For Impact and Urgency I would not configure these on the template, but make them required prompts on the Request Offering. I would also make these a type "MP Enumeration List" on the User Prompts section and then on the Configure Prompts section choose the corresponding Impact and Urgency List that is used by Incident (both come from System Work Item Library). Then the user gets the same list that is used in the console. 

    But if you did put them on the portal, the default value should be picked up off the Template that was selected and it should be shown in the wizard when you are configuring the Request Offering. However, my quick testing showed that the Portal did honor what the wizard was displaying as the default value and just left them blank when they were optional and low when they were required.

    Regards

    Glen


    Web: www.xapity.com  |   Twitter: @xapityapps  |   Facebook: xapityapps

    Thursday, September 7, 2017 8:59 AM
  • Hi,

    First thank you for help !

    According to your last sentence : Did you select "Low" in your template, if not, then SCSM Portal didn't care about the values in the template and displays the first one in the List (urgency/impact), which is "Low", and just cares about the values (as you said) which are not shown and are predefined in the Template.

    If that's the case, then I was looking functionality which didn't exists and everything is as expected :)

    EDIT:

    But for what is then the option "Display only" ? Shouldn't it be for displaying the Default Value..?

    Regards,

    Georgi


    • Edited by Georgi_M Thursday, September 7, 2017 11:07 AM
    Thursday, September 7, 2017 10:59 AM
  • Hi

    To be honest I am not sure what the expected behavior is, it was just the behavior I was getting in the quick test I did. And it is easy to see why it is confusing - I got different results from the fields being optional and required and neither matched what was displayed in the Request Offering wizard.

    Regards

    Glen


    Web: www.xapity.com  |   Twitter: @xapityapps  |   Facebook: xapityapps

    • Marked as answer by Georgi_M Thursday, September 7, 2017 11:54 AM
    Thursday, September 7, 2017 11:04 AM