Gerry

@samwoo Thanks, so looks like one of the back-end servers might be down, and the front end is not corretcly failing over to the other ones, have reported it - by which I mean the 502 error There also seems to be a defect we can re-create in Firefox (and therefore suggests its a defect) where the link to a document page takes you to the home page and not the intended document, this we will investigate and sort out. Thanks for reporting Gerry

@samwoo Thats weird, it works for me ok. What browser are you using? Can you re-create this? If you can, can you screen dump the network tab in your browser after the error? Thanks Gerry

@Berto2002 The reason why we made that change was when you create a workflow, it does not appear in the list because its in Draft, and that confuses people. None the less, I understand why, once you have your list its better to be set to Active workflows. To that end we will make it a user setting, we will default it to all workflows, but make it remember your last selection Gerry

@Berto2002 I expect thats a defect, probably arisen from a confusion around an ou type 'function' and a functional group. A functional group (only one type called 'team' at the moment) is the only OU type that can have tasks assigned to it, therefore you cannot associate basic users with a team. Other than that, there should not be a restriction. The documentation around this can be found here... https://docs.hornbill.com/esp-fundamentals/core-capabilities/organization-and-teams I will nudge the dev team to take a look at that, it should be fixed soon, or if I am not undertsanding something I will post back here. Gerry

@samwoo @MacLean Ferguson Latest release notes to hit beta, simple lists can now be modified through Hornbill iBridge and Core automations in the Workflow if required. Gerry

@Martyn Houghton ok so your saying, an actual node (like a label in a schematic tool) that simply points to a via node. So nia nodes would need to have unique identifiers so you could select the via to goto. Is that what you are saying? I have to be honest with you, my instincts are saying we should not be making it possible to create ever increasingly complex workflows when they are so complex does that not make them a total nightmare to maintain? From a diagram./flow tool point of view, I like the idea, simple and as you say would be quite useful, especially if, when browsing the flow and you click that node it would pan and bring into the focus the node it connects to. I will ask the question internally to see how via(ble) forgive the pun that would be Gerry

@Martyn Houghton I would say, you really ought to try and simplify your workflows I am not sure I understand what you are asking for here. You can already have more than one route into a via node... but I am guessing thats not what you are suggesting? Gerry

@Martin.bowman The problem with setting status anything other than manually is it defeats the point of having a status in the first place. Like you mention, even at Hornbill we do not set the status when we should be doing so, it seems that some people are simply not interested. If it worked like a clock-in/clock out system where your salary was calculated from those times I expect more people would be keen in relation to shifts, the use of the status to control when someone can have requests assigned to them is one thing that could be done, but as you say, if people don't set the status that would be a simple way of avoiding work - like "oh I forgot to set my status, sorry". I have never really given much thought to how one might be able to manage work when operating shifts. In a past life, shiftwork was handled my by dealing with work in queues, perhaps a different way of thinking about it, but imaging if when working requests, you never had a request assigned to you as an individual, instead, you was a member of a group and requests were assigned to that group, then your process would be, you must work on requests in that group. Not sure if any one else has had any other experiences? Gerry

@ilyaas It would be relatively trivial to add that option to the automation, but as @Steve Giller rightly identifies, there is a regrettable hangover, that some customers use today where the email field is not unique in the contacts database, and so, if we added that option we could not guarantee you would end up getting the right contact where you do not have unique email addresses. In fact I had a quick look and this was easy to add, so it will be there in the next core release. Gerry

@Rob Gething Without trawling the change logs/source code, I wonder if there is something here in relation to the fact the API key is created on the admin account. The admin account is treated differently in quite a lot of ways, so as a potential suggestion, I would create an API key on a non admin account (your own for example) who can upload files, and then try your integration with that key and see if you get the same problem. Also, if you are putting content up on the session folder, PUT is what you should be using, so that seems right, its just a permissions issue. Gerry

