Jump to content

Service Form with empty Config Items


DougA

Recommended Posts

We've built up our services and for each request type added the appropriate Config Items. Some of these services might not have any of a particular request type but it still gets displayed.

For instance the Procurement service doesn't have any CIs for the Incident request type.

Capture.PNG.19cbda167d6535749f3262b04bf3bc51.PNG

But it does have CIs for the Service Request.

Capture1.PNG.dffa82738ea9218767d74664996a45f8.PNG

servicemanager.progressiveCapture.servicedetails.catalogRequired and servicemanager.progressiveCapture.servicedetails.enableSupportVisibility have both been set on. For a service request the analyst must select a CI but there's nothing to stop them selecting the Service in Incidents. I've added a test in the PC to see if a CI has been selected or not but I can't see how to force a different selection. If I loop back to the beginning the service form is skipped because it's already been answered which puts the PC in a never ending loop. I've left the Incident configuration settings blank but that just loads the default PC.

Ideally I wouldn't want them to even see the Service if there isn't a CI. At least that way they wouldn't be able to select it! Any suggestions on how to get round this?

Thanks

Doug

 

Link to comment
Share on other sites

Thanks @Victor,

Funny enough that was the solution I came up with! It's a bit crude though and doesn't actually assist in triage.

My Options

  1. Don't have the CI. The Service is displayed and can be selected.
    1. Create a ProCap that somehow loops until a valid selection is made.
  2. Set up a dummy CI. Can't stop someone from selecting it and the service/CI can't subsequently be edited.

Hornbill Options

  1. Do not display Services without CI.
  2. Do not allow selection of Services without CI. servicemanager.progressiveCapture.servicedetails.catalogRequired enforces the selection of a CI if there is one. Perhaps a setting could be provided to block the selection of the service itself?

Thanks

Doug

Link to comment
Share on other sites

On ‎10‎/‎04‎/‎2017 at 10:32 AM, DougA said:

Thanks @Victor,

Funny enough that was the solution I came up with! It's a bit crude though and doesn't actually assist in triage.

My Options

  1. Don't have the CI. The Service is displayed and can be selected.
    1. Create a ProCap that somehow loops until a valid selection is made.
  2. Set up a dummy CI. Can't stop someone from selecting it and the service/CI can't subsequently be edited.

Hornbill Options

  1. Do not display Services without CI.
  2. Do not allow selection of Services without CI. servicemanager.progressiveCapture.servicedetails.catalogRequired enforces the selection of a CI if there is one. Perhaps a setting could be provided to block the selection of the service itself?

Thanks

Doug

@Victor,

Any further thoughts on my issue?

Is there a way to force the user to reselect the service/CI? At the moment it just goes into an infinite loop if I loop back on an invalid service. In the service portal the problem doesn't exist as the user can't select just the service.

Thanks

Doug

Link to comment
Share on other sites

  • 10 months later...
4 minutes ago, Paul Smith said:

have tried exactly the same workarounds and its driving me mad. Theres got to be an easy answer to this hasn't there ?

@Paul Smith unfortunately not... :( You can't loop a PCF and you can't have catalog item required and be able to only select the service...

 

However...

On 06/04/2017 at 2:56 PM, DougA said:

Some of these services might not have any (edit: catalog items) of a particular request type but it still gets displayed.

Looking back at this, it does not seem right... might be a defect here, need to ask our dev team...

 

What exactly are you trying to do?

Link to comment
Share on other sites

Hi @Victor thanks for the reply 

I have a number of services which are accessible by our external customers for the logging of support requests with us. So Software Support requests are logged via a Software Service, Hardware Support via a Hardware service etc. These services are also available to our internal analysis, so should the customer phone us with an emergency situation we can log the request on their behalf. ALL of these customer based support requests are completed using Catalog Items defined under Incident.

For our Software Support Incidents when we investigate we may establish that there is a software bug that we want our development team to fix. To achieve this we raise a Change on the development team. That Change needs to have on it the external customer & organisation so we know who the fix is for BUT it is not customer facing it is purely internal. Currently we just use the Default Change set in the System Settings for both the PC & BPM however by doing so I lose control of the options available ( I don't want the e-mail button available for example ) so it was suggested I create a Service purely for my Change Requests and I can then control what is available.

When I have done that and then go to log a Change, like Doug I see ALL Services associated with the external customer's organisation. With the exception of the Change Service all of the others do NOT have a Change Catalog Item but you can still select the Service and continue on. Ironically you cant select the Change Service you do have to select one of the Catalog items within it. 

For me when you select a Request Type only show the Services that have that Request Type defined. 

I hope this makes sense !

Regards

Pau;

Link to comment
Share on other sites

  • 3 weeks later...

We have a change that has reached our development queue which will allow you to enable/disable the different request types for a Service.   On the Request Configuration tab of a Service each request type will have a simple toggle to disable a particular request type.  When raising a new request, if a user selects a particular request type from the Raise New options, only the services that allow for requests of that type will be displayed.  If the Request Type form in Progressive Capture is used prior to the Service Form, again this will reduce the Services list to only show the services that allow for the selected type of request.  As this is now with development, we should see this provided over the next couple of months.

 

@DougA

On 06/04/2017 at 6:56 AM, DougA said:

Ideally I wouldn't want them to even see the Service if there isn't a CI

I'm also going to look into your original requirement where if you use the setting servicemanager.progressiveCapture.servicedetails.catalogRequired that Services without Request Configuration Items are not displayed.  This makes sense if you are unable to select them anyway.  I just need to be careful that this doesn't impact anyone's way of working  Might also consider a setting on each Service where in the Request Catalog section of the service you could enable/disable this per service.

Regards,

James

Link to comment
Share on other sites

  • 2 weeks later...

Hi @Paul Smith

In most cases once something reaches the development team it only takes a few weeks before it becomes available.  Once it has been completed this post will be updated, so provided you are following this thread, you will be notified.  Also worth keeping an eye open on the release notes.  

You can also follow the announcements to be made aware of the latest updates.

https://community.hornbill.com/forum/135-announcements/

Regards,

James

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...