I’ve created a SmartList Builder report using the User Task table. The report displays fine for me, and I can filter the list as desired.
However, what I would like to create is a Go To in order to open the Task window for the specific task I have selected, but have been unable to make that work.
Is this possible to do this with SmartList Builder Go To’s?
Yes! This is possible using an “Open Form” type of Go To.
If you’d rather watch a video demonstration, see below or click here.
The first rule of thumb is to always look for an existing Built-in Go To. That way, we can leverage what already exists out of the box before trying to create our own. However, sometimes this isn’t possible to do.
Since there isn’t an “out of the box” Go To that does this in GP SmartList – we are forced to make our own.
Typically, that will mean that we have to make our own “Open Form” Go To type.
Usually, the best approach to an Open Form type of Go To is to mimic how the user would manually do this. IE Open the window, type into a field, perhaps type into a 2nd field, and then GP brings up the selected record.
In this case, these steps appear to be impossible.
In the above screenshot, there are two tasks on the home page: Task #1 and Task #2. Clicking on Task #1 opens the Task window with the selected task open.
There isn’t an apparent means of how a user would be able to “hand enter” that value, and it isn’t going to be possible or desirable to try to “click the link”, especially since the Home Page only displays YOUR tasks, and the idea here was to open ANY user task.
Next, we need to see if we can figure out how GP does it. The only way to do that is to get a Dexterity Script log of us performing the same action and see if we can gain insight on how to do this. You can follow this Microsoft KB to add the setting to the dex.ini.
After you relaunch GP and get fully logged in, turn on the Debug | Log Scripts and choose the file name and note the path where the file will be created.
Now that this is enabled, click the same task again and when the Task window opens, use the Debug | Log Scripts menu again to turn it off.
In the above screenshot of the script.log captured,
#1 is where we clicked the link itself.
#2 is the next logged statement, which would be the name of any procedures or functions that were called or field script.
You don’t see the actual GP code here – just the names of the method calls and any parameters that were passed.
In this case – “Open of form syTask” where “Open” is the name of the procedure, and the form in question is named syTask. This one looks promising, but since we don’t have the source to GP, we don’t know exactly what it is doing in this method.
#3 However, as the GP Security() function is called, which means that this script opens the syTask window, and GP is checking security for that. Below that, all Security stuff and GP are getting the window ready to display. But we need to see if we can figure out how it does it.
Looking at the bottom of the log after the window is open, we find what we’re looking for.
In the screenshot above,
#1 is the syTask form “pre” script running, meaning that it is opening.
#2 is the visible “window” opening, and it also has a “pre” script (we don’t know what either do).
#3 is what we’re looking for as it is a “field change” script which is what is like “driving” the UI. The GP Dev team wouldn’t have had to code it like this, but fortunately for us, they did.
A good rule of thumb (but not all, but many), you will find that there is a field named typically “l_Temp Control Number”. It could be named something similar, but “temp” is often in the name if not called this outright.
This (L) Temp Control Number field is almost always the same datatype as the window “Key Field”, like “Vendor ID” or “Customer Number,” and in this case, it is the same as the Record Number, which is the Primary Key field on this table – SLB defaulted this into the Key Fields in the SLB UI.
Knowing that this is the Key Field of the table- then going back to the initial script.log of “Open of form syTask” the only param passed was 43.0000 which is the Record Number of my Task #1 record I had clicked on – so that does make sense why the GP method passed that specific value.
Now it is possible there are other values that need to be set for this to work. We would have no idea of what that would be and even this is a bit of an educated guess. But since this value that GP is passing is the PK of the table and (L) Temp Control Number is a common type of field to set/execute, it is a fairly good guess.
We press the SmartList Builder Go To button and then choose Add | Open Form for our new Go To.
I’ve found the required Product, Series, and Form that we want to open.
Since we believe there is only one field to set, we press the ‘Add’ button and want to “Set a field and run the field script” (in almost every situation). Then the field we believe is what we want “(L) Temp Control Number” and then set it to our Record Number. Press ‘Save/OK’ back to the Go To window to make this the default Go To and press ‘OK’ to close the Go To window and save the SmartList.
Here we can see the resulting SmartList showing all the users’ tasks, and I double-clicked on the first one (for DYNSA), and we can see that GP opened it correctly for me, and I can save/delete/change it as I like.
