[sbruce1]

Hi Nina,

Regarding your first point, I think it would be possible, however there are some problems you may need to consider. Revisiting the dxATGetUsersForItemDB analytic which drives the elements of the dropdown, it would be possible to do a lookup based on a config that links the username to display name and return the display name for the dropdown. Something like this:

dxATGetUsersForItemDB:{[itemID;dt] isHDB:not null dt; itemID:”j”$itemID; alert:$[isHDB; value last select from dxATItemCurrent where date=dt, dItemID=itemID; last select from dxATItemCurrent where dItemID=itemID ]; AT:alert`actionName; ATQ:alert`queue; // POINT 2 // Error trapped as keys for sender/receiver may differ, also this analytic is used in the financial AT users_to_exclude:$[all null ue:raze alert[`data]`sender`receiver;`;ue]; // Get users permissioned on the action tracker permissioned_users:exec users from .at.getActionUsers[] where .pm.chk'[users; .pm.entityname[AT; `actiontracker]; `select]; // POINT 3 // Get users permissioned for the current queue //permissioned_users:exec users from .at.getActionUsers[] where .pm.chk'[users; .pm.entityname[ATQ; `actionqueue]; `select]; permissioned_users:permissioned_users except users_to_exclude; username_displayName:.uc.getActiveParamValue[`USERNAME_DISPLAYNAME;`]; :raze exec displayName from username_displayName where like[username;]each permissioned_users }

You would need to consider that upon selecting this from the dropdown, the logic that follows is expecting a username. So you would have to map back to the username after the dropdown is selected in one of  (if not all) the dxATTransition* analytics – and potentially more.

Regarding your next point I’m not sure if there is a way to disable the assign to dropdowns and retain the commenting. I’ll look into this further and reach out internally. A possible solution in the interim could be to create groups for the transition endpoints. For example, create a group called Escalated for users who are able to transition the alert from the Escalated queue, and do the same for Closed etc. Then have these groups available in the dropdown, so that a user could simply assign the problem to the group corresponding to the transition’s endpoint.

Alternatively, the option of configuring the “transition analytic to automatically reassign this item to a group or user in the correct group in the event that a user has made an invalid selection from the dropdown” does seem to be a good solution still, in the absence of being able to disable the dropdown while maintaining the comments.

Regards,
Sam B

[sbruce1]

Hi Nina,

Hopefully the following answers your questions:

1. You’re right on the money with individuals being accessible from the dropdown after they’ve been added to the entitlements of the action tracker and are part of the ActionTrackerUsers. There is another analytic that drives this dropdown called dxATGetUsersForItem which queries either the AT or HDB, running the analytic dxATGetUsersForItemDB. We can add logic to this analytic to filter the list of individual users further.
2. The dxATGetUsersForItemDB analytic has the itemID as an argument, so information about the alert payload can be interpreted. Hence we can add a simple except statement at the end to remove the sender/recipient from the dropdown.
3. This issue is slightly more difficult than just modifying the dxATGetUsersForItemDB analytic, as the dxATItemCurrent table doesn’t contain information about the transition. However, it does contain information about the queue, so you could filter by the entitlements regarding a queue using the permissions framework. Another solution if filtering on the queue entitlements isn’t a suitable alternative, is adjusting the logic in the transition action analytic (screenshot provided). Since this analytic is executed upon transitioning, it will contain more information about which queue it’s moving to. So you may be able to reissue the alert if the user isn’t entitled to both queues.

Here’s some code that with a bit of adjusting should solve your second point, and implements the first solution for your third point (although commented out). As for your first point of further refining the available list, since I’m not sure what the further refinements will be based on I haven’t included code for it. However this analytic would be the place you put in those further refinements.

dxATGetUsersForItemDB:{[itemID;dt] isHDB:not null dt; itemID:”j”$itemID; alert:$[isHDB; value last select from dxATItemCurrent where date=dt, dItemID=itemID; last select from dxATItemCurrent where dItemID=itemID ]; AT:alert`actionName; ATQ:alert`queue; // POINT 2 // Error trapped as keys for sender/receiver may differ, also this analytic is used in the financial AT users_to_exclude:$[all null ue:raze alert[`data]`sender`receiver;`;ue]; // Get users permissioned on the action tracker permissioned_users:exec users from .at.getActionUsers[] where .pm.chk'[users; .pm.entityname[AT; `actiontracker]; `select]; // POINT 3 // Get users permissioned for the current queue //permissioned_users:exec users from .at.getActionUsers[] where .pm.chk'[users; .pm.entityname[ATQ; `actionqueue]; `select]; :permissioned_users except users_to_exclude }

Please let me know if you have any follow up questions to this.

Regards,

Sam B