Best Of
Re: Cireson Analytics - get all work items and MAs
All Manual Activities tied to Service Requests...
I think the first suggestion I have is coming at this from a different angle. Rather than Service Request to Manual Activity, do it backwards - Manual Activity to Service Request. The reason I suggest this is that from the Manual Activity table, you can find a column called "Parent Work Item Type"
Thereby enabling you a simple addition to a WHERE clause and yes - Parent Work Item ID is there as well so you can join back up to Service Requests 😁
Re: Work Item History
@Matt_Howard1 - As of 11.5 Analytics technically includes the history, but it's buried in the archived work items.
Re: Automated creation of service requests
Hello,
I attended the Innovate 2022 announcement! :)
I am very excited to use power automate -> however -> Is there an expected release date?
Thank you for replying!
Re: Cache Builder does not run properly
@Steffen_Dobritz - Try stopping the cachebuilder service and giving it about 5 minutes to wind down completely. Then try starting it again.
Re: Change request: Updating "Assigned to" to "Created By" user automatically
@Simon_Zeinhofer Yea that is a personal preference. Each person should decide what works best for their environment. Cutting down the Get objects cuts down on your data reads for the SQL server. If you only have a couple runbooks that is one thing, but if you have hundreds that can add up.
Re: Wildcards in Global Search e.g. '*' or '%'
THIS would be amazing.
especially when searching Hardware or Software Assets, it is necessary to type in the complete name to receive any results :(
Re: Asset Management without Computer Objects
For anyone reading this:
DO NOT DELETE ALL COMPUTE OBJECTS! I did a big mistake and deleted all windows computer objects in a bulk of 1000. Doing this, I deleted the workflowserver computer object as well - My event viewer was full of error messages and all workflows failed. Seems like the functionality of the Workflow server also depends on this computer object.
Snapshot did the trick and everything is working fine again ;-)
Re: Extend incident class. Security
Hello @Sergey_Astashki ,
sure :)
First of all, copy the the Incident.js from inetpub\CiresonPortal\Scripts\forms\templates to your inetpub\CiresonPortal\CustomSpace folder. You can just copy it there or in the WorkItem folder inside the CustomSpace. We did that so we have the CUstomSPace folder itself clean and it is easier to find what you're looking for.
VERY IMPORTANT: DO NOT change or delete the files from the forms\templates folder. If you have any errors inside your custom form, and you don't find the cause, you can still just override it with the OOTB Template and it's working again ;-)
Open the Incident.js file with a text editor. I recommend Notepad++, as the standard editors from Microsoft are garbage for that.
On top of the file you see the following line:
This marks the standard Incident View for Analysts.
If you scroll down to line 179 you see the following:
This marks the standard View for NON-Analysts.
What you have to do now, is to create a new section, at the same hirarchy as the Default and DefaultEndUser.
What I do in such case, I just copy the Default Section completely and paste it at the end of the file.
Be careful to paste it exactly where it belongs, which means AFTER the second last }. Do not forget to add an , after this }
Now rename the section you just pasted to anything you like, I recommend something short like "engineers". Inside this section you can then edit the fields as you wish. Here is the KB Article for that: https://kb.cireson.com/article/how-to-create-custom-forms-for-cireson-portal/51
You can of course also edit the fields inside the Default and DefaultEnduSer section to your needs.
After you have finished your engineers section to your needs, open the portal and go to Admin Settings--> Group Seetings. You will find the following in top:
This is the part, where you assign this engineers Incident form to an AD group.
- Click the Add button on top.
- A new line will appear. In the first column type in the AD group which should have access to the engineers form
- In the second column, type in the Name of the form, in your case engineers.
- The third column is the ordinal number, which is very important if, e.g. you create multiple sections inside the same js file and a user is in more than one of the assigend AD groups. With the ordinal number, you decide, which section will be shown. In our environment we use -1 as the TOP number.
- In the forth column, you have to select the item type. In your case it's incident.
- The fifth column is very important, as the type projection has influence on which relationships you see inside the incident. If you choose the wrong one, you might for example not see the Affected user Relationship anymore. To have all the relationships you could use the Incident (advanced) but I remember we had some troubles when we used this projection in views, so maybe this is not a good idea. "Incident (portal)" is a good one for that. But there are two of these, one which only has the Affected User and one, which has the relationships which are "typical". What I remember the second one is the big one, but oyu will have to test that.
- If you have finished that, click on the Update button on the side, the new form is now added.
- DO NOT FORGET TO SAVE AT THE BOTTOM OF THE PAGE!! ;-)
If the corresponding engineer group has already been "touched" by the cachebuilder, members if the engineers AD group should immediately see the new view when they open an Incident.
I hope this helped :)
Re: Portal base hardware requirments
It means, that there needs to be a SCSM Management Server installed on the same server. This is needed for the login process to work. But it does not have to be the primary management server, you can install a secondary management server on a separate server and then install the website on the same server.
For the Cache Builder and ServiceManagement database (the datebase for the website), Cireson recommends that it is installed on the primary management server, so the SCSM CMDB (ServiceManager database) and Cireson ServiceManagement database are on the same instance. Although this recommendations is for performance reasons, so it's not a requirement.
Re: Custom MPs with extended class showing in all Incident templates, under Extensions?
When you extend a class, it'll propagate that extension to all objects of that class.
Instead, you could inherit from the Incident class, effectively making your own class. And only objects based on that class, will have the specific change. So you can create templates for each, and it'll only show that change. BUT - this is not advisable, as it will add a lot of unnecessary complexity. For example, what if an incident is mistakenly created with Template Printer, so it shows Sea, but it was actually meant to be Template World? You would have no way to change the class, so you would need to close the Printer incident, and then create a new World incident. And there's also a number of peculiarities and things to be aware of, when using inherited classes.
So I would recommend trying to make generic extensions, which can be used for all of your needs, e.g. (field1, field2, datefield1, etc). Then you could present the data from the fields in the description, where you can set a custom/dynamic headline for each field, based on that type of incident it is.