Cannot merge tickets when using employee entity from time clock

I am using the time clock implementation by @Jesse

It adds Employee entity and then links Employee to tickets. I have found I cannot merge tickets when they have different employees linked, e.g.:

Is there any way I can get this to work so merge tickets ignores this and allows merge?

I have managed to get a workaround by adding an entity screen for Employees, making visible to Ticket only, adding the Employee entity type to the ticket which then shows a “Change Employee” button on the ticket. If tickets need to be merged, then the staff needs to change the employee entity to be same on all tickets before merge. This is a lot of extra workaround so would like to be able to get merging to work without this.

Perhapse we can automate removing entity and adding it again after merge. Let me check.

Another option I thought of was just stop it from adding employee entity onto tickets. Client said they don’t care but I don’t like to remove a feature to make another work. I guess it is a possibility if all else fails as I assume that wouldn’t break the time clock functionality.

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