Replace Assigned To & Support Group fields with Cireson Assign To Analyst By Group fields in portal

Ryan_Kennedy

Hello,

I am wanting to replace the Assigned To & Support Group fields in the Incident and Service Request forms on the portal with Cireson Assign To Analyst By Group fields in portal.

I've managed to just disable the default fields and require analysts to use the link in the task pane, however I'm wondering whether anyone has a way to completely replace the fields so that the default form forces you to assign to an analyst from a specific group?

Any help would be appreciated.

Thanks

Geoff_Ross

Hi Ryan,
You would need to trigger code on the change of support group that took the value of support group selected, and used api/V3/User/GetSupportGroupUsers?id={id} to bring in a list of users in that support Group. Then filter the 
Assigned To search box to only those users.
Geoff

Tom_Hendricks

I think this could use some refactoring and would like to add functionality for CR and MA work items when the Support Group customization for those is in place, but here is a scrubbed version of what I have tested on portal 7.2.2016.1.

Note that in my custom.js, I selectively only load this code when the current page is a work item form, so if you see errors on other pages, it may be due to the fact that my code assumes it is running on a ticket form.

Please let me know of any issues or suggestions to enhance it.

Geoff_Ross

Hi Ryan,
You would need to trigger code on the change of support group that took the value of support group selected, and used api/V3/User/GetSupportGroupUsers?id={id} to bring in a list of users in that support Group. Then filter the 
Assigned To search box to only those users.
Geoff

Ryan_Kennedy

Thanks Geoff

Tom_Hendricks

I wanted to comment on this, because @Geoff_Ross turned out to be absolutely correct.  My users asked for this same feature (starting by asking to have the analyst by group window pop up on SG change, then realizing they hated that in practice).  This indeed was the best way to deliver the feature, but although the code looks straightforward now that it's done, it was not the easiest to put together, IMO.

Being a KendoUI master (which I am not!) is nearly a prerequisite--the inconsistencies among their controls can be maddening, especially since the controls are wrapped with other elements from Cireson.  However, it works spectacularly once everything is referenced correctly.  Their API is available online and I suggest keeping it open at all times. 

If there is interest, I may be able to share a generic version of the code.

Leigh_Kilday

Tom_Hendricks said:

I wanted to comment on this, because @Geoff_Ross turned out to be absolutely correct.  My users asked for this same feature (starting by asking to have the analyst by group window pop up on SG change, then realizing they hated that in practice).  This indeed was the best way to deliver the feature, but although the code looks straightforward now that it's done, it was not the easiest to put together, IMO.

Being a KendoUI master (which I am not!) is nearly a prerequisite--the inconsistencies among their controls can be maddening, especially since the controls are wrapped with other elements from Cireson.  However, it works spectacularly once everything is referenced correctly.  Their API is available online and I suggest keeping it open at all times. 

If there is interest, I may be able to share a generic version of the code.

Yes please!

Tom_Hendricks

I think this could use some refactoring and would like to add functionality for CR and MA work items when the Support Group customization for those is in place, but here is a scrubbed version of what I have tested on portal 7.2.2016.1.

Note that in my custom.js, I selectively only load this code when the current page is a work item form, so if you see errors on other pages, it may be due to the fact that my code assumes it is running on a ticket form.

Please let me know of any issues or suggestions to enhance it.

Leigh_Kilday

Thanks Tom. I'll see if I can test this in our next sprint.

Ryan_Kennedy

Thanks heaps for that Tom.

I tried it out on the V7.3 portal and seems to work alright.

Seems to be a little fidgety when you select a support group and it automatically selects the first assignee in the list .. But other than that works well

I look forward to updates to the MA / SR forms in the future if you happen to complete that enhancement.

Thanks

Tom_Hendricks

Glad it helps!  I agree that it's fidgety, but that's what my users wanted.  There is a .focus() call on the assignee field that you can remove if you just want it to quietly filter the list in the background.

I will send an update after we roll out support groups in the other work items.  (Or maybe someone else will make the attempt first?)

Brian_Wiest

