Jump to content


Hornbill Developer
  • Content Count

  • Joined

  • Last visited

  • Days Won


Chaz last won the day on August 17 2018

Chaz had the most liked content!

Community Reputation

60 Excellent

About Chaz

  • Rank
    Hornbill developer

Profile Information

  • Gender

Contact Methods

  • Website URL

Recent Profile Visitors

1,422 profile views
  1. Hi @Gary@ADL just to confirm, are you talking about Catalog Items or Services themselves? In any case, I've tried replicating the issue you're having by setting the Service's portal visibility off and then trying the different visibility levels against a Catalog Item and can see it's working as I expected it to. If you could post a screenshot of your configuration and we can look into it some more to see what's going wrong.
  2. Managed to resolve this after reaching out to Dan, we'll have something ready early next week in the App Store as a permanent fix.
  3. @Dan Munns the scenario we found and deployed a fix for was this: Multiple teams support a Service and are included as subscribers to the catalog When configuring the catalog's visibility, exclude the first team in the list from being able to see it (any others wouldn't be considered because the first already granted visibility) Is you configuration different from this? As you have a success plan, it may be worth raising a support request for this issue.
  4. @Dan Munns carried on testing and found that some combinations cause this to happen. We're looking into it now.
  5. Hi @Dan Munns, just had a look at it using the current build and it appears to be working as designed. If you a user is explicitly assigned to the Service and then excluded from the CI then that trumps all other configuration for that user, but this is by design. Have you enabled the new setting com.hornbill.servicemanager.services.subscriptions.allowSubgroupsInclusion which takes it further by including hierarchy in it's decision and that could be the reason for the change in behaviour you're seeing?
  6. @Joanne Happy to say that we're currently working on giving each user the choice of what notifications they receive from Service Manager
  7. @Martyn Houghton can see the issue now, will raise it with the right team and get it looked at. Thanks
  8. @Lyonel just to confirm, the user wasn't re-assigned the task and they're not the owner of it? I take it the advanced task completer functionality is turned off on your instance?
  9. @Rohit Govind putting a Request on-hold does exactly what you describe but perhaps you are looking for more context around why it's on-hold? A little while ago we introduced Sub-statuses which are designed to allow you to give more context to the current status of the Request
  10. Worth mentioning that you can only edit posts and comments that have not been replied to and that have not been liked (although the Super User Role and Admin Role roles trump this restriction).
  11. @Dan Munns just to rule one more thing out, are these regular 'human tasks' or are they authorisations? Authorisations cannot be completed on behalf of someone else, they would need to be re-assigned first.
  12. @Dan Munns I've been through a few scenarios but could only replicate by removing the 'Advanced Request Task Completer' right. The right is automatically given to anyone with a full access role (Change Management Full Access for example) or you can create your own role and then selectively give it out. If that's all in place, I see you have a success plan and this requires more investigation so it would be worth raising a support request with us.
  13. @Dan Munns just wanted to confirm if they can see the complete button but it doesn't work or they are never given the opportunity to complete the task?
  14. Hey all, The latest build of Hornbill Service Manager (1466) has been released to live. Change Log for this release are as follows: Fix An issue with pagination in Linked Requests section
  • Create New...