Gerry

As n update, the new UI layout will be pushed live for all Hornbill customers on Wednesday 28th July 2021. There are still many improvements in UI/Layout to follow, primarily in the applications that we cannot deploy until the new UI layout is live, you can expect to see many UI tweaks and changes to bring our applications and other functions in-line with this new styling. Next up will be improvements to various screens/views/layouts in Service Manager

@Caroline Et'al I am afraid we have to hold our hands up to this one. As you may be aware from other posts, one of the things we have been doing is spitting the codebase behind the service and customer portals, this will allow us more flexibility in the future to create better and more aligned user interfaces/user experiences for your customers and employees. Also, as part of this change we have removed some legacy technology from under the hood (PHP) as well as modernised the way in which the portal works, also under the hood. To the specific problem, there are two failures we need to hold our hands up to. The first in, the Customer Portal had always had multi-language support, but the legacy code that was previously powering the portal had a defect in it, that was incorrectly not selecting the correct language. When we implemented the code code, we of course made this function actually work, and so for a small number of customers where the supported languages were enabled, but not translated/configured, the effect was any users would now see the supported language their browser was set to by default. Regretfully, we were not actually aware of this problem, and because the code that went out worked as we expected, we were not aware there was going to be a problem, and had no reason to suspect that customer instances portal language translations might not be enabled but not created. The original defect in the old code that masked that problem only came to light as a result of us pushing code the new, now working code. We have provided information on how to resolve the issue and we have also made a change to the portal configuration which in future will allow you to disable multi-language support. The second problem is our release note publishing automation for the Customer Portal was not configured. Previous code versions were directly tied into the instance so any change release notes would have made it into the instance update release notes. Since we split the code in order to give the portal its own life/roadmap we had failed (plain forgot if I am honest) that we also needed to get the release note automated publishing configured/enabled for that project. This has now been corrected also. On both counts I can only apologies for the disruption caused, we are well aware that the optics here would have impacted your end users/customers and is far from ideal. While not making excuses for the breakage I hope the explanation above goes some way towards explaining what went wrong. Thanks Gerry

@nasimg Thanks for the feedback, I can certainly understand what you are saying, if we can add a simple option to send task assignment notifications via email that would at least be a start. Gerry

Hello @RIchard Horton I am afraid its still in the backlog. We are consistently asked for things and do what we can to implement everything, our priorities outside of our strategic endeavours are driven by customer demand, in effect the highest priority changes bubble up to the top and we add them to our work queue. The devil is in the detail here, its what notifications to send and how to give users control over these notifications. Technically the sending of an email is trivial, but giving users appropriate levels of control over these is less straight forward, and its that aspect that prevents it from being a quick addition. This requirement surprisingly does not come up that often, probably because for the most part, Hornbill is a destination application for the Hornbill users, which means they see/get the notifications they need through the system, request, work and tasks lists within. What we have done in the meantime is to implement Desktop notifications, which means you do not need to be "in the application" in order to get notifications relating to task assignments etc... I guess even with this, you still see a need to use email for notifications? What work pattern is this for? is it the case that your users are generally not in Hornbill, but need to know when they have been assigned a task to do so an email is the best way of notifying them? What about task reminders, task reassignments, task completions and other notify-able events relating to tasks? Or is it you would expect a mirror of all notifications in Hornbill that you get sent in your email also? Gerry

@andy densham Further to @TrevorHarriscomments above, this is not something that has ever come up before, it would be interesting to understand more about the use case you have? One of the main issues with harvesting content/attachments from email messages is the unstructured nature of email messages, both format and encoding play a part, each mail system does things differently, the MIME encoding scheme is very flexible and the composition of email messages as a result can look very different depending on where the message was composed, what corporate filters its been through and what the receiving mail system does in terms of processing. As a result its difficult to provide precise ways of automating the extraction of content from email messages You stated "This seems to be a fairly important option that is missing!" can you give me some examples of other systems that would allow you to do this? its it something you were doing prior to using Hornbill? Thanks, Gerry

@samwoo Thats the conversation we had internally also, and using the browsers zoom functionality is the best way to go as you can more finely tune for your own setup/environment. All future UI work will have this consideration and move towards making the UI work well at all reasonable zoom levels. Gerry

