David Hall
-
Posts
652 -
Joined
-
Last visited
-
Days Won
34
Content Type
Profiles
Forums
Enhancement Requests
Posts posted by David Hall
-
-
Thanks for the update, having reviewed the code, it should default to the "highest" visibility level permitted on the request for the user, however if no levels are found it will default to "public".
Unfortunately I've not been able to recreate locally to this point, would you be able to post a screenshot/list of the servicemanager roles you have assigned to the colleague that sees this issue, I can then try to match the configuration and investigate further to see if I can pinpoint the issue.
Kind Regards,
Dave
-
Hi @lukeb
When you place the request on hold, are you using the popup form e.g.
If so, the setting highlighted will determine the visibility of the post, it sounds like this may be set to "Owner"?
This can be set as needed by the analyst, but you can set the default value via the following application setting
Kind Regards,
Dave.
-
Apologies missed the notification of your last post.
I've just posted this on another thread with a similar discussion ... if the hold action is being performed via a sub-status change, the process should follow that it will use this value if set, if no value is set here then it should revert back to using the previously mentioned app setting.
In the upcoming update of Service Manager we've made some back end updates to the operation that posts the timeline update, I've just checked it with this scenario and that is working as expected, so if there is still an issue it should be corrected in the next update > build 1805.
Kind Regards,
Dave
-
Just following up on this, if the hold action is being performed via a sub-status change, do you have a visibility leveI set on the individual sub-status as per screenshot?
The process should follow that it will use this value if set, if no value is set here then it should revert back to using the previously mentioned app setting.
In the upcoming update of Service Manager we've made some back end updates to the operation that posts the timeline update, I've just checked it with this scenario and that is working as expected, so if there is still an issue it should be corrected in the next update > build 1805.
Kind Regards,
Dave.
-
Hi @DFarran
Just wondering if you are using sub-statuses here? If so then it could be the new visibility level against the sub-statuses that is giving that setting. If you are using sub-statuses, then if you view the sub-status details you should see an option to change the default value e.g.
Kind Regards,
Dave
-
So any calendar changes will be immediately observed by any existing timers, so if you add in an exclusion day etc then the timers would respect this and wouldn't elapse during this time. What changing the calendar won't do is alter the target times set on a request. Only when setting or changing the SLA will it recalculate the target times based on the current working time calendar configuration.
Cheers,
Dave.
-
1
-
-
Hi @jhiggins
It looks like the ORDER BY clause is incorrectly using the entity name 'Requests' where it should be using the table name 'h_itsm_requests. If this is something you have specified manually then if you update it to read h_itsm_requests.h_resolvedby_username it should run.
Kind Regards,
Dave.
-
Sorry to hear that, we've moved the category to the right panel to make it more visible on the request without scrolling and provided the action tab to set it so that there is no need to edit the form and then have a popup for selection etc. If the changes have made it in any way harder to use then we're happy to take on board feedback for future improvements.
Kind Regards,
Dave
-
So if you were to make changes to the calendar, this would not alter any existing target times etc, however if you were to update the SLA on a request then it would take any changes into account.
Does that answer your question?
Regards,
Dave
-
Hi @John C
In the latest update the category has now been re-positioned to the side bar and there is a new action tab for setting the category as desired.
Kind Regards,
Dave
-
What's New:
- New setting for changing the font of On-hold requests on the request list {CH00157323}
- Allow user with Manage Mailbox rights to see all mailboxes on a Service form {CH00158249}
- As a Service Level Manager I want additional rule criteria for SLAs {CH00146261}
- Create Action Item for setting the category on a request {CH00141466}
- Add visibility of Assets to User Profile {CH00152000}
What's Fixed:
- Routing rule templates not including user details {PM00158720}
- Multiple dollar signs ($) are stripped from when the details are pushed to the timeline of a Request {PM00158408}
- Wiki markup date in the Summary field is not formatted in the Request page title and Requests List {PM00158134}
- Collaboration only users should be able to see the details of a Change they're authorising in the portal regardless of the overall app-setting {PM00158362}
- When viewing a Request that belongs to your staff in the My Services portal, the timeline and post box are sometimes not available {PM00158433}
- Cannot send notifications if a User ID contains a single quote {PM00158790}
- When sending an email through the Business Process, the connections filter is ignored {PM00158798}
- Known Errors cannot be reopened due to checking of a missing app right {PM00158372}
- After posting to the timeline of a Request, another request action's visibility cannot be changed to a higher value than the original posts visibility {PM00157146}
- Request data including summary is not shown in Request list on Service page or mobile requests view {PM00158923}
- When a View is deleted, the entries in shared Views are not removed automatically {PM00158946}
- A chart showing the number of requests grouped by Rating fails to display the rating value {PM00158951}
-
Yes, changes you make to the SLA configuration will only apply to new requests or if you change the SLA on an existing request, otherwise existing SLA timers will remain intact as per the original config.
Kind Regards,
Dave.
-
Hi @davidrb84
We've identified the issue and we'll have a fix in the next service manager update (build > 1781)
Kind Regards,
Dave.
-
Hi @davidrb84
Thanks for the post. I can see the same issue here, I'll raise a problem for the dev team to investigate and address.
Kind Regards,
Dave
-
I've just double checked this out myself and all looks to be working correctly for me on multiple browsers. If you do find a general issue please post back.
Kind Regards,
Dave
-
Hi @Jeremy
Just FYI, an overview of the service levels can be found here https://wiki.hornbill.com/index.php/Service_Level_Agreements
In answer to your question, the SLTs are service based... so on the relevant services for those teams, you can configure the SLA/SL rules to pick a specific SLA/SL based on a combination of request criteria e.g. the team and priority in your case.
If you configure your BPM to start the timers once your team priority have been set, then the rules will process against the criteria and set the SLT accordingly.
Here is a screenshot of a quick mockup, so on SLA details in this example I have created 3 service levels (1,2,3) each of which can have their own response/fix times. I then have multiple rules defined, in this example if 2nd line support and High priority are set on the request it would pick SL 1, if assigned to 3rd Line support and High priority you will get SL 2 etc.Hope that makes sense but please feel free to ask if I still haven't answered your question exactly.
Regards,
Dave.
-
-
1
-
-
Hi @Jeremy
We already have an update with the fix in beta testing which we are about to push live so it should be available for you this afternoon.
Regards,
Dave.
-
2
-
-
Thanks for posting. We're aware and are looking into this and will look to alter it to open the email directly.
Kind Regards,
Dave.
-
2
-
-
As per the screenshot, if you open the service details -> SLAs tab and find the service level that is used on your request you should be able to see which Working Time Calendar is used with it. You will then need to log into the admin portal and the "Working Time Calendar" view where you should be able to find the calendar and the hours it is set to run in.
Just a note of caution this *could* be shared by many services etc so be sure to check before changing it, else you may need to create a new 8:30 - 5 calendar and use that against your service level.
Kind Regards,
Dave
-
1
-
-
If this is exporting from the requests list, then I can confirm that there was an issue recently where some fields were not being correctly exported, these included description and resolution text.
The issue is fixed in the next update (build > 1739) which is due out imminently, so after taking that update you should have the fields available again.Regards,
Dave
-
1
-
-
Yes, in the service level configuration you can add escalation actions to run a set number of minutes/hours/days before a target time. In these escalation actions you can choose to send an email to the owner or to a specific email address which should cater for what you need.
Further details can be found here https://wiki.hornbill.com/index.php/Service_Level_Agreements and https://wiki.hornbill.com/index.php/Service_Levels
Kind Regards,
Dave
-
Hi @nasimg
Thanks for the post, just tried this out and yes there is an issue with the rights checking just on the reopen action on Known Errors.
I'll raise a problem so that we can get this addressed.
Kind Regards,
Dave.
-
Hi @Lauren
There was an update to Hornbill collaboration last night as detailed here with an improved activity stream..
There should also be additional detail in your Hornbill System notifications.
Kind Regards,
Dave.
On Hold Visability
in Service Manager
Posted
Thanks @DFarran that's great.
I'll investigate further and see if I can identify the issue.
Kind Regards,
Dave