Jump to content

Steve G

Hornbill Developer
  • Posts

    746
  • Joined

  • Last visited

  • Days Won

    30

Everything posted by Steve G

  1. Hi @Giuseppe Iannacone, Are you building and sending API calls from Jira back into Hornbill? If so, which Jira app are you using to implement this? From your error message, it appears that you're using a JSON payload, which is not officially supported by Hornbill (yet). It works, but the JSON schema description is liable to change - as it did in the most recent release of the Hornbill platform. So I expect you are sending something like the following (from Gerry's XML example above): { "methodCall": { "@service": "session", "@method": "userLogon", "params": { "userId": "admin", "password": "cGFzc3dvcmQ=" } } } When now you should be sending: { "@service": "session", "@method": "getSessionDetails", "params": { "userId": "admin", "password": "cGFzc3dvcmQ=" } } Note the lack of methodCall property in the second snippet. Cheers, Steve
  2. Hi @Rob Gething, The new automation operations are now available: Let me know how you get on. Cheers, Steve
  3. Hi @Rob Gething, Looks like TextAnywhere have deprecated & removed the API endpoint we were using, and have replaced it with a more modern API. We'll get our operations updated to reflect their changes, and will report back here once done. I'll also make sure the other operation that you have requested is added while we're at it. Cheers, Steve
  4. Hi @Stephen.whittle, We're in the process of reviewing chatbots to integrate with, and are currently looking at: IBM Watson Assitant Microsoft Power Virtual Agent Google Diaglogflow Thanks, Steve
  5. @Martyn Houghton It's still in beta I'm afraid: https://docs.microsoft.com/en-us/graph/api/driveitem-createlink?view=graph-rest-beta&tabs=csharp Cheers, Steve
  6. @Martyn Houghton That's a good question - they actually still reside in the audit trail table, and in fact more records are created to log the fact that the record was deleted. I'll have a look at the possibility of adding an option to remove the audit trail records once the entity record delete has been performed. Will let you know how I get on. Cheers, Steve
  7. @QEHNick as per the docs, it's actually the Microsoft UPN of the target Teams user: Cheers, Steve
  8. @QEHNick Chat ID is the ID of the 1-2-1 chat session with a user. This operation is used to send messages to private chat sessions rather than group channels. Private chat sessions can be created with the Chat > Create Chat operation, which outputs an ID that you can use in the Chat > Send Message operation (below). If a one to one chat already exists between the account that the Teams integration is using, and the target user, the Chat ID of the existing chat will be returned. Hope this helps, Steve
  9. Hi @Adrian Simpkins, Now I understand the requirements a bit better, you could actually perform this prior to the new operation. The Invite User operation has an output called Invited User ID. You can feed the content of that output into the Get User operation, which will then return all the relevant information about the invited user (including the Azure-generated UPN): Cheers, Steve
  10. Hi @Adrian Simpkins, Had a few spare mins so added a new operation that will return the details of an Azure user object for a given email address (with an optional accountEnabled property value). Let me know if this helps. Cheers, Steve
  11. Hi @Adrian Simpkins, Are these email addresses already in Azure? If so, we could provide a new Azure operation that will allow you to provide the email address to return a users details (which will include UPN etc). Would that work for you, rather than attempting to chop & change the users inputted email address? Cheers, Steve
  12. @Giuseppe Iannacone, The Request Type and Service Desk fields are select lists, that will dynamically pull information from your Jira Service Management Cloud account when you click on the down arrow to the right of the input. Summary is as you would expect Cheers, Steve
  13. Hi @Paul Alexander, The config is correct, I've just run it against my SCCM database twice (once for create, then one to test for dupes), and I'm getting no duplicates in the 500 records I have that match your clauses: Wondering if there's a whitespace issue in play in your data. Might be worth trimming the column in your query to remove any leading or trailing whitepace characters, just to be sure: SQL Server 2017 onwards: TRIM(dbo.v_GS_PC_BIOS.SerialNumber0) AS [SystemSerialNumber] Other versions: LTRIM(RTRIM(dbo.v_GS_PC_BIOS.SerialNumber0)) AS [SystemSerialNumber] Hope this helps, Steve
  14. Hi @Paul Alexander, If memory serves, this was a data issue rather than defect in the tool - a number of records in the SCCM dataset had no serial number so matching Hornbill asset records could not be found. If you could check that first, and if you're still seeing duplicates then feel free to post your config here (minus any API keys, passwords etc) and I'll cast my eye over it. Cheers, Steve
  15. @Martyn Houghton Thanks for confirming it was a data issue, glad you worked around it with TRIM(). I'll trim whitespace from date fields when parsing in the code for the next release so we're not caught out by this again! Cheers, Steve
  16. Hi @Martyn Houghton, I'll take a look at that this morning, these were imported with the correct date using v1.10.0 last week prior to release, so I'm wondering if there's an issue with the parsing. I presume the dates provided for your fields are all in the same format? Thanks, Steve
  17. Hi @Martyn Houghton, v1.11.0 is a pre-release - it has dependencies on the build of Service Manager which is due for release at some point this week. As soon as Service Manager is in live, we will release 1.11.0. I'll have a look at the code that checks the release version, as that should not include pre-release builds. Cheers, Steve
  18. @Martyn Houghton Also, re: This seems like a bug, or oversight. Please post this into the Service Manager forum and that development team will review. Thanks, Steve
  19. @Martyn Houghton Yes, there's a managed relationship between the Requests and PublishedRequests entities, so if a request record is deleted, then so will any published records associated to the request. Cheers, Steve
  20. @Martyn Houghton No, it was processing h_last_updated against the extended details table(s) for Problems and Known Errors, but published requests are stored in their own table, and it was those that needed updating. I've added support for that in v1.10.0, on GitHub: https://github.com/hornbill/goHornbillRequestImport/releases/tag/v1.10.0 Take a look at the LastUpdated property of the PublishedMapping object. Cheers, Steve
  21. @Martyn Houghton, Looks like the Customer Portal is indeed showing the Last Updated date for the published known issue rather than the published date. I'll add in support to set that field too. The last updated field in the additional field mapping sets that field in the extended attributes of the request rather than in the published requests table. Cheers, Steve
  22. @Martyn Houghton Actually, it's v1.9.1 you need, as I'd missed off the date parsing from the new published requests feature. It's in there now: https://github.com/hornbill/goHornbillRequestImport/releases/tag/v1.9.1 Cheers, Steve
  23. @Martyn Houghton We've just released v1.9.0 of the tool, which includes the ability to publish problems & known errors, fixed the datetime parsing issue for extended properties, and added the owner mapping ability too. It's on GitHub now, the wiki docs will be updated shortly. https://github.com/hornbill/goHornbillRequestImport/releases/tag/v1.9.0 Cheers, Steve
  24. Hi @Martyn Houghton, No that wouldn't work I'm afraid. It should be a very small change that's required to the tool though, will take a look tomorrow and hopefully get a release out then. Cheers, Steve
  25. @Martyn Houghton I don't think there is currently, I'll have a look and get back to you... Cheers, Steve
×
×
  • Create New...