IT Monkey will place code here as examples of what Cireson's consulting team has to offer as well as examples for public consumption to benefit the Microsoft System Center community as a whole.
DISCLAIMER
All files and projects located here come as is and without any warranty or support. We will attempt to improve the projects as time goes on based on customer and community demand. Comments and improvements are welcome as well as customization requests. Your use of these Cireson Uploads is subject to our Terms of Use.
Cireson's support team has no information on these projects outside of what you have available and will not provide support for these enhancements, extensions, and scripts.
Dont forget to checkout solutions uploaded by our customers, partners and community members here.
Locking the work item
What it does:
- User opens workitem
- Checks if there is an object with the same ID in the work item lock class
- If there is none, a new entry is created for this workitem. The lock is then updated every 30 seconds.
- If a lock is found, the code checks if the lock belongs to this user, or if it is older than 35 seconds. In this case the lock is updated with the current time and the details of the user. The lock is then updated every 30 seconds.
- If the lock is found but the lock is held by a different user and was last updated less than 35 seconds ago, the user is alerted that the work item is being edited by the user holding the lock and the Save and Apply buttons are disabled.
Installation:
- Unzip the attached file.
- Import the Management Pack into the SCSM Console
- Run the PowerShell script to give End Users create/edit rights to the Work Item Lock class
- Add the JavaScript code in the custom.js file to the same file in C:\intepub\CiresonPortal\CustomSpace folder.
N.B. This has not been tested in a production environment. Please test it thoroughly before implementing it. I am sure it needs more error checking code before it is ready for use.
Comments
now that i've seen this one here i will be putting it into our dev environment for testing, and if it works well moving to production
running the powershell script I get the following error:
Okay, I have SCSM 2012 R2 installed.
But the scripts seems to work in my Test environment. I get a flag that the ticket ist currently edited by User X, and I can not make any changes on the Ticket.
That's great work. I will test it the next day in our live environment.
I think that the Class ID in SCSM 2012 is different to SCSM 2016. Maybe you can tell me the Class ID.
But it seems to work properly in my TEST environment.
I am not quite sure how to interpret this message.
These are actual values, not sanitized.
Does it matter that I use a custom End User role instead of the OOB one? The OOB role does exist, obviously, but it has no explicit members. I attempted to add the internal name of my role on line 8 (also by ID and display name) but I got a bunch of nulls throughout the script that caused different errors. So I have reverted back to this, to keep troubleshooting simple for now.
we also don't use the OOB End User Role, but one based off it, and running the script with the only change being the path to the dll works every time here (SCSM 2016, SQL 2016, Server 2012R2)
I had originally changed that line to match my end user role, then changed it back and ran again. I will run it clean in the next environment.
But the good news is that this appears to be working fine in spite of the errors.
@john_doyle: I absolutely love this!
I modified mine to have a persistent message at the top-right of the page, but I want to live with it for a while and get extra opinions before actually sharing it as a suggestion. Your way might be the right one--my way is just more similar to the way our old system worked.
I do plan to run a workflow to clean out "old" locks, potentially...but I want to test the usefulness of keeping them first. I did create a CI view of them so that I can see where this goes.
Like you we'll also be adding something to clear out old items, not sure if we'll have it clear out items older than a day or week etc yet though
Although I am still testing this in lower environments, initial testing is showing that we can "safely" disable the concurrency check without losing updates made by the system account, as a result. If my last batch of tests works out, that will be a HUGE win, as the "data conflict error" is one of the most-complained-about "features." Even if that does not work out, this is still providing benefit.
I have the success block of the lock object commit creating an object in the view model, so that other functions of mine can A.) know that there is a lock, B.) know whether it belongs to the current user or someone else, outside of the scope of this code, and C.) I can run other functions based on whether the current user is locked out, such as removing certain tasks. I have a message right below the title that indicates if the current user has the lock, or if someone else does. If someone else, their name is a clickable link that opens a Skype IM.
You are a hero, @john_doyle.
We installed this feature, and did not receive any errors. We are running SCSM 2016,on portal version 9.4.5.
Although when I'm in the portal trying to test how it works, it does not.
The IE Dev tools, shows a problem with this line: in the custom.js file
Uncaught SyntaxError: Invalid or unexpected token - "TimeAdded": "0001-01-03T00:00:00.000Z"
Any thoughts?
Hi @john_doyle
I suspected that also, and have already tried this. Dev tools shows an error on that line with or without a comma at the end.
I kept the comma at the end, and removed a space after "TimeAdded": and it is now working.
Thanks for your quick response. Hopefully this helps others.
Mike
Glad to hear it is sorted.
Is this being used with the 9.4.11? Looking to implement this into Dev to test it. Not getting much luck so far from following the install instructions. MP in, PowerShell run ok and code added to .js file
Could you assist with removing the ability to lock work items for a specific role, End Users.
I have it applied to our analysts role, but do not want the end users to have this ability, it has been causing issues where they keep the incidents locked all day, and we cannot make changes to the incident.