Jump to content

DanielRi

Hornbill Product Specialists
  • Posts

    271
  • Joined

  • Last visited

  • Days Won

    19

DanielRi last won the day on October 13

DanielRi had the most liked content!

Profile Information

  • Gender
    Male

Recent Profile Visitors

2,594 profile views

DanielRi's Achievements

Community Regular

Community Regular (8/14)

  • First Post
  • Collaborator
  • Conversation Starter
  • Week One Done
  • One Month Later

Recent Badges

72

Reputation

  1. Hi IT Specialist, thanks for your post. Hornbill User accounts are archived by setting the user "Status" to a value of "Archived". User accounts with a status of "Archived" will not shown in any user search or other user-related lists or menus. Changing the status of an individual user account The status of a Hornbill user account can be changed via Hornbill Administration > System > Users & Guest Access > Users. Find the account in question and click to view the details. The status field can be found in the location shown: The desired value can be selected from the drop down menu. Using an LDAP Import Configuration to update the status of a Hornbill User Account If you are importing and managing your Hornbill User Accounts based on the contents of your active directory, its possible to update the Hornbill User Account status via an LDAP import configuration. It will be necessary to create a new LDAP Import configuration specifically for this purpose. This is done in Hornbill Administration > System > Data > Data Import Configurations The documentation relating to LDAP import configurations can be found here: https://wiki.hornbill.com/index.php?title=LDAP_User_Import The key information which should be considered is: It will be necessary to define a DSN and LDAP filter query to identify the user objects which must have their corresponding Hornbill user account status set to "Archived". In the User Options tab, the "Status" should be enabled ("Update Only" is typical but this will depend on what other LDAP imports are operating). The value should be set to "Archived". All other User Options can be set to "No Action". I'd suggest taking time to digest the LDAP Import wiki page, particularly the "Testing Overview" section. Should you prefer, if your organisation has a Success Plan you may have available credits which you could could draw upon and have one-to-one guidance from a Product Specialist. Alternatively, Hornbill Expert Services could also be procured. I hope that helps, Dan
  2. Hi @samwoo, glad to hear that's resolved it! I'll feed our thoughts back to the Product Team to see if the options can be adjusted to make the requirement for a "From Status" more obvious. Dan
  3. Hi Samuel, thanks for your post. Whenever I use the suspend wait for status change node I always set a "From Status". This is something I've always done but I do acknowledge that the "From Status" is not mandatory, maybe that's a question for the Product Team. Have you tried setting this? Looking at your design, I assume that at the point it suspends the request will be have a status of "open" in which case this is what you should specify as your "From Status". On a side note, I assume the status of the request is a relevant factor in your process design? If you're just waiting for an expiry time there is a specific node for that called "Await Expiry". I hope that helps, Dan
  4. Hi @RobW thanks for posting. Hornbill Business Process features user-related operations, on of which can Archive a Hornbill user account. An archived user doesn't consume a subscription so in essence setting a Hornbill user account to a state of "Archived" will release the Hornbill Subscription automatically. The operation I'm talking about can be found in a typical Hornbill Automation node as follows: The "User ID" would be the Hornbill User ID of the leaver and could be fed from a variable. The exact variable will depend on where the leaver information is stored against the request or if it was captured in a progressive capture form when logging the leaver request. This is one operation that I've previously advised and worked with customers to implement. With the Hornbill ITOM module it's also possible to manage AD user objects and AD groups through the Windows Account Management Packages available with Hornbill ITOM https://wiki.hornbill.com/index.php?title=ITOM_Package_Library I hope the Archive Hornbill User account operation can offer some value but there's definitely opportunity for further automation in a leaver process. Thanks Dan
  5. @Josh Bridgens great, I think this should be enough for development to go on so I'll leave it in @ArmandoDM 's capable hands! Dan
  6. thanks @Josh Bridgens that's useful info, I've just removed the attachment for security reasons, just in case it contains anything sensitive. Based on the console error it looks like something around FAQ's. Dan
  7. @Josh Bridgens please could you also confirm what self-service interface your users access? We can identify this if you can provide the URL. Thanks, Dan
  8. Hi @Josh Bridgens can I ask you to inspect the browser console when you click into the service. Depending on the root of the problem, something may be shown here in the form of a red error. The browser console can be opened by pressing F12, and then click on the tab labelled "console". Once you've selected this proceed to click the service in My Services (which should take you to your available catalog items) and see if anything appears. The image shows how this appears in Chrome but other browsers have a slightly different interface, however the principle is still the same. Thanks, Dan
  9. Hi @Stephen.whittle, thanks for your post. I've had a look into this requirement and it isn't possible to get the output you need. To achieve this, the measure interface would need to allow us to obtain the average of a calculated value because the age of a request isn't something that's stored in the database. Storing such a value wouldn't be the done thing as age is a situation that changes as time passes and would be obtained by calculating the difference between the date the request was logged and now (the time that the report was run or the measure was sampled). If you're exporting data out of Hornbill you can use the following query to get what you need: SELECT ROUND(AVG(DATEDIFF(NOW(), h_itsm_requests.h_datelogged)),1) AS Average_Days_Open FROM h_itsm_requests WHERE h_status NOT IN("status.resolved", "status.closed", "status.cancelled") You can add criteria to the WHERE clause to get the average age of whatever set of requests you're interested in. The ROUND function is simply there to ensure the result is to a reasonable number of decimal places. What we CAN achieve through a measure in Hornbill is a count of requests that are older than a certain number of days. Not exactly what you want but could be used to give an indication of improvement if the number of requests older than a certain number of months was decreasing. I'd set this number of months to the threshold that is unacceptable i.e. if you believe that the current state of your Service Delivery operations should mean that there should be no requests older than 3 months, then lets count how many requests are older than three months. The target would be to reduce the number of requests older than three months down to zero (or as close to zero as possible). Now, I'm not saying this is a perfect substitute for monitoring the average age and therefore I've fed back the requirement to the Product Owner. While COUNTS are quite rudimentary, they still offer value in that they still allow you see some change and thus contribute to monitoring whether a situation is improving or not. So, to create a measure that will sample the "No. of tickets older than 90 days" would be as follows: Here's the WHERE clause for this COUNT: h_datelogged < DATE_SUB(CURDATE(), INTERVAL 90 DAY) AND h_status NOT IN ('status.resolved', 'status.closed', 'status.cancelled') Other points to note are that the date ranging columns are empty, and I've specified some saved data columns. The reason the date ranges are empty is because for the purposes of this measure we don't want to group the request records by any date value. i.e. it doesn't matter when the request was logged or resolved or closed. What we want is a snapshot of the number of active requests that are older than 90 days. I use the word "snapshot" because this situation will only be true at the point the sample is taken. It's worth noting that this configuration of measure can't be sampled retrospectively in that you can't go back and determine how many requests were older than 90 days at this time last month because the sample is taking a picture of what the data looks like at that point in time. You'll notice that when you resample this measure for the first time, all the samples will be the same, I recommend setting the sample history to 1 the first time you do this. Once it's sampled, increase the sample history to a more appropriate amount and then let sample data build up naturally as per the frequency you're set (daily/weekly/monthly/whatever). The saved data columns are useful when putting this measure in a widget as they'll show how many request are older than 90 days for each priority, team, or whatever saved data column you add. I'd use a chart-type widget set with a data type of "measure Samples group by". I hope that helps, I appreciate that it's probably not exactly what you were after but may go someway to supporting the insight you're trying to gain into your requests. Dan
  10. Hi All, since I posted my original explanation above (which included details on how to join the table h_cmdb_links with h_cmdb_assets using a SQL CONCAT function) there has been a change to h_cmdb_assets to include a column to hold the asset URN. This is called h_asset_urn. This makes writing the above report much easier in that we can just select the columns from each table, without needing to use the CONCAT function in the custom criteria box. The better configuration is shown below: Thanks, Dan
  11. Hi Martyn, thanks for the clarification. The product team are now aware of this requirement so I'll leave it in their capable hands to determine how this addition may manifest itself. Dan
  12. Hi @Martyn Houghton, thanks for your post. Did you have a specific filter in mind, such as the quick filter where you can type to filter the list, or more stock filter options to filter on service, status, etc? Dan
  13. @Gary@ADL thanks for confirming the situation with the expiry date. I'll leave it up to support and the Product team to determine whether the task should allow an expiry date in the past or identify why the bpm doesn't just progress in this situation. Something doesn't seem quite right to me there. In terms of what you can do in the mean-time to make the process more robust, I'd perhaps add some logic immediately before your task to check whether the leave date is before "now" ("now" effectively being the date at which the task is created). I've mocked up an example that will hopefully illustrate how this can be done: The above configuration should allow you to avoid the stuck task where the leave date is in the past. I hope that helps, Dan
  14. Hi @Gary@ADL From your screen shot above showing the variable being used to set the task expiry, it appears you are feeding the task expiry date from a previous task. I believe this to be the case because the variable begins with "&[functions(getTaskAnswers..."). I can see you've given the field an id of "h_custom_b" (so I can see why you might be expecting the value to exist in h_itsm_requests.h_custom_b) however custom task fields don't support field mapping, which is why the value isn't appearing in h_itsm_requests.h_custom_b. You'll be able to find this in h_sys_tasks.h_answers. Just like the request table, the task table is going to contain alot of records. To make life easier it'll be better for us to know the task id then we can query that table and inspect the values captured against the task. Finding the task id is relatively simple. First go into the request and find your task on the right hand side and click on the task title to open the popup. Then, click on the task title which appears in the popup itself. A new tab will open at the main "activities" view (the view where you can see and manage all your tasks). The task id can be seen and copied from the URL. We can then use this in a database query to inspect the data against that task. The following query can be used to get the task record with the columns of interest: SELECT h_task_id, h_created_on, h_answers FROM h_sys_tasks WHERE h_task_id = "TSKxxxxxxxxx" Inspecting the task record will allow you to confirm the situation @Steve Giller describes where the expiry date is earlier than the task created date. If we find that to be true, there's two things that stand out for me: 1) Should the system allow a task to be created where the expiry date is earlier than the date/time on which the task was created? 2) If point 1) above is a legitimate situation which meant the task immediately expired after it was created, why hasn't the bpm progressed? Are you able to obtain the task ID and show me the result of that query to confirm what we think is happening? In the mean time I'll see if there's a way to rescue the stuck BPMs. Thanks, Dan
  15. Hi Mike, thanks for your post. I hope the HR team found the "Hornbill for HR" demo insightful. Currently, an "Add attachment" field isn't available for us to add on a custom form which means it's not possible to achieve the single pane layout you desire. The form which I believe was of interest was the standard "Add Attachment" form available in Progressive Capture. This is shown below and does feature three ways to interact with it when adding an attachment: Click to choose a file using file explorer Drag and drop Paste a screen shot Having one or more of these attachment options available as a custom field type would be a great addition to custom forms and give us even more flexibility should we wish to consolidate forms. Dan
×
×
  • Create New...