Gerry

Daniel, It might be worth hiding this option in the profile settings for now, just until the back-end has changed, otherwise this will be misleading for people. Gerry

Hi Martyn, Oddly it used to work like that but it was confusing and complicated, you could assign roles to teams and team to roles. Its not something we are likely to change back now. Generally you should assign permissions through roles and assign roles to teams. If you need variations of permissions, then you currently need variations of roles. Gerry

Adam, I just "liked" your comment I do agree with you, I said we would not change it in the app by default, but you can on an individual instance if you like Gerry

Martyn, Because of the different architecture there is no concept of multiple portal accounts, to implement such a thing we would need to make a similar method in the SM portal configuration against each basic user/contact account so these options could be set and controlled on a user-by-user basis. This is something that the SM team would need to add specifically so I will let them answer specifically where we would be with this. I just wanted to respond to the multiple portal account question. Gerry

A further update.... You can go into Admin tool Home -> System -> Hornbill Change History And see the change history for the underlaying platform (very technical), the Admin Tool and the User Tool, the change history is broken down in the same way as described above, so I guess thats what you require for Service Manager and other apps? Gerry

We received some product feedback the other day and I thought I would answer the question here on the forum as its quite an interesting question. I have kept the originator anonymous, the comment was.. Now the reason why we use the word "like" is because its something people are familiar with in other applications. Although one can draw a literal meaning from the word its self, there are in fact two literal meanings of the word "like" in the English language. The first is when you linken one thing to another thing, for example "That car is just like that other car" so its a comparison of sorts. The second form is when you express your liking of something, for example "I like that car". In the context of our application we use the term like as a sentiment of agreement, so we are using the first meaning above where you express that your in general agreement with the comment/posts, in other words you expression of approval is like others expression of approval. Personally for me, there are many things at work I actually do like, and sometimes there are things at work I even love so I will tend to use the like button to both express agreement and sometimes I will use it to like something (for example, a picture of a car I really like), so I find it hard to agree with the logic of this suggestion. If we were to ever change that word a most likely candidate would be AGREE but thats too formal and would be like a contract agreement, and with that word I could not express my liking of something - so in this case the English language and the dual meaning of the same word actually works out quite well for what its being used for. Now all that being said, i would have no intention of changing it in the product, but, if you so desire, using language translations it is of course possible to change the word like to anything you want, all you need to do is agree with whoever is managing your instance and they can use the translation capabilities of the platform to change it for everyone on your instance. Gerry

Hi Ralf, Greg and Sam, I will need to look into your comments as there should *never* be an update that does not contain at least one release note item, so not quite sure whats going on with the rapid updates on the same day with SM, I will need to find out why this happened, it should not and I can understand why this would be of concern. Now I appreciate that advanced notice of new features could be useful in some circumstances but the problem we would have with this is our automation and our continuous delivery process. We release from test -> dev -> beta -> live, generally through a 72 hour window, any release can get pulled at any time, in other words something that makes it to beta may well not make it to live. The publishing system knows this and organises the release notes accordingly but save for blocking intervention by us this process is largely automated. It would not be possible to "accurately" pre-announce any upcoming features, and we don't have a mechanism in place to send e-mail notifications about releases. We rely on pushing change notifications via HH Notices, and (correct me if I am wrong here) but we don't push disconcerting changes either, we try to keep changes progressive and easy for users of the system to stay abreast of - this is core to our Continuous Delivery process. Greg, could you please give me specific examples, I presume in this instance you are talking about Self Service portal, I would like to understand what the big change was so I can take a look at our release and communications approach, it occurs to me that HH notices do not work for self service portal feature changes. I would add on this point that I know there have been some fairly significant improvements in the portal of late so this might just be an exceptional perception, rather than something you can expect on a regular basis as we may well have pushed a disconcerting enhancement(s), I will need to find out more. Samuel, Ralf, I was just looking at admin2 and I see the release note functionality is not as granular as it used to be in admin 1, I recall you could see previous updates which where grouped out by build number and date...not quite sure why that changed, I will need to ask the question of the dev team about this, we will update you further once I find someone with an answer. Gerry

Hi Martyn, The only problem with doing this is while it would work for short lists, it would be hopeless for long lists of stuff. Some people use these with 100's or even 1000's of items. Perhaps an option would be for each list to have a sort by ID/sort by value option, that way for short lists you can use the ID values to imply sorting. Would that work for your requirement? [edit] Just read what Daniel suggested so thats the same as what I am proposing. Gerry

