Gerry

As the Hornbill documentation platform continues to evolve, the latest changes bring the Hornbill Docs content, directly into our applications. There are many places in the Hornbill platform and applications where it would be ideal to provide addtional, contextual help/guidance./reference. What started as an ad-hoc exercise to add the odd popup help option in our software for particularly complicated inputs or settings, has evolved now into a unified method of adding in-app help to any part of Hornbill we need to, with a unified and well document approach to content creation, the Hornbill Docs platform has now been extended to allow "embedded" content to be created. This type of content allows for the creation of pages in a HDocBook that do not form part of the browsable/searchable content, but instead is designed to be embedded inside our applications. Unlike before, where the content was embedded in the source code, this content is now being served from our Hornbill Docs system which means... The content can be edited/updated/improved without having to do a software release. The content can be contributed to via GitHub via a well documented external contributor process through GitHub pull requests. In-App help popups provide immediate access to PDF versions of the popup content As our Hornbill Docs system evolves, features such as embedded video content, up/down voting/feedback/discussions added to the Hornbill Docs system will be brought into the application too. See the video below, a picture says 1000 words...

@Martyn Houghton I see this has been an ongoing requirement for a long time, I just wanted to clarify my understanding here. You have suggested that this be implemented "at the rule level" but from an implementation point of view, this is not possible (see below for an expansion on this), because, the email routing rules system is a generic, generalized platform capability that does the rule logic and then invokes an application-specific function, in this case, Service Manager. So to meet this requirement there is really two quite independent things that need to be done 1. The first thing is, that the input params that the Email Routing Rules passes to the application function is a fixed set of email-related fields (to, cc, bcc, subject, etc). In order to allow you to set rule-trigger specific options, it would be ideal if, when creating an AR function in an application, for example, the ones in Service Manager, that the application devs could also present *addtional* input parameter requirements. In the Rule properties, these addtional input parameters could be presented to you such that when configuring the rule, you could provide the required value. One such input field *could* be the visibility of the item in the timeline. So the first thing would be to extend the rules system to allow for these addtional parameters to be defined. There is another requirement we have that would also be met by this addtional params at config time extension, so that discussion was already in play 2. The second thing would be for the Service Manager dev team to extend the AR related request hadlers to present the required addtional params and functionallity - easy enough to do with the rules supporting point 1 above Some design work needs to be done to implement point 1 above, but there is an ongoing discussion around this internally. Once thats done then point 2 would be an easy requirement to meet Gerry

Extending the ExpressLogic processor to include some time-related functions would be relatively trivial to implement and would benefit all areas of the platform/application where we are using ExpressLogic. Adding something to consider a WTC on the other hand would also be possible, but would be much more difficult to do and would have to be done specifically for the inbound mail routing rules. Is an extension of ExpressLogic sufficient?

Yes, already work in progress Gerry

@Estie At some point quite some time ago (more than two years ago) we swapped out the expression processing engine for something much more reliable, the old one was not case sensitive, you are correct, but thats been changed for well over two years, so your expression must have been failing and probably for quite some time Recently we have improved the UI so you can now use intenseness, as you type you will be prompted with options for the available variables. We have also amped up the documentation so you can click the (?) button to get some in-app help, or, you can see these two documents. https://docs.hornbill.com/esp-config/email/using-email-routing-rules https://docs.hornbill.com/esp-fundamentals/reference-guides/express-logic Hopefully these changes and improved documents are worthwhile improvements There is one further thing on its way, which is Email Inbound Delivery Log which, amongst other things will allow you to see which rules were evaluated and which rule (if any) was applied. This will help you better diagnose unexpected triggers, or non-triggers of email routing rules. Watch this space, should be in the next week or so. Gerry

@Berto2002 We found that there was a problem in our API serializer that was not correctly handling empty string values in an array that sits within a choice type. It turned out we did not have a test case for this particular scenario so missed it. This has now been fixed so the XML/JSON structures will no longer be broken. We will do some testing in the UI to make sure this is also consistent, should all be live in the next few days. Gerry