@samwoo We had that feedback internally too, and while the font size is one aspect, the other is spacing/padding etc. There is a continued push towards better visual accessibility, and so density of information is important to consider. I know us technical information worker/developer/technician types like high density information on our screens, but we have to find a good balance. I would give it a few days and see how things look to you, and then switch back to the old UI, what I found, despite liking the higher density information myself, I found that when looking at the old UI I am compelled to switch back to the new "bigger point size" UI. Thats been my experience anyway, give it a try yourself and let me know what you think

@Michael Sharp Many of the views, including email need a lot more attention, now that we have the new navigation structure in place as well as a more consistent global design system for the dev teams to work with, we have a program to do many further incremental releases improving UI aspects across the board. We purposefully chose this approach to be aligned with our CD pipeline approach. In summary, there are many areas of the application that are currently *untouched* that will be getting improved over the coming weeks and months. Gerry

@samwoo You beat me to it... Gerry

@Stuart Riddell I can hear your frustration, but I want to try and address each point separately, as they are two different things, otherwise we will get nowhere fast. I don't understand the point about the .NET library, its stable, that does not make it out of date, that just means there is (to the best of my knowledge) nothing else to do with it, thats because the XMLMC API that it serves as a wrapper for is also stable and its self has not changed in many years. So I am not sure I understand this problem, are you saying that the .NET library is not working? or is it feature incomplete? do the other libs do something that the .NET library does not do? That is what I am seeking clarification on, just saying its not been updated since 2016 does not mean its not working? As for the other error you are seeing, as @Ehsan pointed out above, this is a defect and has been resolved and will be rolled out very soon, in fact this really ought to be a hotfix, I am not sure why its not, I will ask. This is entirely our fault and has been prioritised, and I can only apologise for that problem unreservedly. Gerry

@Stuart Riddell Ok its pretty difficult to find a community solution here while just being shouted down - let me address a couple of points. The first one relates to undocumented/unsupported API's, its entirely unreasonable to hold us to account when you / your team have taken it upon yourself to reverse engineer the way the browser talks to our service, made use of undocumented/unofficial API/endpoints and then hold us to account when your code breaks. I am assuming no one from Hornbill had advised you that this was supported, and so am making the assumption that this is how you have come to use the cafs_raw endpoint? The .NET API is a community project posted on our GitHub account in the hope that for anyone who finds it useful can use it. Furthermore it is open-source and we are happy to accept community contribution. If its actually broken, then we are always willing to go and fix it too if/when we can. The nature of the API is such that, while the various API's we add/update over the passage of time, the API lib is just a wrapper around composing and the XML messages, so I am not sure what "6 years out of date" means. I am not a .NET expert so I may be incorrect here, but to the best of my knowledge, the current version of the DotNetApi lib project will work with all version of .NET v4 and above? "as I've just re-confirmed, we cannot even view an attachment whilst raising a request from an email in Hornbill" If this is the case, that would appear to be a defect, I will point the dev team at this point for them to have a look, but if this is urgent and needs priority attention, please log a support request with the support team. https://hornbill.com/support Gerry

@Joshua T M As a general rule we document the API's that are public, but they are very low level and I appreciate that. However, you mentioned "I'd suggest at least communicating these changes made as part of the "under the hood" update, regardless of whether these changes may or may not affect your end users"` As our service continues to evolve we change much under the hood all of the time, if we communicated every change we made it would be mostly meaningless to customers, simply because the changes do not impact things we expect customers to be using. You said that "the documentation has been lacking at best (as you can see from my previous posts to the community) and we have been forced to find "workarounds" in almost every use.", I agree that our API docs could be better, but I would still suggest that any web endpoints that are not documented and/or recommended for use should be avoided, or perhaps better stated, use at your own risk, simply because anything like that has a good chance of getting changed/evolved or otherwise depreciated, as was in the case of the cafs_raw endpoint. If we have sight of what you are trying to do, then we can consider those requirements and offer the best guidance/support possible, and build into our roadmap changes that might better suit/be better supported. Gerry

