Wiki: Search Requests, Incidents, and Problems Simultaneously for Ticket Number Options

[admin]

This is the discussion topic for the wiki article: Search Requests, Incidents, and Problems Simultaneously for Ticket Number

[Anthony]

I followed this to the letter and when I recylced the services and cleared the web cache nothing changes. There was no choice for all tickets on the go button list. I am sure I did something wrong but am at a loss trying to find it.

[Gityerfix]

I suspect that the javascripts have been cached in your browser. Clear your internet cache and refresh your browser. The changes should appear then.

[Anthony]

I suspect that the javascripts have been cached in your browser. Clear your internet cache and refresh your browser. The changes should appear then.

I cleared all caches and still no All Tickets option. I am sure I am doing somthing wrong but am not sure what it is.
I have attached a copy of the gobtn. Maybe I put in the wrong place? It only found one if (cfgAccessReqMgr) when I searched for it.

[Gityerfix]

It looks like you are running a pre-cumulative patches #1 version of the gobtn.html. But regardless, if you scroll up just a little ways you will find another reference to cfgAccessReqMgr that contains Incidents, Problems, and Requests. This where I put my code.

Are you using Form Groups?

Are you using the Web Screen Painter to make your changes?

[Anthony]

I am using WSP I will try what you have given and see what happens. This is something I want to get working.

[Anthony]

I put the code where you instructed and it worked. However, when you use the all tickets it only finds requests. If I put in a change order 3 it comes back no matching All Tickets.

[Gityerfix]

It says "All Tickets" but it is really only for Requests, Incidents, and Problems. Thus the title Search Requests, Incidents, and Problems Simultaneously for Ticket Number. Change it to read "Reqs/Incs/Probs" if you like. Change Orders and Issues are not included in this search.

[Anthony]

OK good to know. Currently, we only use Requests and Change Orders. If we go ITIL I will have to put in in at that point now that I got it to work on my test environment

[Ukiah]

I have made this customization and it works GREAT. I have an additional request or question.

Since it works as advertised, how do I REMOVE the options of searching Reqs/Incs/Probs separately? I tried both REM'd and deleting them from the gobtn.html file, but they still show up.

[Gityerfix]

All I did was add // before each line.

CODE

//            if ( propIsITIL ) {
//                html += "<OPTION VALUE='in.ref_num'>Incident</OPTION>";
//                html += "<OPTION VALUE='pr.ref_num'>Problem</OPTION>";
//            }
//            html += "<OPTION VALUE='cr.ref_num'>Request</OPTION>";

[Ukiah]

I tried that first thing and couldn't get it to work. Let me try it again and if I still have problems, I'll post the specific code I have and maybe someone can see where or why it's not working.

[Gityerfix]

It's javascript, so it might cache. Try an F5... maybe even reboot.

[wheels]

Hi guys

Got code working after a few tweaks. Thanks

We have 1 question though, how can we get the Requests, Incidents, and Problems to appear as the default selection at the top?

[Gityerfix]

We have 1 question though, how can we get the Requests, Incidents, and Problems to appear as the default selection at the top?

Put it first in the list and it should be the default.

[wheels]

Hi Gityerfix

I should have advised in my comments that we have tried adding it first in the list. When we add it to the top it still defaulst to Incident.

I have attached screen shots and the code that we have applied.

Happy for any ideas to fix.

Attached File(s)

 Go_Button_Search.doc ( 115K ) Number of downloads: 28

 

[Gityerfix]

Well, is this really an issue? When you think about this, what is the purpose of having an Incident option any longer? When the go button search is being used people are trying to access a specific ticket. They could care less what type of ticket it is. So why restrict them and add the potential of additional searches if they accidentally select the wrong ticket type. I recommend adding the new consolidated search method and remove the individual ones. I can't see any benefit in maintaining the individual ones.

[akhilkmathur]

I have implemented the same and it works! How can I include the search to look into the CHG tickets as well? What I want to acheive is to be able to search for Incidents / Request and Change Orders all together.

[Stuart]

I have implemented the same and it works! How can I include the search to look into the CHG tickets as well? What I want to acheive is to be able to search for Incidents / Request and Change Orders all together.

Generally you are not able to include CHG tickets as well, the reason Incident/Problem/Request tickets can be searched with one method is because they exist in the same table so each ticket ID number is unique. Due to the CHG tickets being stored on a separate table (and there being the strong possibiliity of having duplicate ID numbers, i.e. one existing in the CHG table and one existing in the CALL_REQ table) this cant be done.

As an additional note if you had the time and resources you could perhaps program something specific to your site where if you searched for C1234 then it would search the change table for you (just a thought) unfortunatly I am not to sure how you would go about this.
Regards
Stuart

[akhilkmathur]

Yes, I am writing a script which will read the input box to look for "I"vs "C" for change order and then look for respective tables.