Gerry

@samwoo Appreciate that can be frustrating, I would strongly reccommend that if you are doing long Workflow editing sessions, that you enable this option..... Gerry

@Martyn Houghton Thanks for the clarification. So by the sounds of it a Requests::lookupRequestIdByExternalId() API would get you what you need? It would look for the request where "h_external_ref_number" matches the external reference, and would return the Request ID? Gerry

@Jim @yelyah.nodrog I just wanted to make a comment here. Any database table with the h_sys_* prefix is subject to change at any time. That means you cannot rely on any report you run against those tables to work moving forwards. I appreciate as of today the Hornbill platform through system reporting capabilities allows you to peer into pretty much any part of the database, so you are of course free to do this, its your instance and your data. However, should these tables change as things evolve, and should the platform change in the future to better secure the system for multi-tenant use, you may will find this sort of report will no longer work. With that in mind then, the better question for use to ask is, what are you trying to get/filter by, perhaps if we understand the requirement, we would stand a chance of providing you that facility instead, which would be more convenient for you, and far more supportable by us? Gerry

@Martyn Houghton Can I ask, what API's are you currently using to achieve that? The requirement is perfectly reasonable, however, for us to implement that in a way that is supportable that would require some speciific behaviour. For example, many of our customers now have +millions of request records, so, if your external reference number was just stored into a custom field, where there is no index, then it would be a very poor performing API call as it would have to do a full table scan to find a record. So if this is a requirement we should provide you with the ability to do this via an API, but, in this case, we would probably want to be adding a dedicated field (if one does not already exist) and ensure that its correctly indexed in order to support such an API. This is really the point. The general query API's will let you do pretty much anything, but given our database schema, and general query APIs (like the search API) will and need to change as we improve things, we cannot be continuously locked into API's of the day, as we have been when exposing these. I would be interested to know which API's you are currently using to achieve this. It certainly sounds like something we should be able to correctly accommodate for. Gerry

@Adrian Simpkins Cal I clarify, when you say connection node, do you mean the Service Manager action to add a connection to a request? Gerry

@Berto2002 We generally do not stop for Christmas in terms of ongoing software development/changes/pushes. In practice things do get naturally quieter but we have no official freeze window. Gerry

Just on the point @Steve Giller mentioned, PHP has not been used in our code base for more than 8 years. Our API's are pretty generic though, so they certainly usable from PHP if requiired. Because our API stack is focused on JSON now, especially for customer-facing API's there is no longer any need for us to provide platform-specific API libraries, just use the standerd RPC/REST style API's, they are simple and easy to use from pretty much every language that works with modern web stuff. Our docs to contain examples in numerous languages. Gerry

@samwoo Good question Sam. The basic answer is no, one does not automatically get you the other, but, if the function is present and working as required, for example, lets say there is an automation presented in the BPM for performing an action, and there is a reason why that would be a good idea to also have that as an API then that may make it easier to implement, especially if the logic behind the function is complex. However, generally speaking, the request for an addtional function in the BPM and an addtional API are really treated as two seperate requirements, in both bases we are asking why its needed, how relevant is it in that domain (BPM, API etc...) and all that stuff. Historically we have been very bad at just adding stuff, even if it only aids one customer, and in many cases now, as the systems scale and size has grown this approach has come back to bite us because we needed to change things that were incompatible, or we had forgotten about that variation, or many complaints of how complicated the system is, too many API's, too many options, not enough documentation, examples, guidance etc... All fair criticisms and something we are very keen to do something about. The changes to the API's, documentation, getting the Academy up and running and many other initiatives are all components of allowing our platform to continue to gorw, while at the same time making things simpler, more consumable, better documented etc... So when we look at requirements from customers, from the sales field and in the compatative landscape we have a much more inquisative mind being applied to thore requests. Just knowing what someone would like is no longer enough to get stuff added to the product, we need to understand not only what, but why its needed, how does it fit into the bigger picture, and we need to consider if there are better/alternative ways to achieve the same thing.... etc... Hopefully that sheds a little light and answers your question. Gerry

@samwoo it would certainly be helpful for us to understand generally what customers are using the API's for, so yes, please ask. We are keen to understand not only what API's you use but what you use them for, that might give us better insights into how we might better produce useful customer-facing API's Gerry

@samwoo You can just use these forums. Just put into the right forum so right dev team get it. For the most part you are either going to be requesting a platform or Service Manager API. For the shared user example above that will be a Service Manager feature request. You can generally determine that based on what Doc you would expect the API to be documented in. For now, all old API's will continue to work, the caviat here is, at some point they will stop working because of the API infrastrcuture changes we are making. At some point in the future the API endpoints will also be changing - we will communicate this early with plenty of notice so no need to worry about it now. In essence the current endpoints will be used excluseivly for our front-end applications. There will be a newly created API endpoint which is dedicated for customer consumption, when this happens, two major changes will kick in. * Only the API's documented on docs.hornbill.com will be accessible on that new endpoint * The existing endpoint will no longer work with API keys, only interactive sessions will work, and the only way to create an interactive session will be from our apps, and not accessible by API users * The new API endpoint will only work with API keys. * The old API documentation is going to be taken out of service/will no longer be available (thats happening quite soon) There is still some months to go here, so if you are using some of the old API's they will contine to operate, but, they may change or disappear without any prior notice as this development effort continues. Gerry