Under the hood this will be an ECMA expression... However, I expect that we are quoting any static value that is entered in, so putting the value undefined in the field probably results in an expression som_var == "undefined" Now I am not sure this will work but try entering the following value into the field &[undefined] and that might work, although just a guess, its something to try. Gerry

Hi Ginny, I am sure our application is not doing any "blocking" of anything. I am not sure what the problem is from what you are describing but it is most likely something to do with browser security. Can you provide more information about the error(s) you are seeing? Maybe provide a screen shot or something else that will give us more information to go on? Thanks Gerry

Adam, The setup is fairly straight forward, it would only take a few minutes. You do a lot with/for us so when you are ready one of our product specialists will gladly jump on a quick remote session and set it, so we will take care of it for you, and if you want we can show you how simple it is too. I presume you are going to be running AD and Azsure AD in parallel for a while? Just schedule a time when you would like to switch over and we will take care of it. [edit] I should have mentioned that we would set up both SSO integrations, verify the new and existing one works and show you how to flick the simple switches to enable one and disable the other so you can throw the switch yourself whenever you are ready. Gerry

Samuel, Just to let you know this problem has now been resolved and will be in production within 72 hours. Our fix is to silently remove links to the group(s) being deleted if those links exist to archived users. Gerry

Nasim, We are looking at putting our services through a much better front end cache, we are doing this for redundancy as well as initial load performance for users that are out-of-region. However, this might offer you marginal improvements when remote as the cache provider has much bigger backbone links than we do so static cacheable content (the UI basically) should get served a bit faster than it does currently. Gerry

Hi Samuel, We have been monitoring your instance and observed a number of areas where our application could be made more efficient. To the best of our present determination at this time, its not one specific issues, its a combination of smaller performance issues that are culminating to sometimes show slow responses to API calls around call request management. This only becomes apparent when there are spikes of busy time which is why its been unpredictable. We believe there are a number of areas we can improve and so are planning how to deploy these changes as we make them, so you can expect to see incremental improvements in performance when logging a request over the next 3 to 4 weeks. Here are some things we know for sure. We found that our SM implementation is using Flowcode security elevations, in some cases 15 or more in a single call. We found that our implementation in the core was less than efficient in the way it handled these elevations. We have already applied a fix for this which improves that performance, this will be in production very soon (if not already), although in isolation thats only a small overall improvement, but an important one one the less. We know that in some operations (in particular logNewRequest) where we have duplicate redundant queries. These have come about as we have expanded functionality and have modularised our code to handle the functionality - we plan to re-structure the flow of code in order to remove redundant duplicate queries. In some areas we have been using SELECT * FROM .... on tables that have a large number of columns, only to then use a couple of values. This is a bandwidth and resource hog on our database layer and needs to be optimised. We are doing far too much of the functional logic during synchronous operation of raising a new call, which has the effect of appearing much slower than it should be. We will be re-factoring some of the code so much more of this is done asynchronously after the operation completes. So we have lots of places to improve and optimise and we are on the case. It is inevitable that we will have to go through refactoring and optimisation cycles like this from time to time, but as I said before we do take this stuff very seriously, the last think we want is any of our users having the perception that our service is slow or clunky - we ideally want our users telling their friends and colleges how awesome Hornbill is We will keep this post updated as we make further progress, I have asked SM application team to post an update here this week. In the meantime, if you have any other relevant information please do post it here. Likewise, if you see improvements please also post here Thanks Gerry

Steve, Yes thats exactly right. Although we have a schedule capability that works, I think what the team are questioning/feeling for, is weather or not scheduled calls is really a good idea. The main problem with scheduled calls is proving variable input. If thats not required its relatively straightforward to implement although I am not sure at the moment there are sufficient platform functions available to the application team (Service Manager in this case) to easily schedule application-specific stuff. This will probably lead to having the ability to schedule the invocation of an application-provided API (FlowCode) but then we are back to the problem of how to easily map the required input params of the flowcode to sensible values without making our customers need to have to "code", we are 100% committed to code-free daily use. In Supportworks we always had that crutch to revert back to a bit of PHP or JavaScript but we dont like where that leads to (inability to update) so the product teams here at Hornbill are mandated to provide user features that are easy to use and never require coding/scripting/complcations.... thats why this is taking some discussions.... Gerry