Hello @Joshua T M Thanks for your post. There are a great deal of "under the hood" changes happening on our platform, and one of the recent changes was the depreciation of the CAFS_RAW endpoint. We did not consider anyone outside of our own internal developers would be using these endpoints because we have never documented them and/or flagged them for public use and so in making these changes gave no consideration to that possibility. Unfortunately this change in API endpoints for storage is both irreversible and is likely to continue to evolve/change over time, so reverse engineering the API calls that are being made from the browser to work out how to get this content, while obviously possible, is not going to be reliable from a business continuity stand-point, my recommendation would be not to do that. So as I may give you guidance, perhaps you can give me some insight as to what you are needing to achieve and I can find a more supportable route for you to achieve what you need.

@Ann Apologies for tagging a developer, I was advised that just responding was not seen by anyone Even just replying is enough for people to get sight of the communication, but developers generally are not on alert watching the forums, they are generally heads down writing code (we hope). We are biog believers in supporting our community, but its not a channel where we provide any SLA or guaranteed response, for this, as @Victorpoints out, if its important and you need an answer in a timely manor, this is why we have the success plans which are our formal, SLA committed support channel. No apologies needed, we are always delighted to help, but I think we are just keen that you understand that the forum channel is important to us, but we do not provide any guarantee of a response time, or even a response. Gerry

@Francis von Stein We would love to help support your Facilities Management function onto Hornbill and could certainly add more supporting Asset Classes to expand the CMDB. However, just adding a generic one is a pretty bad idea as we will forever find it does not "quite fit". As you may know, our CMDB is structured in asses "classes" based on which, you can create multiple asset types of each class. In order to look at this properly it would be helpful to get a complete understanding of the asset classes and types you might need, in order to identify the right structure. Do you have any current database? or spreadsheet of these facilities-type items? Is this something you could share privately, under NDA if needs be? Gerry

Hello Ann, So in that context, who "supplied" the phone, I am assuming there is only one supplier in that example? Gerry

Hello Ann, Thanks for the question, can I understand a little more about the scenario in which is this required. Intuitively, an asset is generally supplied by a supplier, so I am curious to know under what circumstances it makes sense to have more than one supplier linked to an asset. Thanks Gerry

@AlexOnTheHill Yes sorry, that was my fault, I was a bit over-optimising, there are some things in the pipeline ahead of it, its about a week or so out, sorry for the misdirection. Gerry

@AlexOnTheHill One of our devs made a quick change, this will appear in next 72 hours or so. Gerry

@AlexOnTheHill I see, fair point, I will ask and see if we can get that changed, should be easy enough Gerry

@AlexOnTheHill can the users not check the "Don't show me this again" checkbox, so any subsequent time they will not longer see it? Gerry

Hi All, Just to close this out, we have now added DKIM support as discussed above. For each domain you have configured on your instance, you can create an RSA public/private key, which can either be 1024 or 2048 bit key size. Once created and added to your domain in the DNS system, you can verify your public DNS settings. Once verified, then Hornbill will digitally sign your outgoing emails using DKIM. Setting it up is simple, see the screen below. This will be available in the next platform and admin tool updates, probably by the end of this week. Gerry

The original design of the boards application did not include this as a consideration so its note likely the data model would even support this. I presume you are talking about providing access to guests who are logged in for security reasons? When you say "like Trello boards" is this a read-only view, or are you talking about more access than that? Gerry

Hi Nasim, Because of the craziness of 2020 we moved the date and as of yet have not set a hard date. There is still a mix of both being used. What I can say is that future engineering work will be going into the Employe Portal and not the Service Portal, so apart from any security related issues, there will be no further changes. I would suggest its in everyones interest to move over as soon as is practical for them. Ideally decommissioning the service portal should be something we do because no one is using it any more, and not because we have set a hard date and that time is then reached. If you feel you need a hard date to work towards I am sure we will ultimately set one. Gerry

@Michael Sharp Lol :: thanks for posting. Yes, it seems everyone is ok with it now, as I think I said originally, the change was going to facilitate other things in the future, but also allows many login options that were previously... errr... difficult... I assume you have rolled out a combination of direct and SSO logins Gerry