Jump to content


  • Posts

  • Joined

  • Last visited

  • Days Won


Everything posted by Victor

  1. @DavidCz it has been accepted as a defect and it's in development queue, but don't have any ETAs at the moment for a fix...
  2. @Smurfy one option is: https://wiki.hornbill.com/index.php/API_Scheduler For service requests I would look to schedule https://api.hornbill.com/apps/com.hornbill.servicemanager/ServiceRequests?op=logServiceRequest
  3. Yes, in Hornbill you will have only one, but in Azure, you need a different one for each endpoint... as I understand you have there (in Azure) an "Enterprise" app for when you authenticate to "live.hornbill.com" and a "Self-Service" app for when you authenticate to "service.hornbill.com"... so different apps in Azure for each HB endpoint.... but as for a SSO profile in HB itself, only one(*)... This is because, as you noticed, the "Self-Service" app in Azure has different certificates than the "Enterprise" app... but since we only have one Hornbill SSO profile it means that the (different) certificates of the "Self-Service" app need to be added to the existing SSO profile in HB. I believe the Azure authentication endpoints (entity ID, binding URLs) are the same in both apps, so the HB SSO profile (in Hornbill) just needs the (other) certificates... No. That advice is for when using the "customer.hornbill.com" endpoint, something that you don't use currently (based on service params I can see for your instance). (*)Note: There are scenarios when one can have multiple SSO profiles configured in Hornbill, for example having a (guest) customer portal or multiple IdP. These scenarios do not apply in the issue discussed specifically in this thread for the affected instance.
  4. @Adam Knee do you have only one app for Hornbill in Azure (named Hornbill Enterprise app)? If yes, then you can only used one of the XML files (which represents a Hornbill endpoint). If you need SSO on all other endpoints (admin, service, etc) you need a separate app in Azure for each... EDIT (as I typed while you replied): By importing the user.xml your Hornbill Azure app is associated with the "live" endpoint, so it will work when accessing that (as you confirmed). Once you authenticate in HB via "live" you can navigate to other endpoints (e.g. "admin"), you don't need to authenticate there when you have an active session in HB. However, if you are not authenticated in HB (yet) and you navigate to "admin" endpoint for login, you would need that "admin" endpoint Azure app otherwise you will not be able to authenticate via this endpoint. So the "admin" app is only required if you intend to authenticate via "admin" (or other endpoint) at any given time... hope this makes sense.
  5. @Mark (ESC) afaik, is any role that has the following System Right: The Admin Role has it by default but that is usually too much to be assigned to a regular user. So maybe add this right to one of his (custom) roles? Or create a custom role with this specific right and assign this role to the user. EDIT: Please note this System Right also gives access to mailbox configuration and all email, basically the Email section in admin tool. We don't have anything granular specific to email templates...
  6. @Dave Woodhead you can't have this as Auto... it needs a value...
  7. Looks all right to me, this looks like an Azure entity ID URL... Have you updated the Azure SSO app with the metadata from Hornbill? It almost looks like you updated the SSO profile but only part of the action was performed ... the full update needs action in both Hornbill and Azure (or the IdP of choice) As for the auto update for certificates, should be straight forward, turn on the option in the SSO profile and input the URL to the metadata...
  8. @Adam Knee can you login if you navigate to live.hornbill.com/... instead of admin.hornbill.com/... ?
  9. @Mantinder Singh This thread was posted in a subsection of About the Forum section. Please note this section is specific to our community forum functionality. For any issues or queries about the Hornbill product please use the relevant sub-section from Hornbill Platform and Applications section. Apologies for the lack of response on this, unfortunately, the forum section is monitored by a couple of forum admins and as such, it had very limited visibility to the Hornbill team. This thread has now been moved.
  10. @Adam Knee do you have a Hornbill Azure app for the admin endpoint? (each HB endpoint needs it's own app in Azure) Note: This thread was posted in a subsection of About the Forum section. Please note this section is specific to our community forum functionality. For any issues or queries about the Hornbill product please use the relevant sub-section from Hornbill Platform and Applications section. This thread has now been moved.
  11. @Berto2002 what is the Customer Portal for you? What URL you use to access the Customer Portal you mentioned above?
  12. @Smurfy there are various options... describe one of these automatic requests/tickets
  13. Are these nodes using the same function/operation? If yes, no need for separate formats after decision ends... if they use the same operation then they would output the same param, just with different value... and from what I see the format is just changing the way it appears, like using the day name... so it does not matter what value it gets (and is all about value afterall) it will format it regardless...
  14. Why two sets of "Set Schedule Start/End date format" and "Add Notice" nodes?
  15. Not quite, it is actually the opposite ... Most of our customers, while many located having HQ in UK have users located all over the globe. Might be the case that their Hornbill instance is set to a specific timezone but the users will have different one based on where are they located. Regardless, the Cloud Automation would not work. Once you format that date in any shape, it will remain like this until another node re-formats it... The solution, in my view, is to have the date/time formatted in the UI based on the timezone of the user that uses that UI. This allows the system to hold a set date (GMT/UTC) while displaying it differently based on user preference. The solution or workaround would work for your specific requirement here and now since you need that BST conversion for all your users and it will only be feasible in this scenario.
  16. Getting "last Sunday in March" and "last Sunday in October" is not quite possible. The alternative is to check for the specific date. I understand the date for daylight saving is different every year but that's yearly so updating the workflow once a year is not that cumbersome, I think... even so I expect the wiki date format in notices to be implemented soon(ish) so I don't expect a yearly workflow update to go on for too long... Anyway, if one wants to implement this check for BST based on the specific date this can be done as follows: 1. Have a Cloud Automation Utility node to retrieve current timestamp. Like this: Operator param is mandatory so it needs to be set but for our purpose it can have any value, we are not actually adding or subtracting any value here because: 2. All other params will be set to ignore. The Starting Timestamp as ignore will use current date/time and the other values set to ignore means we are not altering this current date/time in any form for the Timestamp output param value. 3. In the workflow continue with a decision node that will check in the value for Timestamp output param (returned by the Cloud Automation node) is less than, let's say 2021-11-01 00:00:00. If yes then it means the current date/time falls within BST, if the value is greater than 2021-11-01 00:00:00 then it means the current date/time falls is outside BST. Example for how the expression looks that checks if the date/time is within BST:
  17. @Gareth Watkins was already reported, we're looking into it. I will close this thread to avoid duplicates please follow and contribute on the existing thread:
  18. @Paul Alexander can you have a look or ask the network guys to check the URLs for the Azure app set for Hornbill service? Perhaps one of those URLs is incorrect and would need an update... I am saying the above based on the troubleshooting document from MS: https://docs.microsoft.com/en-us/troubleshoot/azure/active-directory/error-code-aadsts70001-app-not-found-in-directory
  19. @Paul Alexander looks like you are using Azure as IdP (correct me if I am wrong). If so, do you have an Azure app for Hornbill service portal?
  20. @Berto2002 no idea... I can suggest raising a support request if you need this investigated in more detail...
  21. Hmmm.... how? Is this a recent workflow? We have a check in place that looks for this oversight, preventing publishing for that version... example: EDIT: looking a bit further into this, it seems that is possible to set a mandatory checkpoint as False. In effect it means it will not set that checkpoint, but for the validation mechanism it appears valid as the checkpoint is set somewhere in the stage... hmmm... This aside, if you happen to get this error it will be on the node that progresses the flow to the next stage. Edit the affected running workflow, it should look like this: Edit this node and add the missing checkpoint (for example, Incident Assigned checkpoint): Save changes and restart the workflow.
  • Create New...