Jump to content

Making diagnostics easier: one click access to view the database field contents for the active request

Recommended Posts

I very often find myself needing to know what is in a given field in the database for a particular record at a given time. For example, the value in one of my custom fields. These are not always fields that I want to expose to the users through the request details section. At the moment I have to manually go to the Database Direct section to look up the value or I have to run tests adding-in nodes to expose values on the timeline; these take time.

I really wish there was a 1-click way to view the list of all the fields of the current Request and their current values at any one time. I thought of using a custom button to launch a URL, but database direct does not expose any of its parameters into the URL to enable a default query to run, for example. I guess what I'm requesting is a button bit like dev tools in a browser, F12, which brings up certain useful diagnostic background information for system administrators.

Is there a way to do this or something similar and would other admins also like a fastpath to this information?

[I already have a custom button to launch the current BPM when I need to see where any given workflow is at]

Link to comment
Share on other sites

Another possible idea.   Using a Custom Button and an Auto Task, you can add a notice to the the top of the request that contains the custom field information, which you can then manually remove after you have read it.  However, it would be visible to anyone that views that same request at the same time.   

Link to comment
Share on other sites

@James Ainsworth the custom View would have to be per occasion, right? i.e. I would need to enter design view, add the field and save it. Would that save as temporary for me, for others or permanent for everyone? I cannot have my own permanent custom view on a Request Type can I?

The other idea with the Custom Button and Autotask is interesting. I am going to give that one a try. I have a feeling that will be limited by string length. A development of that idea is to send myself an email with all the custom fields. Also that way no-one else gets to see it and we're not limited by string length.

Link to comment
Share on other sites

I have gone with the email idea and my email lists all the customer fields and sends to me.

@James Ainsworth where do these fields come from? I cannot find them on the Wiki: Mapping Fields from Customised Forms - Hornbill or Table Info: Main Request Table - Hornbill

These fields are not mentioned in the Wiki at all (either of the above links). Are they available to use and map to?

1 - {{Extended Information.H_custom_1|empty}}
2 - {{Extended Information.H_custom_2|empty}}
3 - {{Extended Information.H_custom_3|empty}}
4 - {{Extended Information.H_custom_4|empty}}
5 - {{Extended Information.H_custom_5|empty}}
6 - {{Extended Information.H_custom_6|empty}}
7 - {{Extended Information.H_custom_7|empty}}
8 - {{Extended Information.H_custom_8|empty}}
9 - {{Extended Information.H_custom_9|empty}}
10 - {{Extended Information.H_custom_10|empty}}
11 - {{Extended Information.H_custom_11|empty}}
12 - {{Extended Information.H_custom_12|empty}}
13 - {{Extended Information.H_custom_13|empty}}
14 - {{Extended Information.H_custom_14|empty}}
15 - {{Extended Information.H_custom_15|empty}}
16 - {{Extended Information.H_custom_16|empty}}
17 - {{Extended Information.H_custom_17|empty}}
18 - {{Extended Information.H_custom_18|empty}}
19 - {{Extended Information.H_custom_19|empty}}
20 - {{Extended Information.H_custom_20|empty}}

There are fields for 21-30 in the Wiki for the Main Table but are these 'extended' ones the same or in addition to those in the main table labelled 21-20?

21 - {{Extended Information.H_custom_21|empty}}
22 - {{Extended Information.H_custom_22|empty}}
23 - {{Extended Information.H_custom_23|empty}}
24 - {{Extended Information.H_custom_24|empty}}
25 - {{Extended Information.H_custom_25|empty}}
26 - {{Extended Information.H_custom_26|empty}}
27 - {{Extended Information.H_custom_27|empty}}
28 - {{Extended Information.H_custom_28|empty}}
29 - {{Extended Information.H_custom_29|empty}}
30 - {{Extended Information.H_custom_30|empty}}

These are mentioned in the Wiki page for the Mapping Fields but not in the Main Table.

31 - {{Extended Information.H_custom_31|empty}}
32 - {{Extended Information.H_custom_32|empty}}
33 - {{Extended Information.H_custom_33|empty}}
34 - {{Extended Information.H_custom_34|empty}}
35 - {{Extended Information.H_custom_35|empty}}
36 - {{Extended Information.H_custom_36|empty}}
37 - {{Extended Information.H_custom_37|empty}}
38 - {{Extended Information.H_custom_38|empty}}
39 - {{Extended Information.H_custom_39|empty}}
40 - {{Extended Information.H_custom_40|empty}}

Link to comment
Share on other sites

Hi @Berto2002

The custom fields a-t  in the h_requests table are the same (and hold the same info) as the custom 1-20 in the h_sm_requests_extended table.

The custom fields 21 - 30 in the h_requests table are the same (and hold the same info) as the custom 21-30 in the h_sm_requests_extended table.

The custom fields 31-40 do NOT show in the h_requests table but DO show in the h_sm_requests_extended table.

In the email template, these fields can either be picked by selecting the 'Custom' fields, OR the Extended Information - Custom fields:



So, in answer to your question (I think!), the custom fields 1-30 ARE in the Main Table, but NOT in the extended table, and yes, they hold the same information. 

Link to comment
Share on other sites

@Paul Alexander this helps me understand it. It's bewildering and seems a little wasteful to have a-t and 1-20 as holding duplicate/the same information when I could do with BOTH a-t and 1-20 as separately addressable. My subtext is that I am trying to find if I have more custom fields I can use and it seems not.

Link to comment
Share on other sites

51 minutes ago, Berto2002 said:

It's bewildering and seems a little wasteful to have a-t and 1-20 as holding duplicate/the same information

@Berto2002 it might appear as such but Main Requests table and Extended information table are designed for, in part, different purpose. The "main requests" table main purpose is to serve the request list view. Thus it is limited in terms of what information is stored given that it can be subject to performance due to access and the way it is accessed by users (thinking custom filters/views). Having all the extended info into main table will make it a nightmare for performance. Now, we have same info in both places because historically info from extended was (also) added to main (A-T and 1-20) if and when we could balance the performance. If you like you can think of the extended table as the main storage (like a deposit of sort) and the main table as the high street store. Both in essence have roughly the same products but they are designed for somewhat different purposes.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Create New...