Jump to content

David Hall

Hornbill Developer
  • Content Count

    531
  • Joined

  • Last visited

  • Days Won

    17

Everything posted by David Hall

  1. Hi Derek, When you view the details of one of the requests, is it showing the correct BPM process stages etc in the heads up display at the top of the request details view? If not then I would just double check the following: - Within the service view for the service being used against the request, check that you have the correct workflow selected for Incidents and Service Requests - Within the admin tool, confirm that the workflow set against the service is active If this all looks correct then let me know and I will see if we can find any identify any errors from log
  2. Hi @gingib, This issue was identified last week and a fix was included in the 2.35.5 update of SM. It looks like you are currently on release 2.35.4 so if you update your version of Service Manager it should resolve this issue. Kind Regards, Dave.
  3. Hi Kelvin, It looks like it should be working to me, I've tested those locally and for me they work as expected. Normally you would only see the placeholders when the values are not available at the point of the email being sent, when you look at the request details for the request above are the summary and description displayed correctly within the details section? Regards, Dave.
  4. Hi Samuel, Thanks for checking the setting, we have logged a problem to investigate if there are issues with that setting. As for the SQL update you are suggesting, I'm afraid I personally have no access to your instance data so I couldn't advise whether the selection was accurate or not. In general all updates should be made via the API calls to maintain data integrity to avoid missing any possible related data so I would not want to recommend a manual SQL update. I appreciate that you may have a large volume of tasks to cancel, if I can find a better way to do that I will pos
  5. Hi Samuel, With regards to the tasks not being cancelled when cancelling a request, there is a Service Manager application setting that enables or disables the cancelling of related tasks which is: webapp.view.ITSM.serviceDesk.requests.cancel.cancelRelatedActivities So you may want to check as it could be as simple as not having this option turned on. As for cancelling the existing tasks, yes the h_state field in h_sys_tasks relates to the task status and for cancelled status this value should be set 10. Hope that helps, Kind Regards, Dave.
  6. Hi Tina, I have just tried this again myself and it seems to be working correctly. Can you confirm if you are testing with an email entry that has been sent from the request today after you have applied the latest update? Because the issue was related to the email not being linked with the Request at the time it was sent, it has not been possible to retrospectively fix existing email entries which were missing the link, however any sent following the update today should be working and provide the "View Email" option from the ."More Actions" menu. Kind Regards, Dave
  7. Hi Melissa, Thanks for the post, I can confirm that it is not currently possible to edit the responses to questions that have been added against a request as these would normally be responses from customers that would be unlikely to change. Perhaps if you could give an example of when you need to edit such responses we can look to see if there is another way to currently handle it, or put editing questions forward for consideration as a future change. Kind regards, Dave.
  8. Hi Martyn, We have identified the problem and we have made appropriate changes to the pause button visibility checks, this will be resolved in our next update. Kind Regards, Dave.
  9. Hi Martyn, Thanks for the post, I've raised this issue for the development team to investigate as PM00143979. Kind Regards, Dave.
  10. Hi Kelvin, As it is just happening from the one machine, as a first step have you tried clearing the browser cache/cookies on that one machine? Kind Regards, Dave.
  11. Thanks for the post. All of the requests, regardless of the class Incident/Problem/Change, use the same auto value counter "itsmRequestsAutoId" to increment, so it would only really be sensible to reset the counter if you were to clear down all requests otherwise you could possibly run into scenarios where requests may fail to log due to it trying to create a duplicate reference. Regards, Dave.
  12. Thanks for the post, would you be able to repost the screenshot as it doesn't appear to have uploaded correctly? Regards, Dave.
  13. Thanks for post Bob320, Currently as you have identified the only way to perform the updates via the flowcode is to get the existing record data and then supply all populated data fields to the update even if you only want to update a single field, this is the way it is currently used within the application where we do supply all of the relevant data fields on updates. I would agree that the flowcode parameter validation does not make much sense when other values do need to be supplied to prevent data loss, therefore I have raised a problem for the development team (REF: PM00142915)
  14. No worries Dan, glad you tracked it down. Dave.
  15. Hi Dan, I don't believe there have been any changes made in this area. Provided you are logging an incident or service request and you have existing templates then they should be made available on the "Request Details" form within the progressive capture. When you manage the templates do you still see all of the templates that you created? Have you made any configuration changes around which progressive capture (PC) process is in use when logging the request? First step would be to check which PC process is in use when logging and check that it is using the "Request Details"
  16. Hi Tina, We have implemented a fix for this issue, it didn't make it into the next update due out but will be available in the following update. Regards, Dave.
  17. Hi Tina, For your future reference this has been raised as reference PM00142808 Regards, Dave.
  18. Hi Tina, Thanks for the post, I'll raise a problem record and will see about correcting it. Regards, Dave.
  19. Hi Chris, Currently there are no notifications based off of the change in priority in the Escalate tab. The escalate tab will allow the changing of the priority on the request and the addition of an entry into the request timeline recording the change so analysts can see this change in the timeline and the updated priority on the request/request list. Kind Regards, Dave.
  20. Hi Gary, I would suggest using the custom "Views" from the request list view. From the top right of the requests list, click "Views -> Add New", give it a name and then specify the customer in the criteria of the view. Full details of how to work with views can be found here https://wiki.hornbill.com/index.php/Request_List_Views Hope that gets you the data you need and it should all then be sortable as needed. Regards, Dave.
  21. Hi Chris, Thanks for the post, as DeadMeatGF mentioned the date shown is essentially the same as saying the date has been reset when it has been taken off hold. A fix (reference PM00141616) has already been applied for the next update which will ensure that this field shows as empty in future. Kind Regards, Dave.
  22. Hi Gwynne, Unfortunately I cannot promise on the exact ETA of the update, however it is well into our internal beta testing process and we are working to make it available asap. Regards, Dave
  23. Hi Gwynne, Apologies for the confusion, the fix that you refer to above unfortunately did not fully work, so although it allowed you could select dates in the past, you could still not apply them due to other checks in the background. I revisited this issue last week and we now have a working fix which will be available in the next update. Kind Regards, Dave.
  24. Hi Ralf, Thanks for the post, as I understand it both on-hold and off-hold should be controlled by the same settings... does your analyst see any errors or are you missing the option to take requests off-hold "play" button from the interface? Regards, Dave.
  25. Hi, Thanks for the post, we recently identified this issue here and a fix has already been added which will be released in the next update. Regards, Dave.
×
×
  • Create New...