Exclude standard changes from Maintenance Window
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
09-09-2016 06:54 AM
Not sure how to ask this question so best I can do is explain what is happening and why I want to change it. We are upgrading to Helsinki and are planning on utilizing the new automated collision detection. This comes with a Conflict Status field and an embedded list of any conflicts found. What we are realizing is, Standard Changes are being shown as a conflict for the CI being outside the Maintenance Window and could confuse our users. We made a decision in the past that Standard Changes can be done at anytime with no regard to the maintenance window because they are so low risk, low impact, and history of success. Our goal is to find a way to not have conflict detection check the maintenance window if the change type is Standard. Are only other option is to hide the Conflict Status and embedded list is the type is Standard. This last resort option would hide all conflicts which is fine, but could hold value for other conflicts.
Here is the Conflict Status field
Here is the embedded list
I think my question is: Where can I find the properties for when to check a Change against the Maintenance Window, and can we have it bypass that check if the type is Standard?
Thanks in advance for any feedback
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
05-03-2024 10:22 AM
As stated above, you create a new script include named "ChangeCheckConflicts", and overload the desired function with your desired logic. Follow @chrishenson advice. You'll need to add the ' _getChangesWithCommonCIs' function in your script include with your desired logic.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
05-07-2024 03:45 AM
Hopefully you won't have to create ChangeCheckConflicts. It's the customisable extension of ChangeCheckConflicsSNC we provide OOB and what we call from our code.
You'll find in a lot of cases we provide a read only 'SNC' suffixed version of the script include and a non-SNC read/write version. This is how we allow the customer to own specific elements of the code and not need to take ownership of it in entirety.
Also, you'll always be able to view the OOB code also by viewing the *SNC Script Include.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
05-07-2024 05:08 AM - edited 05-07-2024 07:36 AM
Thanks
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
05-07-2024 06:45 AM - edited 05-07-2024 12:47 PM
That's a bit much to ask, after reviewing the 'ChangeCheckConflicts' script include as mentioned by @chrishenson. It is not clear what to change there so conflict detection is not done for "Standard" CHGs. I suggest you find some consultant to help you with your requirement.
Seems you want different behavior for a 2nd CHG for the same CI and the 3rd CHG for the same CI. I fail to understand why the template used or which user created the CHG.