@Osman I got what you are asking for. The problem is, we are having to cater for a large number of scenarios, there are various ways of logging into the system, SSO is one, SSO with more than on iDP is another, there is passport, direct login, support passcode login etc. We do not detect if there is already a login, thats not possible because the cookie(s) that exist are rotted to a different domain. In order to just pass thourgh, what we have to do is intiate the SSO cycle, which involves redirecting to the IDP and the IDP then redirects the browser back to our server. Catching all the variations of things that can go wrong here is complicated. When implementing these sorts of things we have to do things that work for everyone, and so the design decision was taking to first have a landing page, so we have a way of presenting the choices needed. I acknowledge its technically possible to just do SSO directly, but because our login/landing page for logging into Hornbill has to cater for both users of the system as well as basic users (your end users) of the system, when we have now works for all cases. The special URL suggestion "may" be possible, but, then we would place certain handcuffs on ourselves for features we may want to add in the future, so at this time, this is not something we will be adding to the product. Gerry

No problem all, our apologies for that, I am not exactly sure what caused the problem, I expect we missed in testing. Please do keep in mind though that this API is not currently flagged as a customer-facing API and from the looks of the API signature the API does not meet our own guidelines to meet the requirements of being a customer-facing API becuase there are undocumented JSON strings/structures emitted from this API, these JSON structures are generally not ridgid and are subject to change at any time, which means this API can also change at any time. Gerry

@ChrisDee I believe this should already been fixed, I am sure I seen a hotfix go out for this. Is it still not working for you? Gerry

@Osman Ahh sorry, I had misread your original post. You are asking if you can simply bypass the login page all together. This was discussed extensively on the forums when this was first implemented, the short answer is no, there is no way to bypass that login page. This is precisely because there is more than one option, and, should you need to login with a different method, you need a way of getting to those. What we have implemented now is the best compromise to meet all of the various login/authentication requirements. Gerry

@Osman You can disable this option in your CSS profile, which will then not ask you to authenticate if you are already authenticated on your IDP Gerry

@Kelvin Ahh if you are trying to do this in the Workflow thats a different thing, I thought you were talking about the email routing rules. So in this case you only have Regex Substring as an option, I am not familiar enough with RegEx to off guidance on what expression might be used to get what you want. You may want to raise an enhancement request to have the SM team provide something equivelent to the TOKEN() function I mentioned above in this String Utilities list Gerry

@Kelvin You can also use TOKEN(), please see the following document for full details of whats possible Email Routing Rules: https://docs.hornbill.com/esp-config/email/routing-rules The Expression Engine: https://docs.hornbill.com/esp-fundamentals/reference-guides/express-logic Gerry

@Adam Toms We are definitely looking to build out a certification program, thats in the long term roadmap. We would like to see our customers gain a higher level of procifiency and experience with our product, which continues to evolve with ever more comprehensive capabilities, we recognise that customers are not even aware of the scope of our product capabilities, something we believe the academy, the new documentation and otehr customer-enablement initiatives we are starting to build out. We are currently focused on content, and we have quite a ways to go with that, but, we are investing this this initiative, and have a dedicated team of people behind the academy focused on building this out. We appreciate the feedback, please make use of the academy and all feedback welcome. There will be a certification program in the future, but thats very unlikely to appear in 2024, we need a lot more content development first, which is where our current focus is. Gerry