@Tom_Hendricks
Any luck with the "fidget" issues?
My management wants to implement this type of function in the portal. (Too many assigned tickets to specific users but support groups are wrong)
The only stop gap I see right now in implementation is the fact on focus it chooses the first entry and you have to back space it to get the entire membership.
Thanks.

Tom_Hendricks

I haven't really changed it on my end.  I forgot about this thread because honestly, we are all used to it now and it has not been reported as an issue.

As I mentioned earlier, you can prevent the list from opening on its own (which I believe is what causes the first item to become selected, but I have not tested it in any other manner) by making a couple simple changes:

On lines 20 and 45, change this: var fldAssignee = $("input[name='Assigned'WorkItem']").on("focus", function() { openAssigneeSearch(); });

to this: fldAssignee = $("input[name='Assigned'WorkItem']");

This stops the list from automatically appearing.  Our project team wanted that, your users may not.  (There are many other ways to guide someone to fill in the field, after all.)  The result should be that the list is filtered behind the scenes.  I have not tested this in my environment, however.

Gerhard_Goossens

What I did was to disable the editing of the Support Group and Analyst in the IR and SR forms.

This was done by copying the Incident.js and and ServiceRequest.js to my CustomSpace folder and makking the following changes:

For anyone not familiar with the .js structure, here is a quick overview.

The files are structured according to the tabs you see on the portal page and this is indicated by the /** TAB **/ comment lines. If you go the the General tab, you will see the structure of the General tab, If you go down to the "columnFieldList" that has the "TierQueue" and "AssignedWorkItem" you can disable the control by adding "Disabled: true" before the closing }.

It will still display in the poral, but you cant select the Support Group or the Analyst. This will force the Analysts to use the "Assign To Analyst By Group" Task and thus ensuring that the correct Support Group is selected for the Assigned Analyst.

I also used this method to disable the affected user and the Title of the IR. (We have sneaky people that change stuff to bypass some procedures...)

Here is what I did with both the Incident.js and ServiceRequest.js files. 

Incident.js


ServiceRequest.js


And the end result will look like this:


As you can see the Support Group and the Assigned to has been greyed out and cant be changed. This field will update if the "Assign To Analyst By Group" task is used. I have not noticed any strange behaviour by applying the solution.

Below is a screenshot of the complete form, I have added a custom tab to allow me to change what is displayed for this template. It is still a work in progress...



Ok, that is it, please let me know if I missed something or if you have any other suggestions.

G

Tom_Hendricks

@Gerhard_Goossens, I like this approach.  This was our initial approach, but I had to abandon it when my users said that they wanted to keep their hands on the keyboard and not click the task to do this.  In all other ways, I think what you have described here is the better solution.

Brian_Wiest

With the help of team member were able to update the code from @Tom_Hendricks It removes some of the "fidgets" Making the assign to a more consistent drop down.

Tom_Hendricks

This definitely does make the controls less "fidgety" (this is a good improvement!) but has introduced some oddities with the styles.  For example, the assignee field still looks disabled after the list has been filtered, even though it is enabled.  After typing a value, then the assignee field always appears enabled, even when the support group has been cleared.

This seems easier to fix, and if I am able to devote time to fixing that I will post the fix here.  Please feel free to beat me to it, however. 

Tom_Hendricks

I need to amend my most recent comment.  While true, it appears that the CSS oddities are only occurring when the assignee has a value but the support group does not--a scenario that cannot even exist in my QA environment or above.  I would guess that most others may not even encounter it, and it does not need to be addressed.

Alan_Foster

I have a scenario where I would like to change the support group but not assign a user, or when the support group changes the Assign to is blanked out so that someone in the support group can accept the incident. Is this possible? @Tom_Hendricks, @Brian_Wiest, @Gerhard_Goossens

Gerhard_Goossens

You can use the solution above, I use for exactly the same reasons. This solution also ensures that something is not assigned to an analyst that is not part of the specified support group.

Alan_Foster

