Jump to content

Gerry

Root Admin
  • Posts

    2,437
  • Joined

  • Last visited

  • Days Won

    172

Everything posted by Gerry

  1. @samwoo " I guess the only issue is what if the same image is being used in multiple places such as on the BPM, Email Templates etc." to be honest, this was never intended to be a full CDN backed media/content management system, it was really intended to make it easy to host a small number of static images that are used primarily in the configuration domain of Hornbill. To achieve a combination of media sharing with consistent links requires a lot more to be implemented around cache invalidation, link management and so on, that was not really in scope here - its our bad for adding the ability to update an image without thinking this through. To save any confusion here in the future we are going to remove the "update image" option, so to update an image, you will need to create a new one, then update the place(s) where the image is being used. Thanks, Gerry
  2. First tests on beta, with 2FA working nicely for user logins. (email on left, login page on right after you entered login credentials) Gerry
  3. For performance reasons the images are cached by our public CDN's so updating an image is generally not a good idea if you already have something in use. To resolve this issue, just create a new image, which will generate you a new ID/URL and use that. Gerry
  4. @RIchard Horton "Multi Factor Authentication should now be available to turn on" This is currently being implemented for both Hornbill User/Basic User Direct Login and Customer Logins, expect this to be available in the next 2-3 weeks. Gerry
  5. This should be available soon, will be in the next core update... Gerry
  6. @Jeremy Unfortunately no, this is very email client dependant, and generally because of security there is no way for us to get the email address from within the mail client. There are two authorisation schemes available on the Hornbill platform. External Authorisations - these work like most typical built-in authorisation implementations, the audit trail relies on the fact that the system sends an email with a link containing an unguessable one-time-use token, when the user clicks the link it takes them to a page to do the approval. The verifiability relies on the fact that the recipient DOES NOT simply forward this on but acts on it accordingly, you rightly identify that if your user does forward that on to someone else, or if you try to do things like distribute the authorisation request to an email group, you essentially loose audit-ability. This scheme is included with all subscription levels and allows you to have an unlimited number of authorisers in use on the Hornbill platform without them needing any form of subscription - these are what we generically refer to as "free authorisers" Advanced User Authorisations - this is a significantly extended authorisation capability, with these types of authorisations there is built in support for majority, master and weighted group authorisations, custom forms, custom outcomes, mandatory and optional addtional fields and a whole host of other features that make Hornbill's BPM very powerful orchestration tool. However, any user doing authorisations using the advanced user authorisations is REQUIRED to be authenticated on the Hornbill platform. This does mean, that from an audit perspective, every authorisation decision made is audited and is traceable to individual users. In order to use this though, each user who will "authorise" stuff needs to be a Hornbill Platform/Authorisation User which requires a user subscription, a subscription to the platform authoriser user - not to service manager its self. Basically External Authorisations are provided and are functionally equivalent to how most of the service desks and other similar workflow systems work. Advanced User Authorisations are provided as a significantly extended enterprise-level capability for companies that need more flexibility, customisability and especially audit traceability when handling authorisations. Typically in IT-type workloads, External Authorisations are more than sufficient, the general audit requirements are not that stringent. But, when dealing with security, audit, PII and other regulated data/workflows, then the more professional-level Authorisation Scheme is often required, this is where ESM type requirements often come into play and what AUA's were built for. Hope that helps. Gerry
  7. @lee mcdermott 100% possible and very easy to do - no coding required, pretty much point and click, many customers do this sort of thing. For Azure AD you can do it with tiBridge (cloud automations), for behind the Firewall AD you would need ITOM (for on prem automations). Gerry
  8. @Paul Alexander Yes thats well hidden away, I think we can add an entry into the admin index without too much trouble. Gerry
  9. I think this comes down to not understanding the full scope of capability here. A task has many configurable options for completion. For a start, a task can include one or more custom fields that can be included in a task, so when you open that task there are extra fields shown. Populating/seeing those fields is not the same as completing a task. This is why there is a task "view" state and a different task "complete" state. When it comes to task completion, a task can present/require addtional fields of input form the user, these fields are global, and presented regardless of any chosen outcome. One or more of these fields can be mandatory, meaning until those fields are completed, none of the outcome buttons are activated. Then, after all that, each individual outcome can themselves define even more custom fields, that are either optional and required for that particular outcome, this means that when you press the outcome button, you many or may not be presented for even more input. Ok so I know that most people will not use these features all together because that would be complex (and annoying) to the extreme for task users who need to complete a task... but, we have to support these scenarios which is why when a task is opened there are two states, view and complete. For exactly these reasons, the checkbox icon cannot be a quick complete action, because that would introduce variable behaviour, meaning, for some tasks it might just complete, but for other tasks you are presented with a choice of outcome, and yet for other tasks, you might be presented with addtional information you have to provide for the task, and yet for other tasks you may also be required to provide outcome-specific extra fields, that may or may not be presented, and all dependant on what outcome you have selected. The tasks in Hornbill are really powerful, but they have to deal with all of these scenarios. and that makes for a less than ideal interface. We could dumb down the task behaviour and remove the task custom fields, and the outcome specific custom fields, but my feeling is that would take quite a lot away - and anyway we have quite a few customers that do depend on this extended behaviour. "This is a UI frustration that I wanted to bring to HB attention but also to ask if this is something I can avoid by re-configuration." Now I do take your point about not having the view state, if there are no custom fields defined, that would be possible, and possibly we could look at improving this, we could add more smarts so, if for example, there are no addtional mandatory fields we could present a list of outcomes without having to open the view, but we are back to doing pre-task behaviours which will only lead to more frustrations as users who did not configure the tasks don't understand why, sometimes it just completes, other times it opens a details view and presents more fields etc.... It may well be if we revisited this we change the strategy and simply have different types of tasks that have distinctly different behaviours, less flexible, but possibly easier to use. Gerry
  10. +1 for me too, not sure this would be difficult to implement, the minor complication is managing the case where you select a user that has a higher priv level than yourself, in that case we should not allow the copy. I will ask the folks that know to see what is involved. Gerry
  11. @Kelvin As above, yes that is correct, as it is currently implemented, only people with a livechat subscription can access the embedded content within chat sessions. I expect if you integrate with any thrid-party chat tools I am sure you will find pretty much the same situation there too. Gerry
  12. Hello Kirsty, Just to confirm what @James Ainsworth believes, in order to access the embedded media content within conversations maintained by Hornbill Live Chat you need to be allocated to the Hornbill LiveChat application as a user. That was a design decision taken when LiveChat was implemented as this is fairly typical of these types of chat systems and their integrations. Were we to transfer the content as well as the transcript text, we would be essentially re-creating another read-only version of LiveChar (at least under the hood) to achieve that, as well as some very tightly coupled dependancies. Gerry
  13. @Llyr Hi, my understanding is our CS team have spoken to you last week and answer your question above, do you have the answers that you need now? Gerry
  14. No problem, glad its sorted out for you. Gerry
  15. @QEHNick No apologies needed, I am very grateful for all feedback, good or bad, we are always driven to make Hornbill better and make sure our customers get the very best of what we can make. I think they guys are working on sorting the free edition stuff. Gerry
  16. @John C You simply disable the SSO profile(s) that you don't want to use, and the "LOGIN WITH SINGLE SIGN ON" button will not be shown... Gerry
  17. @QEHNick "Glad I found another bug" Hornbill is a really complex system and we do our best, things like this do creep in from time to time, as is true for any software, but we do our best to identify and resolve these things quickly. Gerry
  18. @QEHNick Ok devs understand problem and will apply a fix, should be done and pushed through the pipeline in the next couple of weeks. Gerry
  19. @QEHNick I was just checking. Its not part of your current subscription plan. It can be easy enough However, you should have the free tier available to you, but it seems along the way, as we made ITOM its own app we seem to have broken the ability to install the packages when there is ITOM subscription, which is not correct. We will need to get that resolved, once fixed, you should be able to use the free tier of ITOM without issue. Will post back when I have some answers... Gerry
  20. @QEHNick Active Directory Group Management is a premium ITOM package, so if you want to run it unlimited, you need ITOM Basic Acct Management subscription. However, you can use this for *free* but to a limited number of runs per month. 10 I think is the monthly limit. Now the point about being unable to install the package in the first place, that I am not sure about, I will need to ask and post back. Gerry
  21. @Martyn Houghton To be honest with you that list in the portfolio will be going at some point, its a bot odd that its there, at least in its current form. The request list and custom views can be used instead to get the same data so I am not included to do anything here with this. Gerry
  22. @Berto2002 every time I do that its so annoying, so I know what you mean... Gerry
  23. @Melissa Gurney "Do sessions within Service Manager periodically reauthenticate?" yes, sometimes. What happens is this. When you login and authenticate with your AD, Hornbill will create you a "user sesson", and this session sets a cookie on your browser which is a reference to your session. Using Hornbill from that point forward will not go and re-authenticate with AD, it relies on the created Hornbill session. However, this does have a timeout, so if you were to refresh the browser window, then Hornbill *may* re-authenticate you with your SSO provider, if SSO is configured. If you open up another browser window, it will, by default, use the same cookie as that cookie (ESPSessionState) remains valid across browser instances. As @Martyn Houghton says above, if you want to log into two different user accounts on the same computer, you will need to open a new incognito window, this is how we do it when demoing the software Gerry
  24. @Berto2002 Thanks for the summary above, I will feed this back into development. Gerry
  25. @Melissa Gurney That is controlled by the Azure service, I expect there are options to configure and control it. Hornbill does not control this behaviour. At the point you press the Login with SSO button on Hornbill we redirect to ADAzure based on your configuration. Its up to ADAzure what it does from that point, up until it redirects back to our service with you having been authorised by ASAzure. The default when using ADFS (or at least how most people have it configured is, when you are redirected to AD with a request for access to a resource (in your case Hornbill), the ADFS server will, if you are already authernitcated, simply redirect you directly back to Hornbill with an appropriate authorisation assertion. Sounds like what is happening above is when you redirect to ADAzure, even though you are authorized already, its holding you in its landing page until you click the account, or whatever its expecting you to do. The specifics and details of how ADAzure works is beyond the scope of my understanding (and most if not all of the technical folks at Hornbill), this is really a question you would need to pitch towards Microsoft or your internal ADAzure experts. Gerry
×
×
  • Create New...