Jump to content

SamS

Hornbill Developer
  • Posts

    1,511
  • Joined

  • Last visited

  • Days Won

    25

Posts posted by SamS

  1. Hi @Cristian,

    My GUESS (because I will admit that I ran into this issue the first time I used v4.x) is that you are referencing KeysafeID instead of KeysafeKeyID...

    Please double-check the capitalisation of the letters AND on what level it is in the configuration file. I suggest you compare this with the bundled json file.

    With the KeySafe entry, the Client Secret can be removed from the configuration file.

    The final error suggests there is a typo in the configuration file (my GUESS an extra right-curly brace).

  2. Hi @Met,

    Which "Office Location"/"Site" are you using (in the Data Import Config)? The one mentioned in the "User Account"-section? Or the section within "User Options"?

    It is the latter (User Options) which you need to have configured - I am pretty sure the other one gets ignored.

  3. @DRiley,

    I've had a chat with MS regarding the OData filtering in InTune. In short: they are aware that not all filtering works AND there is no documentation on what specifically does and doesn't work (eg startsWith doesn't appear to work at all, UNLESS you check the full word - in which case "eq" could/should be used. Things might/should change at some stage in the future.

    In the meantime, the best way would be to code the filters within the Runbook - i.e. have a developer implement the following PSEUDO-code:

    if ($Device.model = 'iPhone'){
    	$AssetType = "123";
    } else if ($Device.model = 'iPad' || $Device.make = 'Samsung'){
    	$AssetType = "205";
    } else skip this import

    If the assetClass changes, then some more tinkering will be required.

    • Like 1
  4. Date data within a date field will and should act as a date.

    Date data within a text field will only act as a date if and only if the text matches the datetimestamp format.

    This is clearly not the case and the transformation you are doing on the date as you have received/stored it sets if even further away from the desired (i.e. the DB's datetimestamp) format.

    Any advice to capture date data within a text field will have been to allow you to just STORE the data. The consideration that you might want to REPORT on that data (and specifically use the reporting tool for date-selection on that field; just displaying that data in a report should be fine) might not have crossed the adviser's mind (as that particular requirement might not have been specified).

    With dates captured in text fields, you only really can use that data to look at - not for manipulation.

    As mentioned you might stand a chance by manipulating the date into the DB's datetimestamp or you will have to modify your report to either accept some text input (as opposed to date/time selection) to compare against (given your chosen date format that is unlikely to be fruitful) or not filter on that particular field, ensure the field is visible in the (.csv) results and rely on Excel or such to "deal with"/"recognise" that date-data.

  5. Hi @Ashley,

    I believe you are very close to realising why what you are trying to do isn't working the way you expect.

    You are storing a date (with or without time; that is relatively unimportant at this stage) in a VARCHAR (text) field. This means that the DB doesn't "know" that the data contained is a DATE. The db (and thus the report) will treat that data as text.

    If you are using the report's date selector to fill in the date(s), the report engine will convert that to a DB date before presenting it to the DB which then will compare it (the selected DB date) to your text field.

    The only way this method stands a chance of working would be if the text field is exactly formatted as the DB datetimestamp - that way you are effectively fooling the DB in mistaking your stored text to be a valid DB date. I would not recommend doing this as the "knowledge" that this is hacked will likely be lost at some stage in the future and would be difficult to maintain going forward.

     

  6. @Berto2002,

    A specifc technical point:

    The apostrophe in the children's sample is an actual APOSTROPHE and neither a RIGHT nor LEFT SINGLE QUOTATION MARK - which are visible in the ‘witches hat’ example. In most fonts they can be distinguished by the apostrophe being less fancy/swishy than the left single quotation mark (some fonts use the exact same definition (similar to 1 (one), l (lowercase L) and I (uppercase i) being similar in some font-sets)) - similarly the backtick/accent-grave matches the right single quotation mark.

    As @Steve Gillermentioned, some word processors automate the use of those quotation marks - i.e. when you press the apostrophe button on your keyboard it "decides" which quotation mark to use. Just type (don't copy-paste) 'D and on another line D' in MS Word - you will see the difference. And, somewhat naturally, those UTF-8 characters are copied along when someone copies and pastes.

    IF you were to switch/force the encoding of the .csv file to UTF-8, then the characters should show the way you expect to see them.

    I would venture that whatever you are using to view the .csv file is treating that .csv file as a ASCII file (or in the very least an 8-bit character encoding). Enhanced text editors (eg Notepad++) allow one to set the character encoding in which the text can be viewed (in Notepad++ you will find this under a menu called "Encoding"). Force this to UTF-8 and the data should be visible as expected.

  7. @DRiley & @Steve Giller,

    That backtick should remain in the PowerShell script as it escapes the dollar-sign. The dollar-sign is used in PowerShell to ring in variables, so the backtick prevents that behaviour.

    One thing of note in your query is that the "startsWith" syntax usage should be: startswith(model, 'iPhone')

    When it comes to testing, I've found MS Graph Explorer to be handy (one would leave out the backtick here), but I've struggled to get the filters working as well - including trying it in beta and adding an extra request header () which was suggested in an article.

    As the filtering is Microsoft API, your query should really be directed there.

    The alternative (if MS can't explain why the filtering doesn't work) would be to leave out the filter and deal with the filtering in the PowerShell code.

  8. Hi @Ann,

    Following from @Steve Giller suggestion:

    Most APIs used to create some entity (be it a task, request or whatever), tend to respond with a (unique) reference (ID) to the entity created (or an error message if it goes wrong). Our API works exactly the same way, specifically returning projectTaskId (if all went well). I would imagine that "MS Project Online"'s API works in a similar way.

    IF you are worried that tasks are lost (in whichever direction), then I would build in some logging that captures the responses of the APIs (i.e. ideally the ID, but possible error messages as well). Within Hornbill BP the trick would be to output the responses to a timeline somewhere (eg dedicated workspace; Hornbil Collaboration-section in iBridge/Cloud-Automation).

  9. Hi @Jack_Podmore,

    Why would your tenant be involved to allow acccess to your supplier?

    I would set up an additional SSO Profile linking to your supplier's Azure tenant.

    Your users (internal as well as supplier's) will then need to select the correct SSO Profile (eg "Interal" vs "ERP Supplier") from a drop-down before clicking-in.

    IF you can somehow link (eg via trust) their tenant to your tenant, there might be a way to set this up such that the supplier's users are to be authenticated by your tenant. I don't know whether that is possible - though.

  10. Hi @AlexOnTheHill,

    The attached should be bit closer to what you want/need(*).

    You might need to extend the report based on the amount of levels your categories go - h_sys_profiles__5 would be added in the same way that 2, 3 and 4 were added (i.e. linking with the preceding addition).

    (*) i.e. the code which was is NOT used should be the right-most non-"Closure,2" code mentioned. It is not ideal, as you will need to "interpret" each line the report returns (i.e. remove the end closure,2 columns and the preceding columns).

     

    unused-closure-categories-3-levels.report.txt

    • Like 2
  11. Hi @CraigP,

    Thank you for finding the additional operation - it was coded slightly differently so it didn't make the list I compiled earlier. The wiki page has been updated (and I checked whether other endpoints were coded in the same way to this one - there weren't.

    As for the Security Error you highlight - could you please confirm that the account which you generated API key for indeed has access to update the call via the UI?

×
×
  • Create New...