@GJ06 No unfortunately not, that is one of the problems we are trying to solve. In all honesty we have no idea which customers are using which API's, we have done out best to determine this from the logs and other sources of information we have, but its not so simple to determine, this is because the API catalog customer have been using, is the same APi catalog as we are using internally. This change is about making those two seperate things. Technically, the API's currently. although not documented anymore, will still work today unimpeded, but the basic aim is, if the API is not earmarked for customer use, its not appearing in the new documentation, and the legacy dev documentation that was previously published to api.hornbill.com has been removed. We are not proactively seeking to break things, but as I said, we have no absolute way of knowing exavtly what API's customers are using, we ourselves are trying to make that determination. It is critical we make this change if we are to provide a stable set of APIs for customers, that are of high quality, well documented, and properly supported from an availability point of view. The above problem reported by both @ChrisDee and @CraigP is a perfect example of this. The API ( getUserProfileAssets ) appears to be broken, almost certainly because something changed and this API did not have test/validation in our test automation. In our current approach all API's are equal, what we are putting in place is, specific API's that are customer facing will be treated with a much higher priority, will have more testing applied and will be objectively more stable as a result. @ChrisDee @CraigP in relation to the getUserProfileAssets API, this seems from the error message to be a defect that we have inadvertently introduced, this specific problem is not as a result of the API architecture change, there seems to be a simple software defect. I will ensure a defect is raised against this and it gets fixed ASAP, this ought to be something we can simply hotfix, in relatively short order I would expect. The question as to weather this API should be promoted to a customer-facing API is still open, for now it will continue to work. On the face of it, looking at the API spec it does not pass our Quality Requirements in terms of being properly documented because we are exposing an undocumented JSON structure via an xs:string property type. As I mentioned above, its not our goal to mess things up for customers, so we need to provide a more definitive answer to this for you. In the mean time, we will fix the API so it will once again work as it was previously, and I will raise this API with the dev team who can make a further determination as to the status of this API. @ChrisDee Thanks for providing the explanation around the Device Audit facility, I am not sure I understand what that is in detail, but I will pass onto the Service Manager product team to look into this, to see if this is something that we should be including in Self-Service rather than you having to roll your own, or, if not, we should be providing you with the requsite APIs you need to DIY this as you have done. Thanks Gerry

@RichardD The official position is, if the API is not published on https://docs.hornbill.com/ then its not available for use, and, more importantly is not stable, meaning its subject to change at any time, without prior notice, or any steps to take care of compatibility issues with existing use. Right that all sounds very harsh... but the truth is, we are in transition when it comes to APi's and the Hornbill. Our original strategy was to document and publish *ALL* API's, and over the last 10 years that list has grown to 1000's of them. Not only do we create (reasonably well documented) API's at the platform level, we also create many API's at the application level, and over the last 10 years that has led to a number of problems * Many API's that are published are not generally useful to customers, creating a "cannot see the wood for the trees" problem. * The focus of our API creation has been to support our own development efforts around front ends, administration and integrations, customer access to API's has typically made use of a very small subset of API's. * Documentation ranges from acceptable to very poor. Many API's used for supporting front end UI functionality have ended up using strings to store/load complex JSON structures that are basically not documentable. The scale of our API's along with a need for *much much better* customer facing documentation has led us to a point where we need to create a different set of API's for customers. A smaller, much more well defined, stable and importantly well documented, high quality API's, and thats been part of what we have been working towards. To that end, what is now documented on docs.hornbill.com is our current take on what API's we feel need to be customer facing. All other API's that were there before are *currently* still available to be called, they are just not documented. However, it is important to note that, ultimately if the API is not documented in https://docs.hornbill.com/ then its probably a good idea to assume that you are using an unsupported API, which, is very likely to change, break or even disappear completely from the system, without prior notice from us, and without any contignecy for backwards compatibility or alternatives. Which will mean it will simply stop working, and if that happens, our support team will look at the documentation, and if its not available, there will be no immediate fix. That is not going to happen over night, but there is a strong possibility it will happen in the future. We are in the somewhat bizarre position today that, if we need to change, or depreciate some API's in support of our work in our own product, we cannot because we had no idea who was using these API's, this is crazy given the vast majority of API's are only ever used by us, so, we should be free to change them in order to improve the product. So there is a very strong need for use to be able to both commit to a stable set of API's for our customers to use, and API's that we can use/change/evolve as we see fit, knowing we will not be impacting our customers use of API's If the specific API you are talking about (getUserProfileAssets) is something you feel should be customer facing, then there is no problem proposing that, we would need to run that through our internal team/process to make sure there is no other reasons why it should not be added as a customer API, and on the back of that, I will raise that question internally for you. Can you tell me what you use this particular API for? As part of our overall documentation effort at Hornbill, the aim is to drive up the quality of our documentation considerably, and the API documentation is a big part of that effort. Internally we will be publishing a "Customer Facing API Quality Standard" which will mandate our developers meet a certain standard before making API's generally available to customers. By standard I mean, using correct data types, documenting each input/out parameter properly, setting appropriate security controls, providing an examples for use of the API etc... and of course, for the API's that are documented/published, we have quite a lot of retrospective work to do in this regard. The end game is, our customer accessible API's will be completely independent of our internal API's, we are working on significant changes and architectural improvements to our API infrastructure that will help facilitate this transition. Hope that helps Gerry

@Alisha There is no limits, you can really have as many routing rules as you want. The processing uses in-memory evaluation of expressions using our ExpressLogic engine, it is very very fast, so the expressions or numbers of them so unless you start adding 100's of 1000's of rules you are good to go. Please keep in mind though that the more of these you add, the more of a headache it will be to troubleshoot, although we have recently added something that will be released very soon that will help a lot with that. See the attached, each email message delivered into your Hornbill instance will now include a log detailing the email delivery/import process. Of particular interest will be the part of the log that shown in the green box, which shows you the inbound email routing rule processing, and if any of the rules matched. This new log will be out in the next week or two, so please watch this space. 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