@Ann-MarieHolloway I am not sure the current platform has this capability, it may do, someone who knows the system will most likely provide a much better answer than I. As an alternative thought, we did think about possibly some form of integration with Hornbill such that, when a user of the academy is registered, they are associated with their instance, and, we could on theory make their course completions and learning path(s) visible in their profile on Hornbill, which in turn could make it possible for their manager/others as required to see that information. Does that make sense? Gerry

@Malcolm As @James Ainsworth says above, consider using the LIKE keyword. You can read more about this here: https://docs.hornbill.com/esp-config/email/using-email-routing-rules#rule-expression-syntax As a reminder, a quick search on https://docs.hornbill.com/ for "Email Rules" will instantly find you the above information and quite a lot of other related useful information too - its worth a look. Gerry

@Ann-MarieHolloway FYI: https://community.hornbill.com/forum/161-hornbill-academy/

@Ann-MarieHolloway its a good point, there certainly should be. We will set something up on here. Gerry

@George Warren Configure your reports to run (assuming you are scheduling them), or your users profiles (if they are running them in real-time) to the correct timezone, that includes the adjustments for daylight savings, these should then work as you would expect. Gerry

@samwoo I think thats part of the problem, there are 100 ways to approach it, its a simple requirement on the face of it, but very complicated in practice to find the right approach to implement it. Along similar lines I was thinking, a custom form (so has all the usual form validation bits) with a navigation option that allows you to repeat the form multiple times, once for each row of informaiton of the same shape, that would fit into the way IC works from a user persepctive, but does not really address the main objctive, which is to have/present a full data view. Gerry

@Sam P The general principle I understand and the more scenarios we can support the better for us because the more value our customers get out of Hornbill. However, I do not want to add stuff without having a clear path to something that is generally useful. Trying to cram what is essentially a wide UI element into a narrow spot on the UI would seem like a recipie for a very poor user experience. I understand the point about Excel, its very very easy to enter data into, but its essentially unstrectured and unvalidated data being entered (generally speaking) which is much harder to make use of from a workflow or automation perspective, so there is value in both options. I think what you are saying is, the user may well need to enter multiple rows where they would need to see the whole data set in front of them at one time in order to validate (for themselves) they are submitting the right data? to make sure they have not missed a record etc... hence the tabular layout - is that right? If the tabular layout for data entry/preview is the essence of the requirement, then, thats quite a lot harder to deal with because of the wide date/narrow UI area we present in IC currently, and to work around that we would need to either provide some kind of click to open much wider popup here type function (very unappealing in a portal thats supposed to be easy to use), or we would need to redesign the portal layout completely in order to accommodate such potentially wide data presentations. So I do understand what you and others here are asking for, but its not really clear I we could implement it without significant changes to the current portal, unless we do the popup thing I suggested, thats quite possibly the only way. Make semse? Gerry

@Sam P The difficulty with tabular data in the context of IC is the tabular data has the potential to be very "wide" and as you know in the Employee portal for example, there is very limitied horizontal space in the current UI design. From a user experience that would be displaying a data tabular form, but presenting a horizontal scroll bar, which would be a horrible user experience. The advantage of a form in a collection loop is the fields are vertically placed and you would get one form per row, which means one click per row more than you would get in tabular form. Of course, even in tabular form you need some way for the user to indicate they need to add a new row anyway, so for me, I cannot see the advanatged of a tabular input form in your expample, I am sure a repeating 8-field single form would present a far better user experience for your end users? Being able to see the entered data afterwards is a different matter I guess, that would be neater in a tabular form Gerry

@Sam P Also, in terms of entering data, what would you expect when you are typing for example the Name of Resource, would you expect that to be able to resolve from a known database of names, or are these fields all just free-form text input? Gerry

@Sam P Why does it need to be tabular data format? Can it not be implemented in IC as it stands? is it that you need the user to be able to add more than one row in tabular form before moving forwards? Might an alternative be you present that as a form (so 8 fields representing a row) and as well as a finish button you could have an add another record and it prompts the same form again to get the user input? Or does it have to be tabular form presentation when your end user is entering the data? Gerry

