Hornbill Staff DR

Hi John,  thanks for your post. In the Employee Portal configuration there is one field where you can specify the height of the background image area, and another where you specify the size of the logo. The height of the background image does have a minimum height requirement of 170px, however the logo can be set to 70px as you require. This is set in the field to the right of the image URL for your logo.  In relation to the logo positioning, this now is located in front of the main background image and, as it stands, this isn't configurable. The only thing I could suggest here is modifying/changing the background image to increase the contrast with the logo. Dan

@Alberto M "what about a new setting in Hornbill admin where we can set the visibility level that generates the notification?" Indeed, that's the proposal. We already have the ability to do this, but would be looking for an additional item to be able to set the value to something which would be visible to followers, but remain hidden from customers.  I'll post back once I have an update, Dan

@Alberto M thanks for confirming, I've also observed the same behaviour. The reason being is that the notifications you're entitled to see when following a timeline have no bearing on team membership. Let me try and provide some background. Timelines and following Timelines and the "following" of a timeline are concepts which are part of the Core of the Hornbill Platform, it's not a feature developed solely for Hornbill Service Manager or any other application in particular. Documents, Workspaces, Requests, and Assets all have timelines associated with them, but this functionality (and the concept of following) is intended to be application agnostic. Aside from the terminology (Customer, Team, Owner, etc) used to denote a visibility level, there is nothing application-specific about timelines, or the concept of "following" a timeline. Timeline Visibility Every timeline post possesses a visibility level. In the database this is a number, (either 1, 10, 20, 30, 35, 40, 50, or 100). To you and me, each score is represented by a label (e.g. "Customer", "Team", etc.) and this is the only element that an application has control of i.e. how each value is displayed to the user. You'll notice that some applications, such as Document Manager, don't even indicate the visibility level on their timeline posts. For Service Manager, the current visibility levels which are exposed are: Public = 1 Customer = 10 Team = 30 Owner = 35 Manager = 40 (You'll notice that there are more visibility levels defined by in the platform API documentation https://api.hornbill.com/_types/activityVisibilityType, and that the text references differ to those employed by Service Manager) You can see the above visibility levels listed when defining the default visibility in the application settings prefixed: "guest.ui.app.com.hornbill.servicemanager.operation.defaultVisibility". In reality, the ones that are relevant are "Customer" and "Team". I can't think of a scenario where I've needed to suggest using any other. Visibility Entitlement So, as a user, what dictates my entitlement to see posts with a specific visibility level? This is down to the specific functionality and whatever logic exists to decide which timeline posts you should be exposed to. For example, when viewing a request, the application (Service Manager) will query the user to understand if they are a member of the team to which a request is assigned. If the user is a member of that team, the application will retrieve all posts with a visibility level of 30 or less (that might not be a comprehensive description of the logic, but hopefully that gives you the idea) This is functionality defined by Service Manager and thus adheres to the principles required by that application. However, in terms of following, this functionality exists at the platforms core and the logic and principles operate differently. The roots of that may be due to its need to remain application agnostic. "Following" has no notion of group membership when determining how notifications are distributed. Currently, "following" a timeline entitles a user to see timeline posts with a visibility level of 20, or less. This is why you can see posts with a visibility of "customer" (value = 10), but not posts with a visibility of team (value = 30) when you are following a timeline. Possible Solution The solution might be to expose the visibility level of "Following" in Hornbill Administration and also on the request actions. This would allow you to set a default visibility for timeline posts, and allow users to select that visibility when posting things via the request actions. Posts with a visibility of "following" have a value of 20 and as stated a moment ago, "following" a timeline entitles a user to see timeline posts with a visibility level of 20, or less. Posts with a visibility level of "Team" still won't be available when a timeline is followed. I've asked development and product team to review this suggestion for it's feasibility and that it doesn't conflict with any existing functionality. Dan

