Jump to content

Steven Cotterell

Hornbill Users
  • Posts

    199
  • Joined

  • Last visited

  • Days Won

    1

Everything posted by Steven Cotterell

  1. Hi @Giuseppe Iannacone, You can find them here... Hope this helps. Steve.
  2. Yes, given the instructions on the WIKI, any account with Microsoft Admin level permissions would work fine, but that massively weakens security. We want to set-up a specific account that can be just used for Hornbill (at the moment to post to a Team Channel) but adhering to a 'least privilege security principle'. We are going to try some stuff today hopefully and will report back. Thanks, Steve.
  3. Hi @Aaron Summers, We're not getting any error as such. It's more about understanding what permissions we need to set-up the 'Service Account' with in Azure so that when the pop-up windows opens and we use the 'Service Account' credentials to log in, it meets the criteria needed for the authorisation. No, at the moment, all we want to do is what I put in the earlier post to you, i.e. This is so we can keep our organisation aware of the progress of CHGs. Thanks, Steve.
  4. Hey @Aaron Summers, Yes, we want one of our BPMs to post to a 'Microsoft Teams' channel at various stages of the BPM. It would post to the Channel :- when a CHG Request is 'Approved and ready to be implemented' when a CHG Request has been started when a CHG Request has completed , and I'm comfortable building the BPM to do this, just having 'an issue' getting the KeySafe entry generated... Any help you can offer would be appreciated. Cheers, Steve.
  5. How I understood this bit to work was wrong. I got someone to create a CHG and the form on the submitted CHG Request does indeed display with the fields I created in the 'blank service' CHG Request'. I expected to see the fields when looking at the 'Change' request configuration section on the Service in the Service Portfolio. Should I see them here??? However, I still have the problem where the fields are not saved in the order that I saved them in. This is slightly better as it means the fields to use are there, they are just in the wrong places on the form. Can anyone help please?? Thanks, Steve.
  6. Thanks @Gerry, I will talk to our guys here and see if we can get the answers. Thanks for jumping on this - much appreciated. Steve.
  7. Hi @Gerry, for situations where two systems need to talk to each other we don't use accounts that actually belong to people, we would create a 'Service Account' for this purpose. We understand this part, just need to know what rights to provision the 'Service Account' with so that when we login to it in the Pop-Up window it has the correct rights to authorise the Hornbill app. Could someone share this with us please? Cheers, Steve.
  8. Thanks @Gerry. Really looking forward to seeing how this develops. Steve.
  9. Hi, Is there anyone from Hornbill please that can shed some light on this for us. It is delaying us from being able to raise Internal Change Requests properly as the Details form does not have the correct fields on it. Many thanks. Steve.
  10. Hi all, We want to be able to post messages to our Microsoft Teams channels from within our BPMs and when setting up the Microsoft Key in the Keysafe, we are running into a 'security issue'. The first part of creating the key goes swimmingly, the issue comes when then clicking on the 'Connect' button. It correctly pops up the Microsoft window prompting for a user to login with. The issue is with the fact that the account that needs to login, needs 'Microsoft Admin level permissions' in order to proceed so that we can review the option we are authorising the Hornbill App to be allowed to perform. We do not feel like we should (nor do we want to) configure the Service Account (using a 'Service Account' as this is better for security) with Microsoft 'Admin' level permissions just to be able to post to a Teams channel. What permissions does the 'Service Account' need to allow this functionality to work, but still following the least privilege security principle? I don't know if this is one for you to answer @Steve G? At Insights19 you seemed to be the man that I'm sure would know the answers when it came to questions on integrations. Cheers Steve.
  11. Hi @Gerry, Please add us to the list - looking forward to seeing where we are going and being part of that journey. Also just a nudge about setting up a forum/gathering for Customer site enhancements. As I mentioned, this is currently our primary use of Hornbill, providing support for our external customers. Thanks again for making us all feel welcome and I really enjoyed my first 'Insights'. Cheers Steve.
  12. Hi there @Victor, It was great to meet up with you and all the others at 'Insights 19'. We discussed this one and it was thought to be a potential 'presentation' hiccup. How do I go about getting this formally followed up please? Cheers Steve.
  13. Hi @James Ainsworth, I have followed the instructions you posted about creating a default 'Details Request' form in a Change Request raised without a 'Service', however I'm running into a few issues. Firstly, the form is not actually saving, in the request, exactly the same as when I hit "Apply Changes" (fields are not staying put in the locations/order where I place them). They initially look fine, but when you go out of the request and then go back into it, they've moved around. Secondly, I'm unable to see this newly created default 'Details Request' form in any of the services in our Portfolio. We did have some services that had a modified default 'Details Request' form, but before I started doing any of this, I reset the forms to the 'original' Default. I have found in the WIKI where is states about how to make a change to the default "Details form' if anyone else wants to read-up on it.... https://wiki.hornbill.com/index.php/Request_Details_Form_Designer This is how it should look... It went back to the Request List, then back into the Request and it looked like this... Is there anyone that can shed any light on what is happening please (or what I'm possibly doing wrong). Thanks Steve.
  14. @James Ainsworth - do you have any update you can feed back to me please re: this issue? Thanks.
  15. Hi, Can someone look into this please and see if I have unearthed a bug... We have a 'Human Task' in our Incident BPM called "Investigation and Resolve". When looking at the timeline in the Incident, the outcome answers are being logged twice in the timeline update. Here is the config behind the outcome called 'Completed' Example of timeline entry When I clicked on the blue 'Investigation and Resolve' link in the timeline entry, this is what I got. Any ideas please folks...??? This is happening every time this outcome is chosen in the "Investigation and Resolve" task/activity. Thanks Steve.
  16. I have found out what is happening. The 'expiry' timer is using the Working Time Calendar called 'ServiceDeskDefaultCalendar' which has operational hours of Mon-Fri 09:00-17:30, with no Holiday Exclusions set ( I believe this to be the default configuration for this Working Time Calendar. I have since found requests that have correctly auto-closed based upon these 'working' times and the Expiry time configured in the 'Wait for Status Change' node in the BPM. We will review all this new information and configure everything accordingly. Thanks @Victor for leading me to the desired avenue of investigation. I hope this post helps people in the future identify why their 2-stage closure isn't working as they expect.
  17. Thanks @James Ainsworth, 20MB would be more preferable please - we quite often have to trawl through logs set at 'debug' level to diagnose issues with our customers environments.
  18. Thanks @James Ainsworth, let me get my head around how you've explained it and in principle that sounds like a great way forward. I've just got to get it straight in my mind the steps needed to do this. If I'm struggling, could I set-up a Zoom meeting with you to talk me through this please? Thanks, Steve. @dwalby, if you manage to do this before I do, or vice-versa, I'd be happy to help you out.
  19. Thanks @Victor, very good point and I will double check this. One of the customers, we support 18hrs every single day, so anything over 7 actual days old should theoretically be closed, but I will double check all this & report back.
  20. @James Ainsworth, thanks, I will take your recommendations on board. The specific logic surrounding this section of the BPM hasn't changed since the very early days, so other updates should not affect this.
  21. Hi, After been running live now for a couple of weeks I have noticed that we have an awful lot of requests still sat in a 'Resolved' state despite them being resolved for more than 5 days. In our BPMs we have the following logic... The logic in the 'Suspend wait for status change node' is as follows... Should I have a 'Get Request Information - Request Details' node between the 'Suspend' node and the 'Decision' node? The logic on the 'north-bound' arm of the 'Decision' node is... The build of this part of the BPM was lifted directly from a sample BPM provided to us by during our 'Switch-On' which looks identical to the logic in the Example BPMs. Is anyone else having problems with their requests not auto closing after the expire period time? Thanks Steve.
  22. Hi @James Ainsworth, It was a dummy, test file, just over 15MB (see below), so did not see this as a problem.
  23. Hi, We have approx 90 services where we need to modify the default 'Change Request' details form, adding new fields, changing field settings and re-ordering the fields on the form. Thankfully, the forms all need to be the same for all the services (i.e each of the 16 fields are the same for each service), so there must be a way that this can be done without having to manually, one by one, edit the forms. Any ideas please? We really don't want to have to edit every single one (which could lead to human error). Thanks in advance. Steve.
  24. Hi @James Ainsworth, or any other Hornbill Support employee... Could anyone shed any light on why we might be having this issue despite changing the setting? Cheers Steve.
×
×
  • Create New...