ServiceDesk 4.8.135 Update 12/13/19

If you look in the \sd\HLinks folder on your server drive, how many files do you see?

If at the root-level of this folder you see many hundreds or thousands of files, it's possible this is degrading your system performance (you're not likely to have so many files unless you've been operating at a high volume and for multiple years).

In fact, years ago we discovered Windows slows considerably, in its file access, when folders contain too large a quantity of files within any single folder location.

That is why many years back we added a function whereby, anytime you double-click on a hyperlink within SD (in particular, where the link references a file within your \sd\HLinks\ folder), the system times how long it takes for Windows to open the file for you. If it's more than one second, ServiceDesk informs of the delay, and offers to run a routine that moves the large quantity of root-level HLink files into subfolders. This tends to solve the issue.

In the years since, we've engineered so that file distribution in a number of other areas (in particular, where file quantities might otherwise become excessively large) is automatically distributed into subfolders. This is true, for example, in regard to copies of dispatch data that are attache to each automated dispatch (you'll find these copies in subfolders under \sd\HLinks\Dsptchs\) and in regard to saved copies of your internal SD-Mails (you'll find these in subfolders under \sd\OldMail\).

Regardless, until now our efforts in this regard have been somewhat ad hoc and piecemeal. With this release, we've finally been systematic in seeking to assure we've addressed all areas where too many files might accumulate in single folder locations. Here is a listing of what is now specifically addressed:

• We no longer rely on an "after-the-fact" solution (as described above) for too many files accumulating in the root-level of \sd\HLinks\. In particular, until now, any drag-and-drop-created item would be copied directly into that folder. That is no longer true. Now, any drag-and-drop item will be copied into a month-specific subfolder. Thus, going forward, there will be no added accumulation within that folder's root level.
  ‍

• Prior to now, files that contain information regarding your various saved edit states for each of the FinishedForms have gone into the root-level of \sd\InvcClms\. Depending on your usage and history, it's possible you have many, many thousands of of files in the root-level of that folder. Going forward, that will no longer happen. Instead, all newly-created such files will go into month-specific subfolders of the parent folder.
  ‍

• Prior to now, copies of your SD-Mobile Ticket images, as created via SD-Mobile, were deposited directly into your \sd\HLinks\ folder. With the next release of SD-MobileLink and forward (this release will likely be posted on Monday, 12/16), that will no longer happen. Instead, SD-MobileLink will place these copies into month-specific subfolders, and within an intermediate subfolder at \sd\HLinks\Tckts\.
  ‍

• Prior to now, copies of your SD-Mobile Disclaimer images, as created via SD-Mobile, were deposited directly into your \sd\HLinks\ folder. With the next release of SD-MobileLink and forward, that will no longer happen. Instead, SD-MobileLink will place these copies into month-specific subfolders, and within an intermediate subfolder at \sd\HLinks\Dsclmrs\.

Please note the above-described work all goes toward assuring that, going forward, there is no longer any tendency for the system to accumulate too many files in single-folder locations. Regardless, it's possible, since these changes are only coming now, you already have too many files in particular folder locations. Don't worry. We've got you covered.

Prior to this release, there was a particular menu option that looked like this:

Now it looks like this:

The old menu option was a method to manually invoke the same process, as above described, whereby, when the system see that Windows is slow to open a HLinks-connected file, it offers to run the subfolder-dividing process for you. Now, if you pick the above-shown option, you'll get an offer to run similar processes, but in regard to that and other areas:

Especially if you've been running ServiceDesk for multiple years and/or with a significant level of activity that results in accumulating many files in these areas, we suggest you run each of these procedures. We'll be interested to learn if you notice an increase in performance afterward.

(As two minor items of note: (1) SD-MobileLink Ver. 2.0.110 and earlier will continue to place items in the root-level \sd\HLinks\. For such reason, even if you run the above items presently, you may want to run them again after you've updated to SD-MobileLink Ver. 2.0.111 or above.  (2) any root-level files within \sd\OldMail will be either from a very long time ago or because of a flaw that was temporarily present in SD-MobileLink that resulted in it saving SD-Mail copies in both month-segregated subfolders and in the root-level of \sd\OldMail. For that reason, the above-referenced process for "OldMail" does not move files to multiple month-specific subfolders; it instead moves them to a single subfolder called "Old_Scavenged")

We give credit for this one to Dan Verschleiser at Dan Marc Appliance.

Dan's company recently began using the awesome MPH-Diagnostics feature, as most recently described here (that reference in itself links to earlier descriptions).

Dan wanted to measure how well triage processes are working, when connected to use of this new feature. I happily pointed him toward the new Triage-Metrics-Reporting feature, as described here.

In response, Dan was astute enough to ask about a concern that I'm afraid I'd personally glossed over, when creating the new Triage-Metrics-Reporting feature. It is, can we count on users engaging in such action, as they triage each job, as will show they did so, so as to be tallied within the new reporting? 

Dan's question led me into some close examination of the matter.

I'd made the report look into each JobRecord's narrative history for the expression "chckd-off triage," as would be present in a narrative such as this:

"12/13/19 12:34 GR: chckd-off triage"

This of course begged the question: : What actions result in insertion of this kind of textual entry?

It turns out there was only one. This is when a user manually, from within a JobRecord, clicks on its triage flag to indicate checkoff. Clearly, this seemed insufficient.

For such reason, there are now two other contexts where ServiceDesk inserts such text for you:

1. When a user enters and then exits the MPH-Diagnostics window, the system looks to see if there have been no prior visits on the job and if the JobRecords is not yet checked off as triage-completed. If these conditions are true, it presents a dialog box asking if you'd like to checkoff the underlying JobRecord as triage-completed (with your consent, of course, it does so, and of course inserts appropriately to the narrative history).

2. From the next release of SD-MobileLink and forward, that application will do the checkoff (and place an appropriate note in the historical narrative) whenever a user uses the online Triage system to complete a triage process.

   
   Thank you Dan.