Cannot merge tickets when using employee entity from time clock

Adding them to tickets was optional. I did it for reporting and tracking purposes. You really dont have too I found it easier to use Entities than Users for reports.

Hmm it seems we cant remedy this with automation atm. @emre perhaps we should look at this. Maybe a way to disable that check with specific Entity Type? Like a way to specify a specific Entity Type that is immune from that check when merging tickets?

1 Like

I think this is an amazing result. We shouldn’t allow merging tickets created by different employees.

  1. If we should track it as an employee entity we should transfer all tickets to a single entity. We can detect if we have multiple employees and display a confirmation to move tickets to a single employee.
  2. If we don’t care how they merges we can store employees as ticket tags.
  3. We can store employees as order states.
  4. We may not track employees on tickets at all.

Configuring an exclusive entity type immune to merging does not sounds like a right solution to me as we need to have a single entity at the end. Remember “user switching” request for tickets.

3 Likes

Good points. I will think about it myself for my own flow.

1 Like

I think this sounds like a good option.

1 Like

OK. So I’ll try to implement that automation. I think a small feature might be needed so let me try that implementation. I’ll share details when it is done.

2 Likes

Small start. SQL Script to read employee count on a specific table.

select count(distinct TicketEntities.EntityName) from Tickets
inner join TicketEntities on TicketEntities.Ticket_Id = Tickets.Id
where Tickets.Id in (select TicketEntities.Ticket_Id from TicketEntities where TicketEntities.EntityName = '@1')
and TicketEntities.EntityTypeId = (select Id from EntityTypes where Name = '@2')
and Tickets.IsClosed = 0
2 Likes

So this is the 2nd parameter passed, what is the first and where are this picked off SambaPOS ? Just interested to see how things work in background…

This is how we call supply parameters for SQL Scripts inside custom reports. We call it like

@@SQLHandler:param1,param2

If you scroll horizontally you’ll see first parameter.

However we won’t use that format. I’ll convert it to a JScript Function.

1 Like

This is the script I’m using to read employee count.

function countForTable(entityTypeName,tableName)
{
  var sqlc = "select count(distinct TicketEntities.EntityName) from Tickets " +
     "inner join TicketEntities on TicketEntities.Ticket_Id = Tickets.Id "+
     "where Tickets.Id in (select TicketEntities.Ticket_Id from TicketEntities where TicketEntities.EntityName = '"+tableName+"') " +
     "and TicketEntities.EntityTypeId = (select Id from EntityTypes where Name = '"+entityTypeName+"') " +
     "and Tickets.IsClosed = 0";
  return sql.Query(sqlc).First;
}
1 Like

That will work after .51 update.

This action asks employee and execute Update Ticket Employees command with selected employee name.

This Report Tag reads employee names from open tickets to create employee buttons.

{REPORT TICKET DETAILS:EN.Employee,EN.Employee.Count:(TEN.Tables=[:EntityName]) and ! T.IsClosed:{0}:,},Cancel

This rule handles Merge Test button click on Ticket List.

This function reads employee count.

{CALL:employee.countForTable('Employees','[:EntityName]')}

This rule works when we click on an employee name button.

You may wonder where [:TicketIds] coming from. That value set by Ticket List command and as ask question action transfers parameters to the command it executes we can access Ticket List screen parameters. So if you need [:EntityName] will resolve to table name or [:EntityId] will resolve to table entity id. Using rule debugger will reveal all available parameters at the time rule executes.


Let’s see how actions configured for Update Ticket Employee rule. This action executes a value looper that triggers a rule for each ticket.

This action merges tickets. This action is interesting because as Ticket List already builds a [:TicketIds] parameter we don’t need to re-supply it inside rule. That’s why I’ve collapsed that action in Update Ticket Employee Rule screen shot.

… and this one displays resulting ticket.


This rule does the most interesting job. It loads ticket, sets employee and closes ticket.

So [:LoopValue] gives us Ticket Id but how the heck [:CommandValue] returns employee name? This is AskQuestion Actions's Command Value. As it transfer’s it’s parameters I can access that value from here.

I’m trying to give more details about how we pass values across rules as I frequently notice people using settings feature to access such values. It might not be needed for some cases. As I’ve mentioned before you can use rule debugger to see which values are accessible to rule. You can use [:Value] syntax for reading such values.


So this is the end of complex part. These two actions used to update ticket employee.

Close ticket action is already a default action…

4 Likes

Wow thanks @emre for taking the time to explain :worried: <- Just could not find a picture of a head exploding lol

1 Like

I’ve implemented this following the instructions, however of course I now have 2 buttons for merging on my Ticket List (the standard Merge Tickets and the new one added here). Is there any way I can integrate this functionality into the standard Merge Tickets feature?

Or, is there a way I can hide the standard Merge Tickets button on the Ticket List and then make this new one handle both those merges with different and same employees?

OK. On next version we’ll hide default Merge button if any command button caption contains Merge keyword.

Hi Emre and guys any idea how to solve followed all instructions to the letter not working i’ve even tried cancelling rules so it’s very basic still no luck. Any help would be appreciated been on it for 9 days now Lol - Using V5.1.58 i seem to think it might be either loop value error or merge error i think its merge error as it worked before merge was disabled when using a custom merge…

Sods law Posted on Here and realised i put a Mark Ticket as Closed action on a Before Ticket Closing Rule a While Back… Deerrrrrr Lol

So Fixed …

1 Like

Cant seem to make this setup work, can someone help me to check where im doing wrong
Screenshot_1


Screenshot_3
Screenshot_4
Screenshot_5

Screenshot_6



Screenshot_9
Screenshot_10

It needs to be the same entity on each ticket to merge.

i understand that but on the tutorial above it shows how it merges both tickets by choosing an employee, then it updates both tickets to same entity so it can merge both tickets to one ticket