I’m facing a strange bug with a calendar built using a repeating group (one day per cell). I use conditional formatting to display a red dot when a cell’s date matches a selected date range.
The logic works fine — except that , after the backend workflow that creates the records, one random cell does not apply the formatting, even though:
The date in that cell is correct
The conditional rules are met (same as for the other cells)
The behavior is inconsistent (sometimes the bugged cell changes)
I’ve already checked:
There’s no issue in the data (as seen in the image, 14th is in the DB)
The same conditions apply everywhere (all the 30 records were created through the same workflow)
The issue is not caused by custom states or comparison errors
Tried to replace fomulas in conditionnal formating by variable in the cell (yes/no) but issue is the same.
Has anyone experienced this kind of inconsistent rendering with conditional formatting in RGs?
Could this be related to lazy loading or rendering timing?
What’s in your :filtered expression, and what does the debugger say if you however over the cell that’s not red? In the debugger - is the condition highlighted as green (executed) or is it still red?
You can checking “Show all items immediately” in the Appearance of the Repeating Group, but I doubt that would help.
You can see the filtered expression on the picture. Employe is a custom state in the Popup, and current cell date is generated by the plugin “DateGenerator”.
As you can see, the 4th condition is true, so it should be red (for the 10th of June in the calendar).
“Show all items immediately” is not available since the RG has fixed number of raows and columns.
Try switching the data source of the conditional from the repeating group to whatever the data source of the repeating group is? So, in the conditional instead of RG Buffer List... you’d have Do Search For Buffer List.
Move that conditional to the very bottom to give it priority.
I replace the RG buffer by the original data ource and a “do a search for”. I also put the condition at the very bottom.
In a certain way, it’s worst (should be red from June 1st to August 31th, because in the DB all the “Absences” record are ok.
I also tried to put a delay “current date time + 0.5 sec” in the backend workflow, but it does nothing better.
It is likely this…your backend and front end might have different time zones which may cause issues with the dates since every date has time associated so a date in one timezone, may be different in another timezone, so if your page is rendering in GMT-5 but backend runs in GMT you can end up with issues like this.
Verify first that your dates are in the correct timezone by adding to the RG a text to see the date and time to check that all are time of 12:00AM
All dates are manipulated either using “formatted as mm/dd/yy” or by doing "date → change second to 0 → change minute to 0 → change hour to 0" to match the default "DateGenerator" 12:00 AM format.
I tried duplicating the “Date” attribute into a text field to enable comparison — the logic works, but formatting issues remain (Condition 7).
I tried using a hidden group with the same logic as Condition 7 to avoid applying it directly in the Repeating Group — logic sometimes works, but formatting issues persist (Condition 6).
I also tried the same logic as Condition 7 but using a buffer Repeating Group instead of a “Do a search” — same outcome as Condition 7.
The most important part is that the condition evaluates to true (green), but the formatting doesn’t apply.
BUT I think I’ve found a solution: the only way to get 99% reliable formatting is with an advanced filter:
→ this absence's date:formatted as mm/dd/yy is this group's date:formatted as mm/dd/yy.
It still occasionally fails, but unlike the other methods, **when navigating to another month and coming back, the formatting displays correctly.
I know that advanced filters are WU-consuming, but it seems they force the RG to refresh properly, which solves the formatting issue.
(should be red from June 1st to August 31th, because in the DB all the “Absences” record are ok.