Recent searches
No recent searches
Broken Boolean Logic?
Answered
Posted Mar 16, 2021
Hi - I am looking at the following logic for a specific ticket as a test.
(
DATE_FORMAT([Ticket solved - Date],"yyyy-mm-dd") >= DATE_FORMAT(DATE_ADD(START_OF_WEEK_MONDAY(TODAY()),"day",-7),"yyyy-mm-dd")
AND
DATE_FORMAT([Ticket solved - Date],"yyyy-mm-dd") < DATE_FORMAT(START_OF_WEEK_MONDAY(TODAY()),"yyyy-mm-dd")
)
AND
[TicketSolvedWeekday] < [CurrentWeekday]
This seems to be evaluating to True based on the third boolean being True however one of the other two booleans is false so this should evaluate to False.
Why would it ignore the first statement completely like this? Am I missing something?
0
4
4 comments
Christopher Le Quesne
Extra info on this - it seems to be tied to my [TicketSolvedWeekday] < [CurrentWeekday] boolean consisting of two attributes that are each individually defined by further boolean logic.
If I swap this statement to say 1 < 2 it suddenly evaluates the whole thing to false as it should do so there is clearly something very strange happening here.
It's as if Zendesk Explore can't process the outputs of these custom attributes within another piece of logic correctly. Interestingly I also can't take the logic from these attributes and compare them explicitly because it returns an error, despite there not being an error when I store each of them in an attribute.
0
Christopher Le Quesne
Here's what is contained in the two attributes:
[TicketSolvedWeekday]:
IF
WEEKDAY_NUMERIC([Ticket solved - Date])-1 = 0 THEN 7 ELSE WEEKDAY_NUMERIC([Ticket solved - Date])-1
ENDIF
[CurrentWeekday]:
IF
CURRENT_WEEKDAY_NUMERIC() = 0 THEN 7 ELSE CURRENT_WEEKDAY_NUMERIC()
ENDIF
I literally had to write this because for some reason it is hard for Zendesk to just put an optional parameter into WEEKDAY_NUMERIC so you could actually choose the week start day. This is a basic thing that I would expect from an analytical tool for date-based analytics and it's quite bad to see Zendesk don't think this is important.
0
Christopher Le Quesne
Fixed this - turns out the DATE_FORMAT functions were causing the issues but I still don't understand why...
0
Dave Dyson
Hi Christopher -
I'm glad you were able to figure this out! One potential issue I'm seeing is that when formatting dates, the lowercase "m" corresponds to the minutes number in the timestamp – for the date, you'd need to use the uppercase "M" to get the month number, so:
"yyyy-MM-dd", not "yyyy-mm-dd"
Using the minutes where you mean to use the month could result in some very unpredictable boolean logic!
0