@Alisha There is no reason in principle why this could not be created, but, the devil is in the details here. I can look at that screenshot and deduce certain things, but I would need to understand a lot more about how you might use tihs? for what type of data? how you would expect to configure this? where/how would the resultant data the user enters in be stored? how would you expect to use that stored data? are the rows and columns static (i.e. defined an configurion time) or are they to be pre-populated dynamically from a data source.... etc etc... there are many more questions than answers. So what I would say is, the clearer the requirement/use case is, the more likely we are to consider it for inclusion. Many things are obvious and we get generally figure these things out ourselves, but in this case, there are *a lot* of potential interpretation of whats required. Can you expand on your use case? Gerry

@danb The current implementation of AI Assist does not use your data for the purpose of training any data models. We are using OpenAI behind the scenes to power this feature, and the way it works is takes the specific data you are elaborating on, it does feed that into one of the GenAI models which will apply general knowledge from its prior training to produce a result. The idea of Suggesting a Solution only works when it knows about the thing/problem being referenced. If you ask it to suggest a fix for a broken iPhone screen for example, it should do a pretty ok job at filling in the gaps and providing a sensible answer. If you feed it something that it knows nothing about like your super secret widget, it will have no idea and will either make something up, or tell you it does not understand whats being asked. In terms of what the other two do, in is simply asking the AI NLU processor "Can you Expand on the following.... <your text>?", where as the other one is along the lines of "Can you Expand on and suggest a fix for the following.... <your text>?" We are not sure how useful customers will find this capability, but the market frenzy thats out there demands we look at these kinds of capabilities, of course, we are not wishing to impose the AI nation on our customers and to have a very high level of moral integrity in terms of protecting our customers data, so anything we do add in this regard will be disablable by our customers individually if they want to. So as of today, please use it if you like, the service costs are on us, so enjoy playing and see how useful it is, all feedback always welcome of course, and expect to see more of this sort of thing as we learn more and find more interesting ways to apply the us of Generative AI in our products. Gerry

@Adrian Simpkins The external authorisers functionality is unlikely to be expanded upon much further than it already is, the full user authorisations have many more options to manage groups/teams of people in relation to authorisations, its not really in our commercial interests to change that or over-extend the capability of external authorisations, so any requests for change to the way external authorizations can be used/expanding will go through a lot of scrutiny/consideration. At the extreme, a customer could have 1 service manager users and 1000000 external authorisers, technically that would work and I expect you would agree that the customer would be getting quite extraordinary value for their one Service Manager subscription. Unfortunately we are tied to the named user subscription model with Service Manager because thats the pricing model we defined and in many ways are stuck with. Most other workflow tools seem to model their monetisation around metered consumption, something we are not big fans of, but for full featured, unlimited and highly flexible authorisations that might be something to consider in the future. I am not sure I completely understand what you are asking for, I was really responding to the notion of expanding the fucntionally/capability of external authorisations on the Hornbill platform. In the mean time, here is an explanation of the two authorization types. https://docs.hornbill.com/esp-fundamentals/core-capabilities/workflow-approvals Gerry

@CraigP @samwoo I am afraid I spoke to early, the Hornbill Automation has been added, but not rolled out yet, should be in the next core release, I can only appologise for the misdirection... you will see it in the next week or so. Gerry