Hi Samuel, Thanks for the feedback. Given the problem you have identified, this is actually a defect in the way we handle deleting users that are archived, our service should not have a problem with archived users and should handle this properly. The only explanation for this is we do not have an automated test case in place for this scenario which is our bad I am afraid. I have asked our core platform product team on the back of this post to add the required test cases to ensure we can see the problem(s), we will then fix them and you should see the fix(es) in production in 72 hours. Thanks for the feedback and sorry for the inconvenience. Gerry

Samuel, Is it possible there are one or more archived users assigned to this group? or have you been importing/deleting/cleaning data and lost some referential integrity. You can figure this out by using direct SQL to have a look at the alleged user accounts that are assigned to the group you are trying to delete using Direct SQL SELECT * FROM h_sys_account_groups WHERE h_group_id = '/YOUR/GROUP/ID' should show you the accounts that are associated with the group you are trying to delete. Gerry

Hi Nick, We should never regress behaviour on an API, this is part of our Continuous Delivery model so not sure why this would have changed. Someone form the service manager app team will look into this and find out whats up and why this appears to have regressed. If it has regressed that could indicate we have a gap in our automated testing so we need to get to the bottom of it. Once we do, if it has regressed we will ensure we restore it back to its previous behaviour. Gerry

Hi Ralf, I have been reliably informed that this problem was identified last week and will be fixed in the Service Manager release 2.27 which should be available very soon Gerry

Graham, I have moved this to the Collaboration workspace as this is not something specifically related to Service Manager Gerry

Graham, By default we do not include the original content of the message when replying, if you want that click the Quote (") button and you will have it as you expect. There is no setting as far as I am aware to make this happen by default. Gerry

Hi Samuel, It looks like there is an error with the SSL cert used for APNS notifications (these are the notifications send over the Apple network for Iphone, iPad etc), I will ask one of the infrastructure team to look into it. We appear to have failed to deploy the updated/renewed certificate, or your instance has had trouble picking it up. You can safely ignore the errors, right now it means apple mobile platform users will not be getting notifications to their mobile devices from your instance. Gerry

Hi Nasim, Your welcome. I understand the confidence thing, I hope though that what we will demonstrate consistency is our commitment and ability to identify problems and fix them quickly because of our continuous delivery process. I can never make a promise that nothing will ever be broken but I can make an absolute commitment that anything broken will get fixed and quickly too. Its live now so you should be able to test whenever you are ready. Gerry

Hi Ralf, Ahhh thats an interesting question indeed. So as it turns out, if delivery fails then you can re-send, thats the point of the option and it works - the delivery logging is awesome by the way . However, as you rightly point out you can re-send an e-mail that was previously successfully sent, and if you look at the delivery log you will see that the message does in fact get sent by our servers and you can see the remote server accepting the message. So the theory is very good. However....what you are probably experiencing is the recipient you resend to does not receive the message again right? So as it turns out, Exchange (have not really observed it on other systems yet but presume its the same) looks at the message ID of the originating message, which in our case is the same on each re-send and what appears to happen is Exchange recognises that as a "duplicate" message that it has previously accepted and presumably discards subsequent messages with the same message ID....rather than re-deliver it. That actually makes sense because its entirely possible that an e-mail network can deliver multiple copies of the same message when routing mail. So the "resend after a successful send" function is still a work in progress I am afraid, a little rethinking and experimentation is required to make this useful. Its on our agenda and will get addressed, we just need to figure out how to sensibly allow one message to contain multiple message ID's for traceability. Its probably a good idea for now for us to disable the re-send option on successfully delivered messages until we sort out that problem Hope that makes sense. Gerry

Hi Nasim, Just wanted to let you know that we pushed a number of fixes which went to live as of this morning. The use case has been a little unusual for us, but as it turned out we had far less than ideal automated test coverage on the platform for this specific thing. We have now rectified that with vastly better test coverage and in the process identified a number of areas that needed properly addressing, this was specifically around the use of single quotes in some areas relating to SQL record primary keys when building entity relationships and other such things. We have to acknowledge its a failing our part, primarily in having adequate test coverage which is why it appeared we had found one problem after another. Anyway, the net result is we have solved all of the problems we can see and don't expect there to be any others. I will of course caveat that with, it could be remotely possible we have missed something so if we have, rest assured we will do something about it. Thanks for your patience while we got this addressed. If you do run into any other problem please let us know and we will make it a priority. Thanks, Gerry