Jump to content

DanielRi

Hornbill Product Specialists
  • Content Count

    232
  • Joined

  • Last visited

  • Days Won

    18

DanielRi last won the day on March 23 2018

DanielRi had the most liked content!

Community Reputation

64 Excellent

About DanielRi

  • Rank
    Product Specialist

Profile Information

  • Gender
    Male

Recent Profile Visitors

2,093 profile views
  1. Hi Mark, just to conclude this thread, I can confirm that there an issue existed which prevented reports from being downloaded via the interface in Hornbill Administration. I believe the issue would prevent some users from downloading the report altogether, but with others the error would only manifest itself when trying to open the report following the download. I can confirm that the fix was pushed to live this morning in Hornbill Administration build 1266. If you continue to experience this issue please let us know by posting back. Thanks, Dan
  2. Hi Mark, thanks for your post. Where are you downloading the report from to get this error, is it in Hornbill Administration or elsewhere? Thanks, Dan
  3. Hi Stephen, thanks for your post. Assets (stored in h_cmdb_assets) are linked to requests (stored in h_itsm_requests) via a link table (h_cmdb_links) so we'll be working with these three tables. If you inspect h_cmdb_links, this table contains several columns, two of which are storing the objects being linked. This may be an asset, request, or service for example. Rather than a pure ID, you'll notice that the objects are referenced by what we call a Uniform Resource Name (URN) e.g. urn:sys:entity:com.hornbill.servicemanager:Asset:h_pk_asset_id. I won't got into the details as to why that is, but you'll see this standard used in various places throughout our applications. While a URN maybe great for technical purposes, it does make reporting a bit more interesting, especially when there isn't a corresponding URN to make an obvious table join. You'll find that every request has a URN stored in h_itsm_requests.h_social_object_ref, which means joining h_cmdb_links with h_itsm_requests is easy, but we also need to join h_cmdb_links to h_cmdb_assets....and there isn't a URN stored for an asset in h_cmdb_assets... This situation calls for the SQL "CONCAT" function. This allows us to concatenate two values into one single value which we can use to serve our needs i.e. make the necessary JOIN between the link table and asset table. In this case we would be constructing the value using the combination of a string of text (urn:sys:entity:com.hornbill.servicemanager:Asset:), and the value of a database column (h_cmdb_assets.h_pk_asset_id). So when using the function CONCAT('urn:sys:entity:com.hornbill.servicemanager:Asset:',h_cmdb_assets.h_pk_asset_id) the output would equate to a value such as "urn:sys:entity:com.hornbill.servicemanager:Asset:assetID" which is equivalent to what is stored in one of the link columns in h_cmdb_links. This can be used in the manner shown below, by joining the tables using some custom criteria. I've also uploaded a report definition so you can examine it for yourself. I hope that helps! Dan assets-with-active-requests.report.txt
  4. Hi Ann, thanks for your post. As you'll have found out, the task assignee (h_assigned_to) in h_sys_tasks actually stores a "Uniform Resource Name". I'm not au fait with the motivations for using this standard but I imagine it'll relate to the fact that a task assignee can be one of several things; a user, a group, or even a role. This means that the system has to understand more about the assignee because it needs to know whether it's resolving a user, group, or role when presented in the user interface - information that can't be gained from a simple ID alone. Anyway, that might be interesting to some, but given this situation how do we get a more user-friendly output for the assignee considering that there isn't a corresponding URN value stored in h_sys_accounts, or an alternative value in h_sys_tasks which can be used for our JOIN? When faced with this, I turn to the SQL "CONCAT" function. This allows us to concatenate two values into one single value which we can use to serve our needs i.e. make the necessary JOIN. In this case we would be constructing the value using the combination of a string of text (urn:sys:user:), and the value of a database column (h_sys_accounts.h_sys_user_id). So when using the function CONCAT('urn:sys:user:',h_sys_accounts.h_user_id) the output would equate to a value such as "urn:sys:user:userID" which is equivalent to what is stored in h_assigned_to. This function would be used as shown in the image. Essentially we're saying; join the records in h_sys_tasks when h_sys_tasks.h_assigned_to equals a concatenation of the string urn:sys:user: and the user ID found in h_sys_accounts. I've uploaded an example report definition too. I hope that helps! Dan tasks---active-tasks-per-assignee.report.txt
  5. Hi Malcolm, hope you're well. I've edited the post to conceal the company specific information that was in there and removed the attachment for the same reasons, you can never be too careful! Looking at the bounce-back, the reason its given is because the email address " system.administrator@hornbill.com" doesn't exist. This means one of the recipients has this email address specified in their use account: The user account in question will be the "Admin" user, which has this email address set as default, and the reason why its trying to send the notification to this email address is because the admin user will be part of the team, quite common when we've been testing/configuring things. This can be addressed by one of the following: 1) Disable assignment for the "admin" user for the team in question. Assignment options for team members can be managed via Hornbill Administration > Applications > Hornbill Service Manager > Configuration > Service Desk https://wiki.hornbill.com/index.php/Service_Desk_Administration 2) Remove the "admin" user from the team in question. this can be done via the Organisation Structure in Hornbill Administration > System > Organisational Structure https://wiki.hornbill.com/index.php/Organisation (see the section "Removing Users from a Group") 3) Change the email address of the "admin" account to a valid email address I hope that helps, Dan
  6. Hi James, as Trevor says, for live chat to be available to your basic users, each basic user must have the "Portal Chat Session User" role assigned to them. The method he describes will allow you to quickly add this to all your existing basic users now. Longer term, you may wish to consider including this role in any user import involved in managing your basic user accounts. Dan
  7. Hi Adrian, thanks for your post. This is expected behaviour as there are indeed posts that haven't been read by the owner (in this case the owner is "No Owner"). Once an owner is assigned, and has reads the posts, the request will be considered read and so the light yellow colour will disappear. The unread colour can be change in the following Service Manager setting: webapp.view.ITSM.serviceDesk.requests.list.unreadColour I hope that helps, Dan
  8. Hi Izu, thanks for your post. To get the the root of this issue it's worth revisiting how the asset import utility operates (the same principle can actually be applied across the range of Hornbill's data import utilities). If the utility recognises a record already exists in Hornbill, it will update that record. If the utility determines that a record does not exist, it will create a new record. So the focus of the investigation should be on what the utility uses to determine if a record already exists in Hornbill or not. Considering the database asset import specifically, this is achieved through the "Asset identifier" configuration that exists for each asset type you define in your conf.json file. This involves specifying a "DBColumn", "Entity", and "EntityColumn" which can be described as follows: DBColumn - the unique column that exists in your data source (i.e. where the records are being imported from) and is included in the database query Entity - the Hornbill entity where data is stored. Now this one is a bit Hornbilly. Basically its a round about way of referring to the table where the unique column exists in Hornbill. EntityColumn - specifies the unique identifier column from the Hornbill entity - i.e. the actual column name that exists in the Hornbill table - lets call it the "Hornbill identifier column" Below is an example from our wiki showing the configuration of the asset identifier for records being imported as Laptop-type assets (https://wiki.hornbill.com/index.php/Database_Asset_Import) { "AssetType": "Laptop", "Query": "xxxxxxxxxxxxxxx", "AssetIdentifier": { "DBColumn": "MachineName", "Entity": "Asset", "EntityColumn": "h_name" } }, I appreciate that the concept of an entity is something that is explained very often and can be the most common stumbling block if you're new to Hornbill. Here are the guidelines to follow when doing an asset import: If the unique Hornbill identifier column (EntityColumn) you're using exists in the table h_cmdb_assets, then the Entity will be "Assets" If the unique Hornbill identifier column exists in the table h_cmdb_assets_computer, then the Entity will be "AssetsComputer" If the unique Hornbill identifier column exists in the table h_cmdb_assets_computer_peripheral then the Entity will be "AssetsComputerPeripheral" If the unique Hornbill identifier column exists in the table h_cmdb_assets_mobile_device then the Entity will be "AssetsMobileDevice" If the unique Hornbill identifier column exists in the table h_cmdb_assets_network_device then the Entity will be "AssetsNetworkDevice" If the unique Hornbill identifier column exists in the table h_cmdb_assets_printer then the Entity will be "AssetsPrinter" If the unique Hornbill identifier column exists in the table h_cmdb_assets_software then the Entity will be "AssetsSoftware" If the unique Hornbill identifier column exists in the table h_cmdb_assets_telecoms then the Entity will be "AssetsTelecoms" So, assuming the entity and Hornbill identifier column are specified correctly, if new records are still being created unexpectedly, I'd check the value contained in your unique DB column in your source data. perhaps this has changed and therefore no longer matches any record previously imported. I hope that helps, Dan
  9. For the benefit of the broader community and to conclude this thread, this error can be caused when the userID referencing the manager of the Co-worker contains non-alphanumeric characters i.e. this error is not necessarily representative of an issue with the userID of this Co-worker, but the userID stored in the column h_manager in the user profile (table: h_sys_user_profiles). When a Co-Worker Profile is loaded, it tries to retrieve the manager handle (full name) so it can display it in the profile you're viewing. It does this based on the ID stored in the column h_manager which exists in the table h_sys_user_profiles (the table which stores all the user profile properties such as personal interests and qualifications). If you're receiving this error, its likely due to some incorrect configuration in the LDAP user import (https://wiki.hornbill.com/index.php/LDAP_User_Import) relating to the manager lookup, specifically that a "Manager Regex" has not been specified. The standard manager reqex which satisfies the majority of situations is CN=(.*?)(?:,[A-Z]+=|$) , ensure this is set in the Manager lookup section of the appropriate user import configuration.
  10. Thanks for the clarification. I'm not entirely convinced (yet) that the "Failed to Create User..." error is related to the failure to set the account status. I believe that where the utility is concerned, the creation of the user account and the setting of the status are separate actions (If you inspect the userCreate method call, account status does not feature in its inputs - https://api.hornbill.com/docs/admin/?op=userCreate). First the utility will create the account via "userCreate", and then make additional method calls (such as userProfileSet, userSetAccountStatus, etc,) to complete the exercise. The question is, is it trying the "userCreate" blindly, rather than checking for an existing user id first, and then moving onto the additional calls after as normal, or not bothering with the additional calls at all? Anyway, that aspect may be worth raising with Hornbill Support but before heading in that direction, are you able to confirm the version of the utility you're currently using? A few bells began to ring while typing the above (but now I've written it I'll leave it be ), and just checking the release notes I can see that prior to version 3.03, the user account status section was completely ignored when processing a user account. Versions of 3.03 or later have the fix. Thanks, Dan
  11. I'm not sure I fully understand the reference to "Pre-load", but before we talk about that, are you able to confirm whether the user "taxxxxx.xxxxxkh" exists in Hornbill, along with the accounts current status?
  12. Due to how the imports operate, there will be users created on the first run of this configuration. This means that we need to cover for that scenario and ensure the status is set on creation of a user (as well as on update of any existing user). Upon creation of a user, I believe the default status will be "active".
  13. Hi Martyn, thanks for your post. In relation to the two points you mention: 1) The utility tries to create the user if it did not already exists, i.e. was disabled many years ago. This is one of the principles that all of Hornbill's user import tools operate on. If the import does not find a matching user id, it believes the user does not exist and so will create it. Therefore, with an import configuration intended to manage the archiving of users, there will be a certain amount of redundant accounts imported the first time it's run. Perhaps there's an opportunity to refine your LDAP filter criteria to only focus on more recently disabled user objects? 2) Fails to update existing user to archived as currently active. Error: "User already exists with account status: active" I would double check that the status is indeed set to "archived" and ensure the action is set to "Create and Update". On a general note, is there a reason why you maintain disabled user objects in your AD long term? I hope that helps. Dan
  14. The defect described in this thread was resolved and the fix contained in Service Manager build 1392 which was released to live on November 29th. Detail: Catalog item not visible to a Co-Worker when their team is excluded but the user is included.
  15. Hi Dan, I've encountered the need to set a "due date" on several occasions during my work with customers. Essentially the need to set a target based on a specific event that is influencing the delivery of the work (e.g. end of the financial year, an audit deadline, or a new member of staff starting) - which is what I would understand as being "fluid" in your description i.e. the due date could be quite a strict deadline (unlikely to move) but the factor influencing the deadline can variable for each piece of work. The immediate benefit of such a feature would allow easy sorting of the request list but in terms of the performance and service delivery improvement I'd be interested to know what type of reports or metrics would be useful to you in relation to a "due date". At the very least I would expect there is a need to compare the time at which the request was "marked" with the due date target, and then set a 1 or 0 accordingly - representing whether this was marked within the due date, or exceeded the due date. Would you be able to elaborate further in this area, or is the need essentially the same as reporting on Service-Level-based targets? I'd also speculate that there should be restrictions when it comes to editing any existing due date on a request. Who is involved in managing and setting of due dates in your scenario? The concept of a due date is already under discussion by the Product team and I understand you may already have contributed in some conversations but it would be great to hear a few thoughts on the latter points RE: reporting and governance around amending a due date. Thanks, Dan
×
×
  • Create New...