@RIchard Hortonthanks for your post. Indeed, the connection would be that in each scenario the "Description" field and "Resolution" field of a request currently aren't fed anything other than plain text. Just to provide a brief background on the tag you've highlighted. The "cid:" tag, as its known, is an email standard used to reference in-line images within an email message. Email clients have to package an email to make it suitable for transport, one part of this process is to replace each in-line image with a cid: tag which ensures that when the recipient comes to open the message, the email client knows exactly where to unpackage the image and display it within the text. So the cid: tag is actually content which is being lifted from the email. Until the situation changes with regards to in-line image attachments in the request description and timeline, I personally find the existence of a cid useful as it tells me that there's an image associated with the text and I can view the source email to see the detail. However, I can appreciate the point on aesthetics. Dan ÂÂ

Hi Andy, if the failure is due to the conditions within the branches i.e. a "No matching GoTo If" error, this can be fixed via the Manage Executed Processes screen. However, the error you've posted isn't a "No Matching GoTo If". The first thing that needs to be done is identify why its failed. The screen shot also looks a little odd in that you have two inbound arrows to that decision node (which isn't possible) and the nodes upstream seem identical. This looks like a rendering issue with the Managed Executed Process canvas. As you have a Premier Support plan, I recommend raising this with our application support team so they can look at this further. Thanks, Dan

Hi @Alberto M  thanks for your post. As your second comment speculates, this situation is not related to who makes the post. i.e. the situation you have observed is not due to the posts being made by the System Autoresponder user. The notifications will adhere to the visibility level associated with a timeline post i.e. Customer, Team, Owner, etc. It may be that the expectations on how this should work, are different to what the functionality is actually allowing. So lets explore further. From the post above, it appears that you are looking for analysts to receive notifications on requests that belong to a different team i.e. a team which they don't belong? Is that correct? I'll word it another way to ensure I've understood. The requirement is that Analysts from one team want to follow and get updates on requests assigned to another team which they are not a member of. If you can clarify my understanding of your requirement, I'll then endeavour to explain how the notification mechanism works in relation to following a timeline. Dan

The fix for the validation issue which prevents saving of changes to an existing SSO profile will be available in platform build 3381 and above.

@RIaz Ashruf,  further to my above post, we've identified an issue with the validation when saving changes to an existing SSO Profile. It appears to erroneously conclude that the entityID already exists, even if you only have one SSO Profile configured, almost as if it's validating against itself when you hit the save button. I think the situation reported in your original post were a result of further configuration you'd made to try and overcome the issue, which meant I made some incorrect assumptions. I can confirm that development are on the case to correct the validation logic and will release a fix in due course. The current workaround, as we performed together, is to delete the SSO Profile and create a completely new one as the validation logic performed on creation is working as expected, its just updating existing profiles where we have this problem. Dan

Hi Riaz,  it was great to speak with you this morning and assist with the above. I'll summarise some key configuration for the benefit of others who may come across this thread. In the context of a SSO Profile in Hornbill, the entityID contains the URL related to your identity provider (IDP), e.g. ADFS, where users are sent for authentication. In theory, we should never have to know the value for entityID because it's contained in the metadata (generated from the configuration in the IDP) which is uploaded into the Hornbill SSO profile to populate the required fields. The reason why the SSO Profile may not have saved is because another SSO Profile already existed with that EntityID specified. Only one Hornbill SSO profile is required per identity provider. When updating new certificate information, the new metadata should be uploaded into an existing SSO Profile. In this situation, you will see the new certificate appended in the certificates section and be able to save these changes. Dan

The ITOM preview presentation is available in the thread below and is accompanied by the link to register for the ITOM Technical Preview: Exciting times! ÂÂ

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

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

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

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

Hi Andy,  if the log On Account for the EspSisService (the workaround to the impersonation issue mentioned previously) is still configured, then you shouldn't need to specify the Admin or RunAs Context to be set when configuring the IT Automation node. I believe the impersonation issue is something that development still need to get to the bottom of. Thanks, Dan

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

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

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

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 ÂÂ

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.ÂÂ

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

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? ÂÂ

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".

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

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.