Home General Discussion

SCSM Out of Office - Prevent Work Item Assignment

Adam_DzyackyAdam_Dzyacky Customer Contributor Monkey ✭✭✭✭✭
edited January 2019 in General Discussion
This is a request that's come up herehere from @Tom_Hyde and here from @Carol_Lee.

Clearly this demands some kind of solution and that's why it's the latest repository available on my GitHub with all the source ready to be viewed and modified at your discretion should you so chose. In it, a few things to help get you started:
  1. Management pack to extend your System.Domain.User class with Out of Office concepts ([true/false]OutOfOffice, [date]OutOfOfficeStartDate, [date]OutOfOfficeEndDate)
  2. Management pack to introduce workflows that will prevent Work Item assignment when the Assigned To's OutOfOffice property is true
  3. Optional PowerShell influenced from the SMLets Exchange Connector so you can set the OutOfOffice property across all users from Exchange into Service Manager. Wire for Orchestrator or SMA and then this OutOfOffice property can be set by simply setting your out of office via Outlook!

Currently, this will prevent Work Item assignment on the following Work Item types:
  • Incidents
  • Service Requests
  • Change Requests
  • Problems
  • Release Records
  • Manual Activities

Comments

  • Justin_WorkmanJustin_Workman Cireson Support Super IT Monkey ✭✭✭✭✭
    @Adam_Dzyacky
    You're the hero!  You deserve the gauntlet!
  • Joe_BurrowsJoe_Burrows Cireson Devops Super IT Monkey ✭✭✭✭✭
    @Adam_Dzyacky
    You're the hero!  You deserve the gauntlet!
    Hes a Physicist!
  • Adam_DzyackyAdam_Dzyacky Customer Contributor Monkey ✭✭✭✭✭
    edited January 2019
    Many thanks for the badge @Joe_Burrows
  • Jari_JuntunenJari_Juntunen Member IT Monkey ✭

    Noob here. Does this work with scsm 2019? I'm having some problems getting this working.

    I have the extended user classes with the MPs provided and when I change out of office to true in user form it shows ok. But in the users view all the out of office fields are empty. Also I can still assign a work item to user who is out of office. The user I tested with is a global operator in service manager, does that matter?

  • Adam_DzyackyAdam_Dzyacky Customer Contributor Monkey ✭✭✭✭✭

    Hey there @Jari_Juntunen - haven't tested it out with SCSM 2019. But since the .NET dependency didn't change (as it did from 2012 to 2016) I don't know why this wouldn't work.

    Well... that's not entirely true, the amazingly awesome @Gerhard_Goossens recently made a pull request to the repo that rectifies some issues with some of my original variables used in this. I tried to complete the pull the other day but for whatever reason it won't complete the merge. So while I attempt to sort that out, if you download the forked repo directly from him you should be able to reseal the workflow MP with the included key and upgrade.

  • Carol_LeeCarol_Lee Customer IT Monkey ✭

    Hi @Adam_Dzyacky , somehow I just came across this thread today. Thank you so you much!! I will try the solution out in our environment. We are still on SCSM 2016.

  • Adam_DzyackyAdam_Dzyacky Customer Contributor Monkey ✭✭✭✭✭

    Version 1.1 is now out on GitHub

    This release contains bug fixes as identified by @Gerhard_Goossens. Thank you for your contribution!


    While there are no new features with this release, nothing stops those from being added with more PowerShell for this script based workflow which you can freely edit with the SCSM Authoring Tool.

  • Jari_JuntunenJari_Juntunen Member IT Monkey ✭

    For whatever reason this is not working on my system (scsm2019). Maybe the smlets don't work but can't really pinpoint this since I don't get errors.

    Would it be possible to use type projection to get analyst OOO status to show on incident form and how would I do this? I have made some tests and I can make class extension (quite easy actually), but I'm struggling to understand type projections.

  • Adam_DzyackyAdam_Dzyacky Customer Contributor Monkey ✭✭✭✭✭
    edited December 2019

    Would it be possible to use type projection to get analyst OOO status to show on incident form

    I don't see why this wouldn't be possible. But it's worth pointing out that if you've extended the user class per the MPs included in the solution, you can open the Assigned User, go to that user's Extensions tab, and you would see the OutOfOffice true/false property which should be null by default if all you're looking to do is see the value. But I suspect you're looking at exposing this property in the portal's Incident form, so I'd check out one of the original Cireson Knowledge Articles details this. Haven't tested myself, but since its a Class Extension and the user is already being pulled by virtue of the Incident, I think you may be able to just place it on the form without a Type Projection.

    I'm struggling to understand type projections

    You wouldn't be the first to say that. Type Projections are nothing short of beyond useful for all sorts of things in SCSM, conceptually I think are easy to understand, but difficult to implement from scratch. The explanation almost always given on this front is something to the effect of "Think of it as a pre-built SQL query in that all of the JOINS have been done for you." For example, if you were to create a View in the Console you could use any class or a combination class (type projection). Those TPs generally are something like Incident and Affected User. Two classes, presented as a single concept. As you might expect, if you can use two classes you could also use any number of them. Just like SQL, the more JOINS you perform the more expensive that query/search can become. Alright, enough explanation. If you want a quick, easy way to build Type Projections @Justin_Workman's latest community contribution is the SCSM Projection Builder. A 100% PowerShell GUI based solution that uses SMLets to assemble a management pack containing a custom type projection. This thing is great for all sorts of reasons, the least of which being you can quickly assemble a TP and then see how it's formed in XML.


    As far as testing goes, a quick visual sanity check you can perform is

    1. Obviously making sure the user in question has the property set to true
    2. Administration -> Workflows -> Status -> look up the ooo workflows. Is the WF at least triggering for the Work Item class in question? Then, is it successful or failed?
  • Jari_JuntunenJari_Juntunen Member IT Monkey ✭

    @Adam_Dzyacky Thank you! I will try these.

Sign In or Register to comment.