CA Service Management

  • 1.  Restrict Request Status Options Based on Request Area

    Posted Jul 26, 2016 02:58 PM

    I have a scenario where I need to filter the Request Status dropdown list based on the Group or Request Area for the Request being viewed/edited.

     

    Is @root always the user, or is it sometimes a different object?

     

    Are there ways to use the @ sign to target other objects such as the call_req object in this case?

     

    Thanks,

    Mike



  • 2.  Re: Restrict Request Status Options Based on Request Area
    Best Answer

    Posted Jul 26, 2016 03:22 PM

    Hi Michael,  Currently there is no functionality available out of the box to restrict the status dropdown values based on the group or request area.  This would require a customization and some spelcode that is outside the scope of support, however some folks out there may have accomplished this and may be willing to share their info with you.  You can also post this as an "idea" here on the communities, where folks can vote for it, and product management will review it for consideration in future versions of the product.  Also to answer your question regarding @Root - Yes, that is a global attribute in SDM that always represents the "logged in user" - that does not change.

    Hope this helps,
    Jon I.



  • 3.  Re: Restrict Request Status Options Based on Request Area

    Posted Jul 26, 2016 03:34 PM

    Thanks for your quick reply.  What exactly is spelcode?  Where can I learn more about it?

     

    Let me also re-ask, are there ways to use the @ sign to target other objects such as the call_req object in this case?



  • 4.  Re: Restrict Request Status Options Based on Request Area

    Posted Jul 26, 2016 05:25 PM

    Hi Michael,

    The @ sign is really only used for @rootid, those are object aliases for objects referenced within other objects in context of the current time - meaning for example the logged in user - who is logged in doing this operation right now... @root.    I dont believe you can add additional ones.    Spelcode are the methods by which service desk performs its functions (by definition).  We do not support custom spelcode, but many customers do create their own. Its a proprietary language owned by CA, and solely used in CA Service Desk.    There is limited information about it directly from CA as we do not have any documentation on using it.  However, there are some folks here in the community that have shared their own documentation - you can take a look at this post: Where can I find Spel functions documentation?  This post provides some great insight into what Spelcode is, how its used and what the capabilities are.

    Please keep in mind that when you customize spelcode, CA Support cannot assist you in any way in creation of it, or troubleshooting any problems that occur due to using custom code. Additionally, you would be responsible to maintain that code through patches, upgrades etc.

    Now for your original request, I would definitely recommend posting it as an "idea" here on the community.  I think quite a few people would vote for it

    Thanks,

    Jon I.



  • 5.  Re: Restrict Request Status Options Based on Request Area

    Posted Jul 26, 2016 10:06 PM

    I agree, this would be a good candidate for an Idea.  I'd vote for it!

     

    Until an out-of-the-box solution comes along I can see the following possible approaches:

     

    1. Implement a classic workflow for each request category (assuming you're up to release 14.x) and have the workflow update the request status.  You can then apply a data partition to your analysts that would only allow 'Open' and (perhaps) 'Cancelled'.  That may be too far to leap at the moment, as it would require your request fulfilment analysts to update workflow tasks rather than updating the status of the ticket to record progress.
    2. Create a new status 'factory' for each request category for which you want to restrict the status codes.  If you look at the innards of the 'request_status_change' form, you will see that it has code to use the factory 'crs_in' as the source of status codes for an Incident, 'crs_pr' for a Problem, and 'crs_cr' for a Request.  It is not a big stretch to modify that to (say) use factory 'crs_cr' for Request status unless the category is 'xyz', in which case use factory 'zcrs_cr_xyz'.  You will find the definitions of the the factories in bopcfg\majic\cm.maj (in recent releases) and you would define a variant of one of them in a '.maj' file in your site/mods/majic folder.  You can use the WHERE clause in your factory to select just the codes that are relevant to category 'xyz'.  This is relatively easy to implement, but the downside is that your status selections are hard-coded into the factory definition and any time you wish to change them you will need to edit the factory definition and restart the SDM service.
    3. A more generalised solution would be to define a new LREL linking request category and request status and then define your site's variant of the 'crs_cr' factory to look up the codes from the LREL.  That is a far more significant undertaking but would potentially allow you to maintain the selections on demand without requiring downtime.  This is likely to be how such a change would be implemented if your idea was adopted into the base product and it would require a significant effort to achieve, especially if you're not already some way up the learning curve in terms of implementing Service Desk mods.

     

    Hope that gives you some ideas!

    Regards,

    James



  • 6.  Re: Restrict Request Status Options Based on Request Area

    Posted Jul 27, 2016 08:01 AM

    Thanks James - I agree with you, I would vote for the idea myself as well if Michael creates it     Your alternative suggestions are ok as well, although they do require customizations, which I explained to Michael can be a risk if you are not familiar with how to maintain those through patching and upgrades.



  • 7.  Re: Restrict Request Status Options Based on Request Area

    Posted Jul 27, 2016 09:25 AM

    Sounds good.  How do I post an idea?



  • 8.  Re: Restrict Request Status Options Based on Request Area

     
    Posted Jul 27, 2016 12:10 PM

    Actions -> Create an Idea



  • 9.  Re: Restrict Request Status Options Based on Request Area

    Posted Jul 27, 2016 09:27 AM

    camja06, thanks for those great suggestions.  I think I like number 3 the most.  I'll try it out and let you know how it goes.  Thanks again!



  • 10.  Re: Restrict Request Status Options Based on Request Area

    Posted Jul 27, 2016 01:34 PM

    Here's  a link to my newly created idea.  Add other objects like @root to data partition constraints