Jump to content

Gareth Cantrell

Hornbill Users
  • Posts

    160
  • Joined

  • Last visited

  • Days Won

    1

Posts posted by Gareth Cantrell

  1. We would like to request some finer-grained permissions for the service portfolio.

    Currently, the built-in Services Manager role has the following permissions:

    • View Service Records
    • Create Service Records
    • Edit Service Records
    • Delete Service Records
    • Manage Subscriptions

    There doesn't appear to be any permissions controlling access to the Priority Levels and SLAs.

    This means that even though I have created a "Services User" role, with only the "View Service Records" permission, anyone with only this permission still has access to edit, delete and create both existing priorities and SLAs.

    Additionally, there are no permissions to restrict who can create bulletins or FAQs against a service.

    We would like to give our agents read-only access to the service portfolio so they can see the details and custom fields we carry which hold important contextual information, however, we cannot allow everyone to have free reign to edit, delete and otherwise change the priorities, SLAs, bulletins and FAQs.

    • Like 2
  2. When using the "Copy Request" functionality, request specific fields (such as h_implementation_plan, h_backout_plan, etc on Change Requests) are ignored.

    I looked through all the "app.request.copy.*" settings in service manager, and there are no options to enable the copying of type-specific fields.

    From what I can see this prevents effective copying of request types other than Incident and Service Request.

    Could we please include an option that allows copying of the type-specific fields for Change Requests, Problems and Known Errors?

  3. When creating a custom button using the "Popup" action, any variables added to the URL are not substituted when the button is activated.

    For example, trying to open a Google search on the request summary in a popup results in a search for "[[h_summary]]", rather than the actual summary of the request.

    See below screenshots for examples:

    1) Custom Button definition:

    image.thumb.png.d6e7ae09918ae2684e5b0987e5e87e3a.png

    2) Result of variable substitution:

    image.thumb.png.43e3f6fc2939b6228afa56186e71f10c.png

  4. We have an issue where a request has been placed on hold, waiting for customer.

    If the customer responds via a timeline update, the request correctly comes off hold.

    However, if the customer responds via a comment to an existing timeline update, the request stays on hold and the owner is not notified of any activity.

    How can we ensure to force a request to come off hold in the 2nd scenario (when a comment is added rather than a full timeline update)?

     

    Thanks,
    Gareth

  5. We are busy with the process of importing all our suppliers and contracts into Hornbill, however we have a number of contracts with suppliers that are facilitated by resellers.

    At present, there is no way in Hornbill to show this relationship, however I did see a roadmap item for this that was accepted last year, and we'd like to +1 this for consideration.

    Screenshot2023-07-06at09_43_41.png.aae36f78d750a3a3b6bccd8b164c86ea.png

  6. When changing the service connections for a service via the UI, new records are being created in the database.

    In the below screenshot from "Database Direct", the original records for service id 13 are h_id's: 7, 8 & 9.

    Selecting the "All" button for all permutations in the service has caused additional rows to be created. This has the downside of not allowing connections to see the timeline or comment as expected when we've supposedly allowed collaboration.

    I have had to manually delete records from the database using the "data:deleteRecord" API to get this working as expected, so that the database looks like the 2nd screenshot below.

    {
    	"@service": "data",
    	"@method": "deleteRecord",
    	"params": {
    		"application": "com.hornbill.servicemanager",
    		"table": "h_itsm_service_connections",
    		"keyValue": ["9","597","600","7","595","598","8","596","599"]
    	}
    }

    image.thumb.png.1ecd574c3e1eb003d1245ab19dbca440.png

    Table1: Incorrect

    image.thumb.png.d7d46269308cb68e066a6f05c8aaa219.png

    Table2: Correct - after running "data:deleteRecord" API

  7. I think I found the issue.

    The setting app.itsm.progressiveCapture.newRequestFromEmail had no value, so the default IC "new request" was being used (and by default, I mean the setting: app.itsm.progressiveCapture.newRequest = "new request")

    This then did a switch capture to the "new service request" IC which in turn performed a switch capture to the IC configured to the catalog item.

    The IC for "new request" is "Co-worker search" -> "Request type details" -> "Select service" -> "branch on request type" -> switch capture (to "new service request" in this case)

    The IC for "new service request" is: "Co-worker search" -> "Select service" -> switch capture (to "IT - Service Request")

    The IC for "IT - Service Request" is: "Request details" -> "Attachments"

    I set the app.itsm.progressiveCapture.newRequestFromEmail setting to "new service request", bypassing the generic "new request" IC and now all is working as expected.

  8. @James Ainsworth We've looked at the customer portal.

    Unfortunately, we will not be allowed to present that to any partners as it does not follow our approved guidelines for colour schemes and is not customisable (for example, all the service icons are a blue-ish colour).

    Additionally, all our partners are already part of our core SSO and already imported as basic users (as we could not have gone live without offering them support).

    Aside from that, having the ability to control widget visibility by group would also allow us to selectively show widgets to different groups of employees.

  9. Something we would find very useful is the ability to have subscribers for portal widgets, in much the same way as we have for services.

    We have a number of 3rd parties who work with us and require access to our portal to raise requests and would like to only show specific information to these users.

    For example, we have a links widget which shows links to internal sites which ideally should be hidden from these users.

    We also have some "buttons" in a links widget which allows users to navigate to our Facilities and HR domains and would also like to restrict visibility of these.

    Having the option to subscribe certain groups of users would allow us to effectively hide widgets such as these from users not in the correct Company/Department/Group/etc.

  10. @James Ainsworth thanks for your response.

    We don't have anything specified in that setting.

    What happens is when we click "+ Raise Request", we go through the default IC as mentioned, which asks us for the service and catalog item.

    Even after selecting this correctly (i.e. using exactly the same service & catalog item that is configured in our routing rule template), it is not attaching to the workflow specified in that catalog item.

×
×
  • Create New...