IT Monkey:   Click Here to Help Me Build the Agenda for Upcoming Cireson Webinars!

Hiding templates from showing?

Suleyman_OzdenSuleyman_Ozden Customer Advanced IT Monkey ✭✭✭

Anyone found a way to hide templates from showing when creating a new Work item?


In my case, I am looking to hide all the built-in Change Request templates from showing, as I am creating my own templates.

I know I can delete the built-in, but is there a way to avoid it?  

Best Answers

Answers

  • Suleyman_OzdenSuleyman_Ozden Customer Advanced IT Monkey ✭✭✭
    Ok, I am not able to change that for the built-in user roles it seems.
  • Jaime_PalazuelosJaime_Palazuelos Partner IT Monkey ✭
    I have written a short function to hide for everybody the templates we want to hide. As you can see, you just need to add the title to the array on the top. Hope this helps, it is not as powerful as the user roles option, but very simple.

    var arrHideTemplates = [
                    //Incidents
                    'Generic Incident Request',
                    'Incident portal template',
                    //Service Requests
                    'Default Service Request',
                    //Problem
                    'CiresonDefaultProblem',
                    //Change Request
                    'Publish Offering'
                ]           

    $(function() {
      var observer = new MutationObserver(function(mutations) {
        $(".templatename").each(function(){
            for(var i=0; i < arrHideTemplates.length; i++){
                if($(this)[0].firstElementChild.outerText == arrHideTemplates[i]){
                        $(this).hide();
                }
            }   
        })
      });
      var target = document.querySelector('.drawerdetails-actions-box');
      observer.observe(target, {
        attributes: true
      });

    });

  • Justin_WorkmanJustin_Workman Cireson Support Super IT Monkey ✭✭✭✭✭
    @Jaime_Palazuelos This is great!  I've had several customers ask for something similar.  Anyone else tested this out?  I'm going to try it out in my lab as soon as I get a chance!
  • Jaime_PalazuelosJaime_Palazuelos Partner IT Monkey ✭
    I have written that this morning, works fine for me. I am working with version 8.1 of the Portal, but I guess this has not changed for a while.
  • Tom_HendricksTom_Hendricks Customer Super IT Monkey ✭✭✭✭✭
    I think this has been stated elsewhere, but I want to point out that while @Joe_Burrows is absolutely correct, this approach has a significant performance implication to it.  If you have an over-built environment, then go for it and stop reading my comment.

    Otherwise, setting the user role to see all templates and using a script such as this one from @Jaime_Palazuelos could help your page loads and saves stay performant.  It seems counter-intuitive that allowing more templates through would help performance, but in doing so you are reducing the scans that occur in the DB, and the amount of text going across the network is negligible by comparison.

    Ideally, this would just work using user roles, how the product was meant to be used, rather than requiring an absurd amount of processing power to determine if a user should see a template or not, but that appears to be the state of things.
  • Jaime_PalazuelosJaime_Palazuelos Partner IT Monkey ✭
    We agree, user roles is a better approach. However, the purpose of this function is to hide the templates I could not delete from the OOTB Management Packs, as you can see there are just 5, and at least myself I could not see any performance issue. It would be very different if we would be talking here about 40 templates. This is a workaround, we know that sometimes retrieving the information from the customers about the AD groups that are going to be related to the user roles is not easy.
  • Tom_HendricksTom_Hendricks Customer Super IT Monkey ✭✭✭✭✭
    I can only speak for myself, @Jaime_Palazuelos, but I took your intent the way you just described it.  :) 

    I merely wanted to point out another way that this could be helpful.  For context, I have about 300 templates, and it has a noticeable performance impact.  Back when we used to have significantly fewer, I did not notice any performance issues from scoping objects to user roles, either.
  • Brian_WiestBrian_Wiest Customer Super IT Monkey ✭✭✭✭✭
    I have attempted user roles approach. The down side is that if you remove a template from the user role for an analyst but then provide them access to a service catalog item that uses that template when they submit it will fail. Thus to provide them access to the service catalog items they must have the template access. That runs into my issue where analysts will fill out the template and not the catalog request messing up data mapping and reporting. This is why I submitted a feature request to tag templates to "hide" them from the portal. 
    https://community.cireson.com/discussion/2487/ability-to-tag-templates-to-be-available-or-not-via-the-analyst-portal

    For the solution above the down side with my 300 templates that would be a lot to update in the list when specifying the template name. (It does help with the OOB templates you cannot change the name)

    So taking content from the other post I added the variable option from it to the above coding and it works on removing tagged templates.

    $(document).ready(function () {
        var observer = new MutationObserver(function (mutations) {
            $(".templatename").each(function (index) {
                var tplName = $(this).children('strong');
                if (tplName[0].innerText.match("-WF")) {
                    $(this).parent('tr').eq(0).hide();
                }
            });
        });

        var target = document.querySelector('.drawerdetails-actions-box');
        observer.observe(target, {
            attributes: true
        });
    });

    This example looks for -WF in any template name to hide it. My testing shows that it appears the error presented from the other post clears in IE.
  • Jaime_PalazuelosJaime_Palazuelos Partner IT Monkey ✭
    Nice!!
  • Brian_WiestBrian_Wiest Customer Super IT Monkey ✭✭✭✭✭
    Rats spoke a little too soon. Error is present but intermittent now. Happening one time out of 5-10 new page loads. Seems if your session has expired it happens. but if you have a session connect it works fine. 
  • Nick_FlintNick_Flint Customer Advanced IT Monkey ✭✭✭
    This only seems to hide the template from the initial load. Pressing enter in the templates search box displays all templates.
  • Tom_HendricksTom_Hendricks Customer Super IT Monkey ✭✭✭✭✭
    That was true of the original version, but the latest (about 2 comments above this) should remove them each time the list updates.
  • Nick_FlintNick_Flint Customer Advanced IT Monkey ✭✭✭
    I'm running portal version 8.6.1 in my Development environment and 8.2.1 in my Production environment; it hides them initially; but pressing the enter key in the 'Filter Templates' box displays all templates. That's using the code from @Brian_Wiest above dated October 2017.
  • Tom_HendricksTom_Hendricks Customer Super IT Monkey ✭✭✭✭✭
    I have a version of this in my environment and it correctly hides templates as you would expect it to.  I did alter the logic a bit to pick from a list of allowed prefixes rather than having just one, but I do not recall making any other changes.  It was a long time ago however, so it's possible that I did.  Here is the scrubbed version of what I have:

    // Remove templates that do not match a list of acceptable prefixes.  Assumes that all templates are prefixed.
    function removeTemplateRows(grid) {
        // List of acceptable prefixes for templates that will show on the page - USE DOUBLE ESCAPE CHAR FOR ASTERISK!
        var okPrefixes = ["IR:", "SR:", "CR:", "PR:", "RR:", "YourOwnPrefixHere:"];
     
        var rows = grid.tbody.children('tr');
     
        // Gather the non-matching rows in a collection
        var rowsToDelete = rows.filter(function () {
            // Use EITHER textContent or innerText for browser compatibility
            var label = $('td', this).children('strong')[0].textContent || $('td', this).children('strong')[0].innerText;
     
            var exp = new RegExp('^' + okPrefixes.join('.+|^') + '.+', 'gi');
     
            // Reverse logic--return the rows that do not match
            return !(label.match(exp))
        });
     
        // Delete the rows from the dataset and the grid
        grid.removeRow(rowsToDelete);
    }
     
    // Remove unmatched templates on each subsequent databind
    function templateGridDataBound(e) {
        removeTemplateRows(e.sender);
    }
     
     
    var observer = new MutationObserver(function (mutations) {
        // The template list grid
        var grid = $('div.drawerdetails-fromtemplate table[data-kendo-control="grid"]').data("kendoGrid");
     
        if (typeof grid !== "undefined") {
            // This will do nothing if the grid is undefined
            removeTemplateRows(grid);
     
            // Check to see if the kendo binding has occurred yet and if so, check to see if this event is already bound.
            if (typeof grid._events["dataBound"] === "undefined") {
                // Once this object is found and the new event is added, stop observing.
                //observer.disconnect();
    
                // Bind this function to the onDataBound event of the template list
                grid.bind("dataBound", templateGridDataBound);
            }
        }
    });
     
    var target = document.querySelector('.drawerdetails-actions-box');
    observer.observe(target, { childList: true });

Sign In or Register to comment.