CA Service Management

 View Only
Expand all | Collapse all

Transferring Incidents in 14.1.02

  • 1.  Transferring Incidents in 14.1.02

    Posted Jan 27, 2016 10:56 AM

    Hi Community,

     

    We recently upgraded to 14.1.02 and one of the annoyances voiced by our users was the fact that in the Transfer activity you need to remove the Assignee before you can change the group.  This adds a bit more clicks to what should be a simple task.

     

    Is there an easy way to force the Assignee value to be blank when opening up the Transfer activity?  Or perhaps there's a better way to do this that I haven't thought about?  Any advice is appreciated, thanks!



  • 2.  Re: Transferring Incidents in 14.1.02

    Posted Jan 27, 2016 11:37 AM

    In my SDM 14.1.02, when I select New Group and it returns a value then the New Assignee field is automatically blanked.  I have made some Option Manager changes since starting it but none that I can think of that effects this behavior and no changes to xfer_esc_cr.htmpl.

     

    Curious.

     

    J.W.



  • 3.  Re: Transferring Incidents in 14.1.02

    Posted Jan 27, 2016 11:46 AM

    Hi J.W.

     

    As part of the Group/Assignee inter dependency update only Groups the Assignee belongs to are listed in the Group field..  Until Assignee is blanked out.  When I click New Group it adds the following filter in additional arguments, restricting the Group view.

    (member_list.member IN ( U'010101010101' ))



  • 4.  Re: Transferring Incidents in 14.1.02

    Posted Jan 27, 2016 12:17 PM

    Alright, I may have skirted your use case because I had only one active Group with a member at the time I started this.  When I opened an existing Incident with a Group and Assignee and selected Transfer, there was no other Group available from the search.  So, I did a Create New from that screen and just saved it with a name - no members.  When I selected this group and it back-filled to the Transfer screen, the previous Assignee was blanked out.

     

    After creating that second Group, it does behave as you describe.  My normal usage, and I think most users, is to start typing in the New Group field and have the auto-suggest come up or else just complete the field.  This is now filtered out using the current assignee and so all Groups are not returned.  This is working as designed as I see it.

     

    My workaround would be to move the Assignee field to before the Group (adjust the tabbing sequence as needed) so that if you need to clear the Assignee first you can clear it and then tab to the Group field.  At that point, the filter is cleared.  Not a complete solution but it does eliminate tabbing past the Group field, blanking the Assignee, SHIFT-TAB back to the Group and continuing.  A couple of keystrokes saved.

     

    If you do want to keep the current Assignee, just tab past it and the filter will still be active.

     

    Just off the top of my head.  There may be better solutions.

     

    J.W.



  • 5.  Re: Transferring Incidents in 14.1.02

    Posted Jan 27, 2016 12:29 PM

    Thanks for the tip, I'll keep this one as an option.  I wouldn't mind adding a customization to get the Assignee to blank out.  I was dabbling with the following JavaScript function and couldn't figure out how to get it to get it to blank Assignee once Group is selected.  The following function will blank out the Assignee once the input is moved to the Assignee field.

     

    Function

    function clearField(input) {
        input.value = "";
    }
    

     

    Assignee field

    <PDM_MACRO name=dtlLookup hdr="New Assignee" attr=assignee evt="onBlur='clearField(input)'">



  • 6.  Re: Transferring Incidents in 14.1.02

    Posted Jan 28, 2016 04:42 PM

    To be clear, you want the New Assignee field to blanked (set to empty string) when you first enter the NEW GROUP field or NEW ASSIGNEE field?  Your description says on selecting Group but your code snippet is for Assignee.

     

    J.W.



  • 7.  Re: Transferring Incidents in 14.1.02

    Posted Jan 28, 2016 04:53 PM

    Hi J.W.,

     

    Yes I was trying to figure out how to clear Assignee once Group was selected.  I could't figure out how to extend that JavaScript to clear out additional fields.



  • 8.  Re: Transferring Incidents in 14.1.02

    Posted Jan 28, 2016 06:43 PM

    Is there any case where you don't want to the clear the Assignee?  If not then we can just clear the field when the form loads.

     

    J.W.



  • 9.  Re: Transferring Incidents in 14.1.02

    Posted Jan 28, 2016 06:48 PM

    I can't think of any cases where we don't want the Assignee cleared.  Because you have to clear it when changing groups and if you're changing assignees then it's still one less click.



  • 10.  Re: Transferring Incidents in 14.1.02

    Posted Jan 28, 2016 09:39 PM

    Alright then, try this:

     

    In the "xfer_esc_cr.htmpl" file, Add this function just before the end of </script> before </head>

     

    function clearAssignee() {

       document.getElementsByName("assignee_combo_name")[0].value = '';

    }

    (those are 2 single quotes '' and not a single double quote ")

    then add ;clearAssignee() to the list of functions called onload in <body>

     

    Excerpt shown here.

    ....

    function clearAssignee() {

       document.getElementsByName("assignee_combo_name")[0].value = '';

    }

    </script>

    </head>

    <body onload="load_from_scratchpad('0');initApcForNewTicket();setFieldsForCapReasonAsync();clearAssignee()" onunload="clearParentResumeAction();unload_check()" class="editform">

    <PDM_INCLUDE FILE=std_body.htmpl>


    ...

     

    Now, whenever the page loads the Assignee field should be blanked.

     

    Let me know if this works for you.  Since the 'New Assignee' field's id can be different based on several conditional checks depending on options, I didn't get to check this for all scenarios.

     

    J.W.



  • 11.  Re: Transferring Incidents in 14.1.02

    Posted Jan 28, 2016 10:02 PM

    That's not working.  The filter is still in place on Group until the first time you enter a value there; afterwards it checks the assignee field again and sees it is blank.  I'll look into further but it may be a while.

     

    Thanks,

     

    J.W.



  • 12.  Re: Transferring Incidents in 14.1.02

    Posted Jan 29, 2016 03:01 AM

    gbruneau

     

    I don't seem to get such behavior with OOTB functionality. Is there some customization (spel-code or JavaScript) that you put in place to enforce the Assigee field to show only members of the group? If not, I would suggest you log a Support case to debug this for you in case you have not done so already.

     

    Kind Regards,

    Brian



  • 13.  Re: Transferring Incidents in 14.1.02

    Posted Jan 29, 2016 08:49 AM

    Hi Brian,

     

    I'm pretty sure this is expected behavior. Check the Assignee/Group interdependent enhancement for 14.1.02.

     

    Here is a better explanation of the issue..

     

    1. Setup two groups with separate group members.
    2. Create an incident and assign it to group 1 and set the assignee then save.
    3. Open the transfer activity on this incident, you'll notice that you cant select group 2 unti you clear the assignee field.

     

    Let me know if you still don't experience this behavior.. The only not ootb group / assignee change we have implemented is the nx variable to change location based routing to group only.



  • 14.  Re: Transferring Incidents in 14.1.02

    Posted Jan 29, 2016 10:42 AM

    Hi J.W.

     

    Thank you for providing this code!  It appears to do exactly what we're looking for.

     

    cdtj and Brian_Mathato this enhancements page lists the Group/Assignee inter dependency update that we're talking about.  It applies to all Group/Assignee fields.

    CA Service Management Release 14.1.02 Enhancements - CA Service Management - 14.1 - CA Technologies Documentation



  • 15.  Re: Transferring Incidents in 14.1.02

    Posted Jan 29, 2016 11:09 AM

    You're welcome!

    Let me know if you see any 'lag' in that the filter is still applied when you first enter the New Group field; I had to tab out and back in for it to recognize that assignee was cleared.

     

    it also occurred to me that if your business case does not ever require the Assignee to be a member of any Group then the 'Any Contact' option under 'Request-Change_Issue' in Options Manager might also resolve this.  However, this means someone could also put an Employee or Customer as an Assignee.

     

    J.W.



  • 16.  Re: Transferring Incidents in 14.1.02
    Best Answer

    Posted Jan 29, 2016 11:47 AM

    @Grant Bruneau had the better solution and I am adding it here.@

    ///////////////////////////

    Adding onto this customization I found that adding the following pdm_set before the assignee attribute will clear the additional search filter on Group.

     

    <PDM_ELSE>  
    <PDM_SET args.assignee=''>  
    <PDM_MACRO name=dtlLookup hdr="New Assignee" attr=assignee>  
    </PDM_IF>
    
    

     

    /////////////////////////////////

    (Original Response)

    If you want to clear BOTH the 'New Group' and 'New Assignee' fields then use this function:

     

    "xfer_esc_cr.htmpl"

    function clearGroupAndAssignee() {

      document.getElementsByName("assignee_combo_name")[0].value = '';

      document.getElementsByName("group_combo_name")[0].value = '';

    }

     

    </script>

    </head>

    <body onload="load_from_scratchpad('0');initApcForNewTicket();setFieldsForCapReasonAsync();clearGroupAndAssignee()" onunload="clearParentResumeAction();unload_check()" class="editform">

    <PDM_INCLUDE FILE=std_body.htmpl>

     

    This definitely worked for me as now there is no Group for a filter to be applied.

     

    J.W.



  • 17.  Re: Transferring Incidents in 14.1.02

    Posted Jan 29, 2016 12:03 PM

    Thank you J.W. you've been very helpful!!



  • 18.  Re: Transferring Incidents in 14.1.02

    Posted Jan 29, 2016 12:34 PM

    Hi J.W.,

     

    Adding onto this customization I found that adding the following pdm_set before the assignee attribute will clear the additional search filter on Group.

     

    <PDM_ELSE>
    <PDM_SET args.assignee=''>
    <PDM_MACRO name=dtlLookup hdr="New Assignee" attr=assignee>
    </PDM_IF>
    


  • 19.  Re: Transferring Incidents in 14.1.02

    Posted Jan 29, 2016 12:40 PM

    Even better!

     

    J.W.



  • 20.  Re: Transferring Incidents in 14.1.02

    Posted Jan 29, 2016 09:50 AM

    Hi Grant,

     

    are your goal described in first post still actual?

    If yes, could you provide original file of xfer_esc_cr.htmpl, because i'm still on 12.7 and haven't issue like this...

     

    Regards,

    cdtj



  • 21.  Re: Transferring Incidents in 14.1.02

    Posted Jan 29, 2016 10:19 AM

    Hi cdtj,

     

    Yes we still have the same goals.  I haven't tested J.W. javascript yet, that may work for us as we typically transfer using auto suggest and not by opening/searching list_cnt.  Our xfer_esc_cr.htmpl file is very close to OOTB, the only thing that we have changed is forcing the Internal flag to be set by default.



  • 22.  Re: Transferring Incidents in 14.1.02

    Posted Feb 05, 2016 01:16 AM

    I would want CA to do completely something else with Transfer.

     

    When you open Transfer window, you do your things, and upon pressing Save it should check, if the fields New Group and New Assignee are the same or have changed. If they're the same, don't allow to Save. In such a way there's not going to be an annoying problem that you Transfer, but actually a ticket stays with you.



  • 23.  Re: Transferring Incidents in 14.1.02

    Posted Feb 08, 2016 04:37 PM

    We have the same issue since upgrading to 14.1. Support center analysts hate how this function is designed now. Edited the xfer_esc_cr.htmpl with the group/assignee code and still doesn't solve the problem for us.



  • 24.  Re: Transferring Incidents in 14.1.02

    Posted Feb 08, 2016 04:45 PM

    Hi sconnolly,

     

    I'll share the contents of my xfer_esc_cr.htmpl file.  It may not have been clear what to add with all the back and forth in this thread.  You can use a comparison tool like beyond compare to see what differences are in this verses the default.

    Note: I'm not sure how to add attachments.

     

    Let me know if you still have problems after creating a new file with this code.

     

     

    Edit: It dawned on me that we might not be aloud to share whole files?  Can someone confirm?  I've posted the specific sections with updated code below..

     

    Assignee field section (Added the pdm_set control)

    <PDM_IF "$env.NX_REQUIRE_REQUEST_ASSIGNEE" == "Yes">
    <PDM_MACRO name=dtlLookup hdr="New Assignee" attr=assignee make_required=yes>
    <PDM_ELSE>
    <PDM_MACRO name=dtlLookup hdr="New Assignee" attr=assignee>
    </PDM_IF>
    <PDM_ELIF "$args.type" == "I" && "$env.NX_REQUIRE_INCIDENT_ASSIGNEE" == "Yes">
    <PDM_MACRO name=dtlLookup hdr="New Assignee" attr=assignee make_required=yes>
    <PDM_ELIF "$args.type" == "P" && "$env.NX_REQUIRE_PROBLEM_ASSIGNEE" == "Yes">
    <PDM_MACRO name=dtlLookup hdr="New Assignee" attr=assignee make_required=yes>
    <PDM_ELSE>
    <PDM_SET args.assignee=''>
    <PDM_MACRO name=dtlLookup hdr="New Assignee" attr=assignee>
    </PDM_IF>
    var assignee_id = _dtl.currID;
    
    

     

    Clear Group and Assignee code (Added the function just before the end of the script block and configured it to fire onload)

    function clearGroupAndAssignee() {
      document.getElementsByName("assignee_combo_name")[0].value = '';
      //document.getElementsByName("group_combo_name")[0].value = '';
    }
    
    
    
    
    </script>
    </head>
    <body onload="load_from_scratchpad('0');initApcForNewTicket();setFieldsForCapReasonAsync();clearGroupAndAssignee()" onunload="clearParentResumeAction();unload_check()" class="editform">
    <PDM_INCLUDE FILE=std_body.htmpl>
    


  • 25.  Re: Transferring Incidents in 14.1.02

    Posted Feb 08, 2016 05:24 PM
    Header 1Header 2

    Grant,

    The 'Attach' link is inside the Reply window at the bottom, right.  Next to 'Mention' and 'App' 

    red_down_arrow.png

     

     

    J.W                                                                                                                                                                                                                                                        



  • 26.  Re: Transferring Incidents in 14.1.02

    Posted Feb 08, 2016 05:27 PM

    Gotcha, thanks!  I guess it's only available once you press "Advanced Editor".  Also I removed the code since I wanted to confirm the entire file is permissible to share.



  • 27.  Re: Transferring Incidents in 14.1.02

    Posted Jan 02, 2017 11:36 AM

    Achieved this by using below function

     

     

     

    create function like below

    ###############################################

    function ClearAssingeeField() {

       document.getElementById(assignee_id).value="";

    ###############################################

     

    call this function

    <body onload="load_from_scratchpad('0');initApcForNewTicket() ;ClearAssigneeField();

    <PDM_INCLUDE FILE=std_body.htmpl>

     

    Add var assignee_id=_dtl.currID; before"NEW Assignee"Field lines like below

     

    <PDM_IF "$args.type" == "R" || "$args.type" == "">

    <PDM_MACRO name=dtlLookup hdr="NEW Assignee" attr=assignee make_required=yes>

    <PDM_ELSE>

    <PDM_MARCO name=dtlLookup hdr="NEW Assignee" attr=assignee>

    var assignee_id=_dtl.currID;

    /PDM_IF>

    <PDM_ELIF "$args.type"=="I" && "$env.NX_REQUIRE_INCIDENT_ASSIGNEE"=="Yes">

    <PDM_MACRO name=dtlLookup hdr="NEW Assignee" attr=assignee make_required=yes>

    var assignee_id=_dtl.currID;

    <PDM_ELIF "$args.type"=="P" && "$env.NX_REQUIRE_PROBLEM_ASSIGNEE"=="Yes">

    <PDM_MACRO name=dtlLookup hdr="NEW Assignee" attr=assignee make_required=yes>

    var assignee_id=_dtl.currID;

    <PDM_ELSE>

    <PDM_MARCO name=dtlLookup hdr="NEW Assignee" attr=assignee>

    </PDM_IF>

    var assignee_id=_dtl.currID;