@Gerhard_Goossens , I have applied the settings in the Incident.js and it works as stated.
What I would like to happen:
1. An incident is already assigned to a support group and an assigned to user
2. Change the support group and remove the original assigned to user so that a member of the new support group can assign the incident.  
currently, the original assigned to  user is still assigned if you only choose to reassign the support group.

Gerhard_Goossens

Ohn no, please excuse me. It seems like I'm full of cobwebs.

I used the code I posted above with the screenshots and another one I found in the community...

https://community.cireson.com/discussion/46/assign-to-analyst-by-group

This combination allows me to select a new support group via "Assign to analyst by group" and if I do not select a user in the drop-down, it clears the assigned to user. This will work if the assigned to uses field is populated or not. It also disables the assigned to and support group on the form to force users to use the assign to analyst task.

I use this solution to force the analysts to change the assigned to user when selecting a new support group.

Alan_Foster

@Gerhard_Goossens I just found @Nicholas_Velich post that you reference, too.  Thank you.

Brian_Wiest

FYI v9.0.6.2016 Broke this customization. Have yet to figure it out. But the symptom is that clicking the user seems to be selecting as null as the assigned to reports no entry was set. Dev tools showing no errors.

Tom_Hendricks

I don't have a solution, but I think I at least found the problem.  The change event is not triggering on enum controls anymore.

Perhaps there is some other way that it needs to be bound now, but the code simply isn't running other than that very first call when the form loads.  Thus far, I have tried 4 different ways of trying to bind to a change event, but none have worked.  Not sure what changed here.

Update/Edit: It is not that the change event isn't firing so much as the bindings to the change event are failing.  If I bind using this syntax, after the page has loaded and long after boundReady for the form is done, then the code works normally: pageForm.viewModel.bind('change',function () { //do stuff here }, "TierQueue");

So this is apparently a timing and a syntax issue, due to something that has changed in the recent versions.

Edit 2 (am I liveblogging now?): This is beginning to make a little sense.  Apparently in the past, it has been possible to cumulatively add event handlers, but not any longer.  If I remove all formObj.BoundChange and ...bind('change' fn() {}) calls from my code, then just add one back in.  It works.  Anything I put in there will run.  But if I bind another function to it after, that 2nd function doesn't work.

In my case, I have multiple files that all bind to the same field's change event.  Reorganizing these different functions to be called from the same place seems to be the way to get this (and other things) to work, unless a significantly less annoying option presents itself.

Brian_Wiest

To updated everyone v9.1 this was fixed so the original scripts above work again.

Gabriel_Lences

This customization broke for us in 9.7.0. in Incident forms, it worked up until 9.6.0 flawlessly for SR's and IR's , but since 9.7.0, this only works for SRs in our test environment :(

Hopefully Cireson will implement this as an OOB feature (for CR,PR and Activity forms as well) soon.

Already voted the thread over here.

Regards,

G.

Gabriel_Lences

Edit: Seems to be working again in 9.8.2 for newly created incidents, but for those that were created during 9.7.0 it's seems to be broken. We're still testing it only in our lab environment, so it's safe though, just wanted to give an update

Edit 2: Found the issue which was causing this , in our lab env. we had a few incidents starting with IM (from our old system) and for these it doesn't work, the code works with "IR", sorry for overlooking this :)

Gabriel_Lences

Anyone who'd be willing to update the code to also work with Support Groups of Change Requests, Problems & Manual Activities? (https://community.cireson.com/discussion/4963/manual-activity-change-request-and-problem-support-group-lists) 🙏

Shane_White

(Made an Edit to this)

Here is a working version in 10.5.1, please note the following changes:

1. Changed the way we determine the Support group field to be based on the pageForm.viewModel.FullClassName, this is a better way of doing it compared to the previous which was based on the work item id and taking a substring, but if you didn't have IRXXXX, but has INCXXXX, it would not work
2. I found a bug where if you selected an Assigned User, then clicked away, click back in the box it would wipe the assigned user and this is fixed now
3. Cleared all console.logs for cleanness
4. Tidied up the code a little in terms of formatting
5. Abstracted some of the code to avoid repeated code blocks

custom_FilterAssignedToBySupportGroup.txt

Hope this helps!