@samwoo Ok so to summarise I think you are using the simple list to set a value a bit like an atomic global variable as a way of allowing one ticket to make its self visible to another ticket. The problem I see with doing this is simple lists are really designed for standing data, so while you may be able to get something like that working, I would suggest its unlikely to be reliable for the reasons I mentioned above, so is not something I would be comfortable recommending, it feels like a hacky work-around for some kind of data token (request reference) sharing/gating. Let me ask you this, just in case I am not fully understanding your explanation. If the perfect automation to enable you to achieve the outcome you are trying to get to existed, what would it be? what would it look like? Gerry

@MacLean Ferguson In that case a simple Hornbill automation on the com.hornbill.core app is probably the right answer., but via the BPM there may well be a priv's issue, adding to a simple list requires certain rights, if the user does not have those rights and the BPM is running in the context of that user then using an API key to call back into the instance through the iBridge gives you more control, so in that case it would be better to add this to iBridge Hornbill automation. Probably sounds like we need both - I will ask the integrations team Gerry

@Andrew Parsons The act of adding a request onto a board is a "transactional" operation, and is not as a result of a dynamic query. That in turn says that in order to add a request to a board lane, you have to add the request via a transactional operation (aka API call), which in turn means, if you want to do what you are describing, its more than possible, but you would need to write a custom script which you would schedule to periodically add requests to a lane when the correct conditions are met using the Hornbill API Gerry

@MacLean Ferguson Thanks for your question. First, I do want to say that we are delighted that customers find new and imaginative ways of getting more use, and more value out of Hornbill, we are all for that. Its just when we see things that might lead to things breaking in the future. or might lead to unpredictable results then its worth thinking about. Sam has asked for some features that will help facilitating the dynamic changing of content in simple lists via a workflow, and in the absence of a ready-made Hornbill Automation to do that, he has found a way of making an API call via the iBridge back into the instance to achieve that, but is asking for a better way. Sop now we know he has a need to do that, what we do not know is whats the use case, because perhaps there are better ways to achieve what he wants. Ok so there are a number of things from the above use case that Sam has deployed that stopped to make us think... He has used an HTTP Request method in iBridge that is clearly marked as Experimental, that means that capability could actually be removed, or changed without notice at any time - not a very good thing to depend on in a production environment. Simple lists, are by design, an "customisable via administration" static list of data. These are designed that way, and while a simple list on the face of it is just a bunch of small records in a database, the reality is quite a lot different to that. Often, as in this case, we do highly optimise these sorts of lists, typical read many-write few caching semantics, which means, we load from the database and keep things like this in memory to keep database I/O and traffic low and efficient. Now if a simple list is being used as a dynamically customisable list on a Workflow by Workflow instance, that changes the nature of that data completely, specifically the caching semantics are off, and we could easily end up changing our code in the future that could change this behaviour, for example, we might have delayed write semantics, in a distributed environment, this means there is no garuntee at all, that when you make an API call to change the data, that the next API call that hits a different process might not even see those changes. Further more, simple lists are global, shared lists. They are not designed to be dynamically changed on a request by request basis, on busy systems you could easily end up with data loss or corruptions as far as any application logic is concerned because the write semantics will most likely be the last write wins. So the reason I ask the "what is the use case" quesitons is, I would rather none of these things happen to Sam, I would rather offer guidance that would enable him to avoid these types of situations. Sam has worked out a way to do something he speicifcally needs to do, I am asking what does he specifically need to do, so we can understand that, and consider if Service Manager should offer what ever he needs to do as a feature/capability so that he does not have to use his technical solution which feels like it could be a bit of a work-around. Now, if Sam says, we are using the automation to set up a new department and we need to add that department to a list of departments, or something like that, where you can see its more of an automated administration task, then fair enough, adding that to either a Hornbill automation (via Workflow or AutoTask, or even as an ITOM package would make perfect sense), but as I say, that does not appear to be what he is doing, which is why I have asked the question Hopefully that all makes sense. Gerry

