Jump to content

David Hall

Hornbill Developer
  • Posts

    636
  • Joined

  • Last visited

  • Days Won

    31

Everything posted by David Hall

  1. Hi Keith, The icons should be there, they have been added to show you the service icon, followed by the request type icon and then finally whether it is a running or paused sub-state... however for some reason you are missing the name of the sub-status which should be being shown before the final icon. I'll see if I can replicate the issue locally. Regards, Dave.
  2. Hi @Martyn Houghton I believe I have a fix for this scenario, just doing some testing on it. We already have the next update (2.50) undergoing QA so I will get the fix in for the following update (2.51). Regards, Dave
  3. Hi @Gary@ADL Thanks for the post, could you confirm which routing rule operation you are using to apply the email updates? e.g. in my screenshot I'm using "logOrUpdateIncident". In the latest version of Service Manager (2.49) we made a change to fix the scenario you have raised, however I've just taken a look at the various available operations and I'm guessing that you may be using the "updateRequest" operation which for some reason did not have the same update applied as the other "logOrUpdate" operations. I will make the same change to the "updateRequest" operation which will solve the issue in future, however it may not make it into the next update (2.50) in which case it will be available the following update (2.51) In the short term, if suitable and should you wish to, you could try using the "logOrUpdate" operation which will send the notification with the original email update content before the status update is applied. Any queries just ask. Kind Regards, Dave.
  4. Hi @Martyn Houghton Apologies for the delay in response, was about to post back this afternoon, I have replicated the issue locally and I'm working on a solution right now. When I have it completed I'll let you know. Regards, Dave.
  5. Hi @Martyn Houghton I've just been trying to replicate this scenario.. could you let me know how you have the rules configured at the service level (your first screenshot above)? Regards, Dave.
  6. Thanks for the feedback @Martyn Houghton, I'll try to replicate shortly. Kind Regards, Dave.
  7. Hi @Keith I've just been investigating the last issue you mentioned around the sub-status change text overwriting the email content in the notifications. I've added a fix for this problem so that in future the received email content should be maintained in the notification emails. This fix should be going into a build planned for today, so all being well with testing it should be out to you within the next 2 weeks. Regards, Dave.
  8. Hi @Martyn Houghton As @James Ainsworth mentioned yesterday, we've just completed a small change to provide a new application right under the service level management rights which will also control the ability to update request service levels in addition to the existing role checking, hopefully you can then add this right to your roles as needed. We have managed to get it into the next build planned for today, so as James said if all is well with testing and release it should be with you within the next couple of weeks. Regards, Dave.
  9. Hi @Dan Munns I think I probably tested with the task assigned to a user as well. I've just reviewed the implementation and found that the functionality was initially intended to cover a situation where a task was assigned to a specific user and that user was available to complete the task, in such cases this would allow another member of the team to complete it. The original requirement did not include any concept of allowing users from other teams to be able to close tasks of other teams. I'll mention the product team to get their feedback around raising this as a future change to this functionality. Regards, Dave
  10. Hi @Dan Munns I've just tried this out and it all seems to be working fine, in my case I had just forgotten to turn the setting on. Details of how to get it all working can be found here https://wiki.hornbill.com/index.php/Service_Manager_Experimental_Features#Current_Features If that doesn't work then let us know. Regards, Dave.
  11. @Martyn Houghton I just managed to get this in for the current build, the build is underway so subject to our testing process I would expect it to be out to you in the next 1-2 weeks. Regards, Dave.
  12. Hi @Martyn Houghton No errors in the logs, but I've just been trying again to replicate and I've identified the issue locally, it was an issue with the logic when you are updating from "New" to "Open" status. I've implemented a fix and that should be available in the next service manager update. Regards, Dave.
  13. Thanks @Martyn Houghton I'll have a look to see if there are any errors in the log.
  14. Hi @Martyn Houghton I've tried this out locally and it seems to be updating as expected for me. Do you know if there were any errors in the serverservice log file at the point at which it tried to update the sub-status? Alternatively if you can let me know an example time of when you tried this I can have a look in the log file for you. Regards, Dave.
  15. @Martyn Houghton Thanks for the feedback. I've got a fix for the draft items appearing in the selection lists which I will get into the next build. I can see your point about the duplication in the naming, will need to take a further look and see if we can implement some kind of prefixing as you suggest going forward. Regards, Dave.
  16. Hi @cchalmers, I've spent some more time looking through the log files but I've not been able to find any errors or activity relating to that request coming off-hold, so I cannot track down the specific issue. We have however fixed an issue in the latest build of service manager (980) where requests were not coming off-hold at the appropriate time, so it may be worth updating to the latest update and seeing if this has resolved the issue. If you continue to see this issue with the latest update then let me know and we can investigate further. Regards, Dave.
  17. Hi @Rohit Govind Apologies for this, we have identified an issue and a fix has now been applied to correct this, future timers should now be coming off-hold correctly. Kind Regards, Dave.
  18. Thanks @cchalmers, I'll have a further look into the log files with these dates and times. Regards, Dave.
  19. Hi @nasimg This issue has been fixed in the most recent update of Service Manager (979), so this should be resolved when you next update. Kind Regards, Dave.
  20. @Martyn Houghton Thanks for that, I can see the scenario you are trying to cater for. I have asked the Product Team to comment as soon as they are able. Cheers, Dave.
  21. Hi @Martyn Houghton When the ability to change service levels was implemented, it was done so with the intention that it would be used primarily as a means to correct incorrectly assigned service levels and therefore would be a task for a full access role user (such as a team leader) rather than a standard request user. As a result there are no app rights currently controlling this check, it is purely checking if you have a full access or service desk admin role. I can ask our Product Team to comment to see if we have any plans to make any changes in this area. Cheers, Dave.
  22. Hi @Martyn Houghton To be able to change a service level on a request you either need to have the appropriate "Full Access" role for the request type in question e.g. you need the "Incident Management Full Access" role to change the service level on an Incident, "Problem Management Full Access" role to change the service level on a Problem etc, or you need to have the "Service Desk Admin" role which will allow you to change the service level on any of the request types. Regards, Dave.
  23. Hi @cchalmers Apologies, took me a while to get the log files and run through them in detail. Unfortunately for the reference example you supplied I cannot see any specific errors or reasons why this request would not have come off hold. In the case of this request SR00008389, if you could let me know the date and time from the timeline that it was most recently put on hold I will see if I can find any errors that may have occurred at the time of placing it on hold. Kind Regards, Dave.
  24. Hi @Keith, Just in addition to James' comment around the upcoming increased controls per sub-status, as part of the same enhancements the sub-status will no longer be updated via a customer response unless a sub-status has already been set, so it sounds as if that will cater for the problem you raised? Regards, Dave.
  25. Hi @Awalker thanks for the post. Looking back to when this was originally implemented, we put in place essential data validation to ensure that uploaded data was suitable for use and would prevent errors when viewed within Hornbill. We then added some additional validation e.g. for "Computer System" where we added fields that we believed may be used for uniqueness, however the list was not meant to be exhaustive as everyone has different requirements so we left it open for feedback. If you have any examples of fields you may wish to validate on then please feed them back and they can be considered for future changes. I note that you referred to future uploads, so though it probably best to reiterate that this asset upload facility was designed to be used just for a straightforward initial importing of data where the data is mostly static, so the hope would be that your source data would not contain duplicates when initially uploaded. We have an additional import utility which is detailed here https://wiki.hornbill.com/index.php/Database_Asset_Import which can be used if you wish to perform updates or more complex imports. Regards, Dave.
×
×
  • Create New...