Jump to content

alextumber

Hornbill Developer
  • Content count

    62
  • Joined

  • Last visited

  • Days Won

    6

alextumber last won the day on July 5

alextumber had the most liked content!

Community Reputation

25 Excellent

About alextumber

  • Rank
    Product Specialist
  • Birthday 11/15/1982

Profile Information

  • Gender
    Male

Recent Profile Visitors

348 profile views
  1. Select Site Progressive Capture

    Hi @Graham1989 The behaviour you are experiencing has already been changed in the next update to default to 'All Sites' when there are no 'Customer Sites' available. In fact the 'Customer Sites' tab will be removed from view as it is not required if the customer does not have any sites. Regards, Alex
  2. Innovation: Insanity and the Fear of Change They say that the definition of insanity is doing the same thing over and over again and expecting different results. If that is indeed the case, you could say that many of the things that we do in our lives are insane. How many people go to work each day in a job that they don't like yet are unwilling to do something about it? The primary reason; fear of change. My name is Alex Tumber, and I'm part of the development team here at Hornbill. I've been in the Service Management industry now for over 10 years, primary as a consultant but more recently as a developer. I joined Hornbill just over 4 years ago, roughly a year before we brought the current Hornbill platform to market with our flagship application; Service Manager. Much has changed in that time, of course it has - or actually has it? Well at Hornbill it most definitely has, but looking at the rest of the industry, has it really changed or have I gone completely insane?! At the recent Service Desk & IT Support show in London (SITS), my task was to man one of the demo pods that we had on our stand to talk to and demonstrate our offering to prospective customers. Normally I don't leave our stand throughout the duration of the 2-day event but this year I decided to have a look around to see what our competitors are doing, more out of curiosity than anything, and I have to say I was pretty shocked to see what was out there... A huge part of what we are doing at Hornbill involves 'innovation' and thinking about things differently to others. Things that are so engrained in our industry and culture for that matter have much less relevance at Hornbill than they might do elsewhere. Email for example - I don't use it at work, certainly not for internal communication anyway. All communication is done through the Hornbill Collaboration Platform. Walking around the exhibition and speaking to other vendors about things like upgrades, patches, versions, even their pricing models to be frank - makes me feel old.  I'm currently in the middle of delivering a new Enterprise Project Management application for the Hornbill platform called “Project Manager” which will be ready by the end of Q3/17. We have started using it internally with great success and are busy adding features based on the feedback that we are getting. Yesterday alone, we pushed out 5 new builds of the Project Manager application. Let's just stop and think about that for a second. 5. New. Builds. So what does that mean? Well, firstly it's the primary reason that inspired me to write this blog, but secondly, for those of you who are not familiar with the Hornbill platform, it means 5 upgrades of your application. WTF I hear you say! An upgrade is a project right? An upgrade means downtime and service disruption for end users. An upgrade means full end to end testing. An upgrade means cost which means less of the IT budget can be spent elsewhere on other important things. Well with other vendors, an upgrade most often means these things but like I say, at Hornbill we like to think differently. Without getting too technical, I'd like to give some insight into the release process for a Hornbill application. It goes something like this:  A developer checks out the source code from the appropriate repository and makes some changes. Any tests that need updating are changed and the developer tests his changes locally. The updated code is then checked back in with a description of the work that has been carried out. Automated tests are run against the source code. I can't possibly explain all the good things that happen here as the list is long enough for its own blog but some key things that happen are: Each API is scenario tested Each input/output param of every API is checked to make sure it has a description The database schema is validated and every column is checked to make sure it has a description All html code is checked by JsLint to make sure it is valid html and that will work across all supported browsers All functions in the JavaScript code are scenario tested All translation strings are checked for a valid structure All application settings are checked for a valid structure If just a single part of one of these automated tests fail, the whole build is considered a failure and does not progress any further. If all automated tests pass, the build can be pushed into the release pipeline, starting with development, then beta, then live. Currently for Project Manager, this whole process takes under 2 minutes. For Service Manager, the process takes around 9 minutes as it is a much bigger application and has many more tests to run and APIs to check. Once the new build appears in the app store it can be updated by an Administrator on your Hornbill instance. At the moment, this is the only manual step that we are very much hoping to do away with in the near future. Clicking the Update button updates the application and in under 30 seconds, the new build is live. None of your currently logged in users need to log out and in again to pick up the changes and there is no downtime. Now that is the way you do an 'Update' – no concept of an UPGRADE here…   Think about problems that you've had with your existing service desk application over the years where you've reported a bug or asked for a small change to an existing feature only to be told it might be in the next version. Ok so when is that? In 6 months maybe? Actually, it's over a year away as we won't do the upgrade until next year now due to budgets anyway. Well that's just great, thanks very much for that. Is this all starting to sound a little too familiar? If it is then I'll tell you why; it's because it's insane. Change can be scary, it really can. Going outside of your comfort zone is daunting for many people however you're never going to progress and improve unless you continue to test yourself and embrace change. That's what we're trying to do every day here at Hornbill. I often think that the world just wasn't ready for what we had to offer only a few short years ago, although I can now honestly say I finally see that people are 'getting it' and that maybe we weren't the ones that were so insane after all!  We're on the start of an amazing journey that's hopefully going to change not just the Service Management industry but the Business Applications industry as a whole which I strongly recommend you join us on. For this developer in particular, it's a true privilege to be part of.
  3. Here is what you can expect from the new Service Details node:
  4. Hi All, An additional output parameter called 'Linked Requests' has been added to the 'Get Request Information' bpm node. This parameter will give you a total count of linked requests to the request your business process is running against. If there are no linked requests, the parameter will return 0 so a value will always be returned. This will be available in our next Service Manager update. Alex
  5. It can be anything you want it to be. I would use one of the get request information options that sit under the Requests entity then make a decision from there. e.g.
  6. Just so I understand correctly, do you need to make the decision in the business process? Something like this maybe:
  7. The 'Project Name' simple list:
  8. Hi, The 2 application settings you mention here are there to act as a default and to save you entering in the information every time in each bpm node each time you want to create a new Jira request. If you leave the input param on the bpm node to 'Auto', it will look for a value in these settings. You can manually specify the Project Name and Issue Type by selecting them from the drop down menu. If you want to add additional options to the drop down menus, you'll need to add them to the relevant simple list(s). Hope this helps, Alex
  9. failed BPM error

    Hi Lee, The most common error here is that the email template that has been defined in the business process node is not a valid email template in the system. Is this possibly the case? Alex
  10. viewing flowcode error messages

    Hi Gary, The way to see the full error is to go to the logs in the admin tool and to filter the server service log by 'error'. Alex
  11. Graph Views

    Hi Sam, Currently it's only possible to share the view and not the graphs. That's not to say that this feature wouldn't expand in the future to allow the sharing of graphs. Alex
  12. Custom Field Variables

    Hi Samantha, try this as an expression for each custom field: Alex
  13. Custom Field Variables

    Hi Samantha, For this scenario you can use an esp condition on the field to only show it if it contains some data. Here is a link to a wiki page that you may find useful. https://wiki.hornbill.com/index.php/Email_Template_Variables Alex
  14. Hi Paul, I have to say I'm slightly confused now as I've got your exact setup working completely as expected on my own Hornbill instance with no issues. Can you try deleting the decision node and recreating the branches to see if that makes a difference? Remember to type out the condition exactly as it's shown 'Coworker' because it's case sensitive. Alex
  15. Hi Paul, Just to confirm, when you are raising requests from the portal, are you raising them from the service portal or the customer portal? https://service.hornbill.com/<instanceName>/ https://customer.hornbill.com/<instanceName>/ Alex
×