Jump to content

Steve Giller

Hornbill Staff
  • Posts

    6,498
  • Joined

  • Last visited

  • Days Won

    268

Posts posted by Steve Giller

  1. Just a flag - if you're recording Toner Codes and Stock Level you'd need more than 6 fields - CYMK + 4 Quantity fields is 8, and you'd probably want to record the trigger levels for placing an order, too.
    Also, the difficulty with recording them in the Printer Asset Properties table would be that if you have 4 Model X printers you'd only have 1 pool of CX, YX, MX, and KX toners so the logic to adjust the stock levels would get very complicated very quickly.

  2. In theory, if your alerts and call logging procedures are consistent - whether they are manual, email or whatever - then logging a job for a printer x requires toner y (possibly y-cyan, y-magenta etc.) and this can trigger a script that reduces stock by 1 for that toner, and create a new job to order more stock at a certain trigger level.

    We've experimented with this and the difficulty has been having a wide variety of printers - the alerts are inconsistent for one thing, and don't even get me started on ordering stock from different suppliers depending on seemingly random criteria ...

    But yes, theoretically possible, it just requires a high level of organisation at the back end.

  3. A useful (and fairly common) customisation option for an App view would just be to have a list of all fields than can be displayed with a simple [On/Off] checkbox - a more complex version would allow re-ordering the list to customise the view as well.

     

  4. If you've received a personal email asking you to raise a job then it's perfectly proper that the "Raised by" time is the time at which you action that request.

    Taking a rather stupid example, if you were microwaving a ready-meal which stated it took 4 minutes on full power to cook, you wouldn't expect it to be ready 4 minutes after you decided that you were having that meal for tea, would you?

    Foolishness aside, this is more a scenario for expectation management - your agreed SLAs with your customers have to be clear that a personal email does not constitute a job request, and that should the call be raised from such an email this is a courtesy and as such the call "timers" will only start once the email has been received and acted upon.
    The easiest way to sell this to customers is to ask them what happens if they send an email while you're on holiday - you can't action an email you don't receive because you're away for two weeks, can you?

    • Like 2
  5. On this topic, is the mapping to sAMAccountName hard coded into the product?
    We've found that mapping to the sID to be more effective, as that very rarely changes when user details are ordered.
    This does produce other issues, mainly that the sID is not exactly a field that you ever want to be visible, but that's relatively easy to work around.

  6. 37 minutes ago, neilhsfc said:

    2016/06/17 08:39:41 [ERROR] Unable to Search For User: Unable to load the user security session

     

    37 minutes ago, neilhsfc said:

    2016/06/17 09:39:40 [ERROR] Unable to write to log Unable to load the user security session

    Both of these seem to verify that it's insufficient permissions (or a non-existent user!).

  7. For me, as everything, I can see the argument for having this as an option, but I would agree it would need to be on a per-team setting, not global, for the reasons you describe.

    Personally I would not want to publish individual contact details, otherwise you might as well dispense with the Service Desk altogether and go back to customers having "pet" technicians (an exaggeration, perhaps, but still rife in our organisation) but I have no doubt that there are different structures where this would be essential.

    On the other hand, once we complete our Skype migration we won't have numbers, just names, so the point will be moot.

×
×
  • Create New...