Jump to content

Gerry

Root Admin
  • Content Count

    2,010
  • Joined

  • Last visited

  • Days Won

    79

Gerry last won the day on January 13

Gerry had the most liked content!

Community Reputation

307 Excellent

5 Followers

About Gerry

  • Rank
    Senior Member
  • Birthday 03/19/1966

Profile Information

  • Gender
    Male
  • Location
    UK

Contact Methods

  • Website URL
    http://www.hornbill.com/
  • ICQ
    0

Recent Profile Visitors

3,146 profile views
  1. @lee mcdermott Could you tell us what browser you are using, this could be browser-specific behaviour. Also which side are you talking about, the chat in the portal or at the analyst end? Gerry
  2. @AndyGilly We can provide the IP addresses (I don't have them to hand), but, I would strongly suggest you don't rely on the IP's as they might change over time, instead if your firewall can use domain names then that would be better. You can also rely on authentication to further limit access. If you do use IP addresses, you will need to be aware that we may change these and do not either a) keep a track of customers who maintain firewall rules aginst our IPs or b) notify anyone if we do make IP address changes, we rely on the DNS system to ensure continuity of the Hornbill service. Gerry
  3. Hi @lee mcdermott We are looking into whats wrong, its a little strange and we need to investigate. There were some browser changes a while back where notifications were delayed until you are focused on that browser tab, it might be something to do with that, and possibly browser notification settings. We are looking at it as a priority, but it will probably take us a few days, please bear with us and someone will post back here once we know more. Gerry
  4. @Martyn Houghton Thanks for the clarification, I have had a quick look. With regards to PM00158398 I can only apologise for this, it was simply an oversight on our part. The function this relates to is what we internally call a "plug-in". The Timeline component is developed as part of the collaboration core, and in order to allow applications to extend the core capability, application teams are provided a facility to "plug-in" to the timeline to add application-specific functionality. It would appear from the internal descriptions of the solution, we failed to fully recognise the purpose of the plug-in function, that was simply our error, I do not want to dismiss it because we should not make mistakes like that but it does happen from time-to-time, I will make sure I feed this back to the team(s). I cannot hand on hand say that we will never make a mistake, we will from time to time, we are in the software business and thats the nature of the beast. However, one of the great benefits of automated software updates is, if we do cause a problem, we are empowered to fix and deeply really quickly, which overall should be a far greater benefit to our customers I would hope. With regards to more frequent updates - one of the positive side-effects of automated updates is we can do more frequent updates, little and often is always good in software development, less likely to create significant problems along the way. Now thats not to say that we will be pushing loads of updates, but 2 a week would be typical I would expect. It is also worth noting that sometimes we have what might look like update breaks where you see nothing for a couple of weeks, this is typically aligned to things like security fixes, technical debt or major change where we switch into project-like mode for a short period, each app team is autonomous so it will be different on an app-by-app and platform basis. On your point about O365 clients, yes you are right, for the on-prem deployed clients, they follow a different path. I was referring to 0365 in the cloud/browser, there is no such controls for that Gerry
  5. @Martyn Houghton "Also from a change control point of view, if there are applied on the first opportunity after release, there may not be time for system administrator to review the impact from the release notes and inform the users of any changes and impact. For example the recent UI changes to the timeline." Yes I understand, but what we try our best to do, is to only ever make changes that are incremental, we try to bring our users through the journey with us. We will never change anything so drastically that your users could get confused or lost, we do make subtle changes all the time, this is how we keep things fresh and always modern and up to date. In the case where we make changes that are impactful from a working practice point of view, say we completely redesign the UI, then we provide an option to "switch on the feature" and try it for a while, giving people the opportunity to get comfortable with large changes. If we do make changes that cause issues then we really need to know about them so we can understand what we got wrong, you mentioned "recent UI changes to the timeline", can you provide me some specifics here? as I really need to feed that back to the team(s) that need to know. Basically, we should not be making any changes that cause disruption to your day to day use, we would like to think that as a service provider we largely remove the need for a system administrator to have to review impact of changes altogether, just in the same way as Microsoft has done with 0365 and many other cloud based services do. Gerry
  6. @Adrian Simpkins @Martyn Houghton Hi Guys, thanks for the questions, let me try to answer them as there are a few points I should probably cover. With regards to having a capability of adding some control over the "days of the week", with our current development methodology this is not practical. For the platform, we have adopted a "Continuous Delivery" approach from day one. This means, all customers are always on exactly the same version of the software at all times. Now it is critical (because our development processes make this assumption) that updates are applied incrementally and sequentially. For example, suppose build 10 is out in "live", then we push build 11 to live, we know that within 24 hours all "live" instances will be on build 11, and sometimes we have to gate the next build because there are incremental dependancies, in other words, we cannot push build 12 until we know that build 11 is already on the tarket PODs. If we had a situation where a customer could effectively gate the update by say limiting the update to only Sundays, then just one customer doing that would mean we would now be unable to push build 12 until the next Sunday maintenance window. For this reason, it is simply not possible to provide a means by which you can control the update schedule by days. It is really important to highlight something else. When we first built the Hornbill platform, every instance had its own set of physical processes and run entirely in isolation of every other instance. Over time thought, more and more of that architecture has become multi-tenanted, and while we are not there today, we are moving towards a full micro-services architecture and when we get to that point, processes and systems are shared by multiple customers, and this means that over time, even the maintenanceWindow setting will become obsolete, and will be replaced by the fact that there will be zero service disruption during updates, as many elements of the platform already work like this. In terms of the published updates schedule, not really. On the platform we generally push twice weekly, being Tuesdays and Thursdays, but this is not rigid, we can actually push updates at any time, sometimes we can push every day, it depends on what we need to do. Our release streams contain fixes, changes and new capabilities, and we do our best not to gate anything. Of course, along with this, we also ensure that we do not break any compatibility along the way, so platform updates should be largely invisible to our customers. We have used the same mechanism for automated application updates, and part of this is adopting the same CD development methodology and practices we are already well versed in with the platform. Our overall goal is to ensure our customers have an evergreen and always up to date service, removing the overhead entirely that is normally associated with updates, CAB and change control normally associated with enterprise software. Now before anyone panics, I wanted to ask a question to give this some perspective. Do you use Office 365 in your organisation? If the answer to that is yes (which it is for most everyone now days) - Do you have any option to gate or regulate updates to the O365 service to specific times or days? - Do you get advanced notice and/or release notes of updates that are applied to O365? - Do you take changes to the O365 service into your CAB meetings? - Do you have any idea what version of O365 your organisation is using? What we are aiming for with the Hornbill service is the same thing. Hopefully, while not the answers you are possibly looking for, I hope the explanation makes some sense. Happy to discuss further. Gerry
  7. As I am sure you know, Hornbill platform updates are fully automatic and happen without any human intervention, ensuring you are always on the latest software versions, this is part of our continuous delivery development process and strategy and we have been doing this since 2015 when we introduced the Hornbill platform. However, I am also sure you that you know, while the platform is kept up to date, applications are not, its left up to you as an administrator to do the update by simply pressing the "Update" button in the Hornbill app store. One of most requested platform changes we have had at every Hornbill INSIGHTS meeting is for us to extend the automated updates to applications that are installed on your instance, so I am delighted to be able to tell you that we have now reached the point where we are able to do this and will be turning this on over the next 2-3 weeks. The main sticking point for us this end was building out, and ensuring we had robust automated testing for each application, which we are now satisfied we have achieved. Once we switch over, application updates will be automatically applied to your instance within the maintenance window you have set. You will also receive email notifications advising you of updates to applications when they happen just like you do for platform updates (assuming you have that configured). You will see that the "Update" button will still be present in the Admin tool when there are new updates, so if there is a need to update in an emergency, for example, if we pushed an urgent hot-fix that you need to apply, you could do that immediately without having to wait for the maintenance window. However, when updates are made available, they will be applied automatically at the first opportunity within the maintenance window configured for your instance. This was a much requested change that I know a lot of you have been asking for, expect to see this change in the next 2-3 weeks. Thanks Gerry
  8. @Moe ok thanks for the info, I will ask internally to see what we can do with the import tool Gerry
  9. @Moe Out of curiosity, what was the previous ITSM tool? Gerry
  10. @Moe Ok I understand, so if you import and forget some data, you want to be able to retrospectively update the same imported data with the addtional field(s)? In which case this is something we would need to look at changing, and there is the added complexity of mapping a unique source ID so updates can be synchronised. Thanks for the clarification Gerry
  11. @Adrian Simpkins Would need to understand more about that, in suupport-works I epxect the scanner is simply entering a string into a field when you scan the barcode, if so, then yes, should work just the same in Hornbill. Gerry
  12. @Moe As Alex states, the import currently is only a one-off import. It sounds like what you want is some form of live synchronisation with data in another system? Can you provide more details so we have an idea of what you are trying to achieve, and with what other system(s)? Thanks Gerry
  13. @Cassie Happy new year! You are right, if you need to assign assets to them, they need to be basic users, not external contacts. You have two options. If your sub-users are on an AD domain, you could set up a second SSO profile, when they first log in they would need to select the profile and once they successfully authenticate it would remember that profile. Alternatively, you can add those users as users manually (or import them) and set a password on their Hornbill user account, then they can login using those credentials instead of using SSO. Hope that helps, Gerry
  14. @David Longley "The System" is a very broad scope, there are roles and you might have to create specific roles depending on which application(s) and which elements of the Core (tasks, collaboration, email and so on) the person would need access to - but it is certainly possible. Gerry
  15. @AndyGilly We try not to publish roadmaps but we are pretty proactive in finding good product-market fit. If you are looking for anything specific or have any ideas we are always open to them, please feel free to post. Supplier Manager has a lot of potential, we would love to see more procurement type teams using it, its certainly got potential in that area. Gerry
×
×
  • Create New...