ServiceDesk 4.4.62 Update 04/18/10

Until about 30 months ago, there was nothing in ServiceDesk functionality to operationally distinguish between jobs as setup for in-shop work versus those setup for in-field/on-site service.  However, a few servicers described the need for certain kinds of distinguishing treatment, so the program code was enhanced to provide the same (see description accompanying Release 4.3.45).  At the time, we used kind of a "cheat" method to facilitate designation, of any particular job, as being in-shop (as opposed to the default assumption of on-site).  Quite simply, in the LocationName box you'd type the magic phrase "SHOP JOB."  In result of seeing such text there, ServiceDesk would realize it was a shop-job, and react accordingly. 

This has been the solution until now.  It's worked fine, except for the fact the designation method was perceived by some as -- shall we say -- inelegant.  Certainly, it has been less elegant than would be having an actual checkbox for the purpose, and that is the matter now addressed. 

In fact, I began working on the graphic interface for this improvement a few weeks back (since real-estate in the applicable forms is already tight, I could not simply add-in in a normally-labeled checkbox for the purpose; the applicable forms do not have space for that).  You may have noticed my tentative solution when a couple of tiny new boxes appeared in the Callsheets.  These were otherwise not-yet-operational, and there was no notice explaining their purpose.  It was nevertheless my intent to program the first to default with a checkmark indicating the job was intended for on-site service, while providing the option to user-check the second, instead, to designate the item as a shop job.  Initially, I got as far as making that graphic, but did not get any of the underlying programming done. 

This past weekend I finally found time to do the underlying programming.  Initially, I'd intended to go ahead and use the graphic interface as above described, but soon decided two checkboxes make less sense than a single one (why do you need a box indicating normal status, anyway?).  The final scheme is, this single box defaults to a neutral color to indicate a normal, in-field-service job -- but can be user/click-toggled to red for the purpose of indicating in-shop service instead.  So, that's what we've ended up with (with, as you'll note, the final/operational box also moved to a slightly different location, as compared to original intent). 

Applicable Callsheet section without any check-off designator

With interim/abandoned modification, showing boxes as intended for toggled/alternate checkmarks

Design as finally settled upon (here shown with new checkbox NOT toggled)

Also showing new/actual design, but with new box toggled to indicate job is intended for in-shop work

Naturally, this new little designator has been added not just in Callsheets, but in JobRecords (current and archived) too.  Simply click on the little box in any such context, to toggle it red, any time you wish to designate the job is intended for management as in-shop work.  Or, click again to toggle back out.  Again, it will show in a neutral color (same color as the surrounding background) if it's a standard job, or as red if toggled for in-shop.  Also, if you float your mousepointer over the new little box, you'll see a ToolTip come up to remind you of its purpose. 

Ideally, it would have been good for me to include with this release conversion code that would go through all present and past jobs, search for the old mode of designation (i.e., the phrase "SHOP JOB" in the applicable location), and change the new designator to match.  Alas, I did not find time for that.  However, for a reasonable transition period ServiceDesk will recognize either old or new designator methods as legitimate.  In other words, whether it finds the phrase "SHOP JOB" in the expected box, or if you've toggled the new little checkbox to red -- either way it will see the job as being intended for in-shop management.  From this point forth, of course, you should use the new designator, and abandon the old.