DRiley

Hi Steve, I tried leaving that field blank and the BPM got upset . I'm quite sure there was some built in behaviour, potentially governed by an application setting which cleared the substate on resolution. I was looking for confirmation on whether that was true or not. I can't find a setting myself. Thanks, Dan

Hi Team, I've noticed that if I resolve a request via a business process workflow (using the Update Request > Status operation) the last sub-status is is maintained against the request. I seem to recall there being something that would clear the sub-state on resolution, perhaps an application setting? Does my memory serve me right, or has it never worked like this? The rationale for this behaviour is that many of the active sub-statuses are only relevant when the request is open, but more importantly they reflect a particular state in the life of the request. The sub-status may only make sense when read in the context of "open", but when the request is "resolved" the sub-state quite frequently doesn't hold true and hence should be cleared (especially when it isn't attached to that parent status). Thanks, Dan

Thanks James

+1

Hi Team, the following question has been posed to me from one of the service delivery teams at our organisation, they suggest that when looking to put a ticket on hold, the predetermined time options for selection appear to be "all over the show”. Just going off this screenshot there doesn’t seem to be any kind of consistency, unless we're missing something. So we were wondering what the logic was and how this component determined the time options it presented? Thanks, Dan

Thanks guys, that's what I was looking for!

Hi Team, can you tell me if there's a BPM operation which I can use to either add a user to a Hornbill group or subscribe a user to a service? I'm looking to temporarily give visibility to a user while the ticket is active i.e. add the user as a connection, subscribe them to the service so that they have visibility, then unsubscribe the user at the end of the process. I figure I could achieve the same by adding a user to a subscribed group and then removing them from the group. Are there any operations I can use to achieve this? Thanks, Dan

+1

We were impacted by this update too. One of our teams doesn't use resolution/closure categories either and having a category level set down to the maximum levels in the service configuration provided a solution. Hornbill insist that something has been addressed so that things work "correctly" in relation to this setting. However, if you refresh you browser the mandatory message disappears. That new behaviour Vs a previously logical (and reliable) approach to the situation makes the "fix" hard to stomach. It's as if someone saw the description of the application setting and took offence. One might think it was easier to caveat the description of the setting. The motivation for this "fix" is a little baffling. The lack of an alternative to support the preferences of different business areas on the platform, or any commitment to fill the gap in capability which has been created, adds more frustration to the situation. It's not often I throw my toys out of the pram, but this one has created back-lash for us too.... and on a side note, I'm still waiting for an update on my escalation in relation to this. In my opinion, setting the resolution category before the ticket is resolved is not the right approach. Secondly, what are we meant to set it as, just a generic one? I'll have to review my category-related reports to exclude such a value as its essentially acting as a placeholder for those teams where the category isn't of any use. Dan

Hi team, a question on activities, specifically the situation when one is assigned to both a user and group. I'm looking for clarification around who can reassign, edit details, and delete in this situation. The wiki (Activities - Hornbill) states that "Group & User - if the activity is assigned to both a group and user, then the owner of the activity is able to reassign it". Is this correct? One might think that this situation would result in a combination between group only and user only? I'm not prescribing a solution here, it just seems strange that only the owner can reassign in this situation. Thanks, Dan

Hi @yelyah.nodrog , I hope you're well. I have a report that looks at feedback received maybe this definition will help? You'll ned to tweak the filter and columns included but sounds like it might have the join you need? Dan customer-feedback---feedback-received.report.txt

@Keith Stevenson thanks for clarifying. Is there a wiki page, or other resource, which outlines the features of the enterprise edition? Just so time isn't wasted in future. At times its hard to know what's intentional Vs unintentional in the product. Understanding this area would likely save my time and the time of Hornbill's Support team! Thanks, Dan

I can see it in the search results, but when I click on it I'm taken to the "users" page Thanks, Dan

Hi Team, I believe there's a table which captures an audit of logon/log off actions and I can see from the wiki that there is an interface where this information can be viewed and filtered: Security Audit - Hornbill . However, I can't seem to locate it in Hornbill configuration. Where can I find it or do I need a particular role to access this view? Thanks, Dan

@ssimpson following the Service Manager update, we experience the same situation as you. Within the service configuration there is a category specified down to its maximum level, effectively acting as a default closure category. This approach was taken as the setting of a closure category is not relevant to this particular (non-IT) business function using Hornbill. Having a category set in the service configuration supressed the mandatory closure category prompt. This behaviour seems pretty logical. It appears other Hornbill users have been employing this approach for some time too: https://community.hornbill.com/topic/18412-resolution-category/?do=findComment&comment=88220 What's interesting for us is that if the user refreshes their browser, the mandatory prompt disappears allowing the resolution of the incident in the usual fashion as per before the update. Dan