Hi @samwoo At first glance we are not sure this is very wise, I will expand on that, but before I do, can you please give us an outline of the use case here, and why you need to dynamically change simple list content via the BPM? Thanks Gerry

@Jim In Hornbill, Date/Time values internally are always represented and written to the database in UTC, that is, without any adjustments for timezones, this you can think of as an absolute point in time, relative to the international standard of Coordinated Universal Time (UTC) https://en.wikipedia.org/wiki/Coordinated_Universal_Time Throughout the system this is our standard and allows to display any date/time value in any local time and removes the need for us to try and track Timezones along with the date/time value. So all you need to do when working with these values is always work with them in UTC for calculations, then, when displaying, or including in a report for output to PDF or Excel, you need to convert the date/time UTC time point into local time. This is why when generating a report and in many other places you are required to specify a timezone. Gerry

@will.good Just looking at this, it seems this should not currently be visible, this is a feature that is being incrementally rolled out, it should not have been visible here just now. Whats happening is, although the UI component is showing up here, its not saving any values in the templates. We are just out of sync between the combination of the UI, back end and Service Manager app, this will be resolved in the coming days. Apologies for the misstep here. Gerry

@will.good @samwoo Please accept our apologies. When we are rolling out new features we often role out changes incrementally, because different layers of the tech stack arrive in production at different times, we put these changes behind version gates so the code can be present but not yet activated, allowing self-activation when all the bits finally land in production/live environment. We do this a lot and its a well trodden path for us, but, In this case we missed something for an upcoming feature thats "on its way", we have now deployed a hot-fix to correct that. Entirely our failure, we apologise for any inconvenience caused. Gerry

@Nikolaj Also, please refresh your browser, looks like there might be a local browser cache issue that stopping the view from loading Gerry

@Nikolaj We have added Login History under security and we have moved the Security Audit to the Monitor section, please scroll down and you will find it there. We have also added IP GEO information to the Security Audit. Gerry

The following roadmap item has been added to the 90 day commit for the Hornbill platform. This will include a number of of addtional improvements all designed to help working with large numbers of email templates more workable for our customers. We are aiming to ensure current behaviour is not disrupted, but you will be able to take advantage of the changes progressively and in your own time

This has been a long outstanding request, we are having a look at whats involved here. I am not familiar enough to make any real assesment at this point, and its a bit concerning that according to the above that supporting teams in the service portfolio somehow influence the visibility of these email templates, that seems a bit odd to me, but I will find out and see what we might be able to do to make these more manageable at scale. Gerry

@Mhari Lindsay Is this effecting all users, or some users? Gerry

@Mosh this may not be related at all, that looks different as you say, I will ask our support team to reach out to see whats up. Gerry

Et'Al, The error we are seeing is only impacting a very small number of customers, and within those customers only a very small number of users. We can see the symptom in the error, the essence of which is a check on the browsers Origin header for a value which is expected to be a domain, we are getting the value "null" which apparently is something browsers do, and we do not handle this condition which causes the error you see in the browser to be thrown. So while we can handle that exception and not throw the error, we are not at all sure that the cause its self will be resolved. So for now we are not going to hot-fix, we are going to spend a little more time trying to understand the cause, and not try to treat the symptom just yet, simply on the basis that the hot-fix might handle the error (the symptom) but the cause may well still be present. As part of yesterdays update we have changed the encryption keys that are used to create the ESPSessionState and CSRFToken cookies when logging into Hornbill. This means those cookies will be invalid for anyone who left their browser open and logged in over night. We did take care of clearing down those cookies if invalid, which is why most customers are not seeing the issue, what we do not understand is why a few individual users are seeing the specific error that has been reported. If there is any more useful information to be had, we would appreciate you posting or letting our support team know, the more information we have the better we are able to understand. If there is anyone else reading this who is still unable to log in, please contact support or post here, we are on standby to help, and it should be a simple case of a Ctrl-F5/Browser restart to get you going again/ Thanks Gerry