@CraigP Thats a fair question. Ok so the basic idea is this. If you are automating your Hornbill instance, you should be using Hornbill Automations. Why? because the security model in Hornbill is designed to ensure that you can do things, and more importantly can not inadvertently allow things to happen, in the case for example, where a user runs an AutoTask and has the right to run that, but one of the actions in the autotask is invoking something they do not have the privs to run. When you run a Hornbill Automation its using the users security context. iBridge on the other hand is primarily intended for automating cloud systems that are external to your instance, these automations can include the automation of other Hornbill instances. In the above case, the iBridge is being used to automate (or if you like, call back into) your own instance. To make that work is more complicated for you because you have to create an API key, create a KeySafe entry, then set up the integration. Also, the design of iBridge was never really intended for self-integration, although it does work, we have no easy way of detecting/preventing rogue execution loops because the instance will see the iBridge API call as just another API call, there is nothing to make it aware that this is effectively an internal call. In the future we may disable self-calling via iBridge for this reason. That is not actually on the cards now though because we have not run into a real-world production problem, but in theory at least that could happen one day The tihng that spawned this thread was exactly this situation. There is no intention/consideration given to the iBridge calling back into its own originating instance, and when we applied some security hardening we did not gave hany test cases for this scenario, the net result, we put the software update out, and a couple of customers things broke, because they happened to be using the self-calling via iBridge which was being blocked by the security change. So as a general rule, if we do not recommend something, or even recommend against it, then its generally because we think that future software changes may be impactful in the future. Hope that helps answer your question Gerry

@samwoo Thanks, the error above is due to some recent security hardening we did, which inadvertantly impacted this area because of the way our private netowkrs work. We will be resolving this, but, I would suggest, can you ask your user to use the Hornbill Automation for this instead of iBridge, that will be much better in the long run. Gerry

@samwoo Thanks for the suggestions/questions. Its incredibly important to foster as much customer engagement as possible when it comes to documentation, I would love it if customers had everything they needed to hand, and our support team only ever answered questions with links to the documentation pipe dream I know, but reach for the stars and all that... Discussions : this is on the list of things to consider. Thus far the system does not use a database, content is built from Github repo's and published. In order to implement discussions we would either need to integrate something like Disqus or we need to roll our own. One of the things for consideration is to enable comments powered by Hornbill collaboration/workspaces, as we use these internally already so its a ready-made back end. Basically, either a workspace or seeded post per document. where a discussion. There are various issues around moderation and of course keeping track of issues that need to be addressed, so there is some work to do here, but yes thats most definitely on the cards. Reporting Issues: As above, it would be nice if the above mechanism could be used, basically raising an issue would post into a workspace where we can manage it. So I want to say on the cards also. ChangeLog: Not that we have a plan, but this has most definitely been in our thoughts, you will note that every document is versioned (bottom of the page) and, internally at least we have an identity system so we know who (internally) is reading what documents, so we could record that in a database, if we can extend the identity system to our community, then the same. Then, because we would know who has seen what version of each document, when a document is published and has a new version we could work out who we need to notify, and perhaps make that available in a change log, a daily digest email or some other mechanism. The ChageLog could not be based on Git comments, because there a lot of minor tweaks often, spelling, typos and the like, which would drive people crazy, so it would need to be more like our release notes which are declarative and written by the auther each time they change the document. Something we could do, even if we have community contributed content. So yes, this too would be a very nice addition to the docs system for sure. I can't make promises with this stuff at the moment, in many respects, outside of the intial push, the docs system is a bit of a home-grown side project here at Hornbill because its not our main dev activity it only gets the attention it needs ATM. One thing for sure though, is every day the documentation is more and more important and valuable as more and more content is created, so you will for sure see this evolve. Thanks for the suggestions and watch this space. Gerry

@samwoo First off, thanks for the feedback, if you have suggestions or comments, (or even the burning desire to contribute lol) please let us know, its early days so we are cranking out quite a lot of internal and unpublisjed documentation, we are looking to abandon the wiki as soon as we can. The new documentation system is built by us, purpose built for the job and that, coupled with the academy we have also created, are both being invested in so we can get high quality learning and reference content to our customers. Work in progress and pleanty more to come. With regards to the 502 error, we have now resolved that, it was a crashing issue, our systems are robust enough to be laod balanced so while it was not taking the thing down the proxy was seeing unexpectedly dead connections, this has now been resolved. We have also resolved the issue that was not opening the document when you clicked the link, so thats also sorted. @samwoo @Berto2002 If you would be so kind as to conrm its working for you now I would appreciate it: https://docs.hornbill.com/esp-fundamentals/core-capabilities/organization-and-teams Gerry

Thanks guys, it seems we have a problem with one of our docs servers being down and the load balancer not doing its thing. We will sort that, thank you for posting the information. Gerry