Duplicate entries for all day events with multiple standard (non smartdate) date fields

Have you tried not selecting any fields in the "Customize Fields" option?

Could you post a screen grab that shows the fields you're trying to use? Also, you mentioned that you have this working with Fullcalendar View. Would you be willing to post a screen grab of that config?

Here is the patch if you want to test and check the unique events for the same.

Sorry for the comment #14 please look into this patch.

Please use this patch DuplicateAllDayEvents-3480947-15.patch for the Duplicate entries for all day events with multiple standard (non smartdate) date fields issue.

Duplicate entries for all day events with multiple standard (non smartdate) date fields

I can confirm the duplicate entries on the frontend when assigning start and end dates to an event. Following the comment #7 by @erutan, I removed the end date and the duplicates don't show up on the front end. I've attached screenshots that demonstrate this behavior. Please merge the fix and issue a new release.

PS: Edited after posting this comment this morning. I also logged another issue - similar to this one and with another - possibly related cause - here. I tracked this conversation after logging the other bug report.

Dear all,

I can also confirm that this patch works. I've added my comments and screenshots to the other related issue I posted here. The patch seems to fix the issues I was facing. Shout out to @vinayakmk47 for the patch and all the contributions from this community.

Thanks a ton!

Mithun A. Sridharan

I appreciate the work done to date here, but unfortunately there are a few things needed before this will be ready to merge. First, there are a variety of code standards issues, in fact the changes in the MR that actually introduce code standards failures outnumber the lines required for the actual solution. If it were as simple as that, I would have made a new MR with only the actual proposed solution.

My bigger concern is that the proposed solution does a pass for deduplication at the very end, after all the processing has been done for all the rows in the view. That means that the back end is still doing all its work on duplicate rows, we're just stopping them from all being passed to the front end. I would suggest that there's a much more efficient way to address the cited problem.

Consider this code towards the end of the unmodified prepareEvent() method:

          $event = $this->prepareEvent($entity, $title, $date_fields, (int) $index);
          if (!empty($event)) {
            // @todo more sophisticated key assignment needed?
            $events[] = $event;
          }

The proposed changes include this line:
$uniqueKey = $event['id'] ?? $event['start'] . '_' . $event['end'];

We could generate the $uniqueKey value and check for an existing value in the $events array BEFORE calling the prepareEvent method, and then add the current row to the $events array using the $uniqueKey as the index. Then the method could return the array values of the $events array directly.

I would be happy to help this along more directly myself but since neither this issue nor the one closed as a duplicate include detailed steps to reproduce the problem on a clean install, I don't want to guess how to replicate an issue I haven't yet come across myself.

Thanks for the additional work here. I see now (having done a little testing) that my earlier optimism that we could skip processing by generating the $uniqueKey before calling the prepareEvent method was unfounded, since the logic for generating it depends on start and end keys that will not be available until after the method has been called.

@erutan thanks to your steps to reproduce, I was able to see the problem, and validate that the proposed code resolves it.

I do see a bigger problem, however. The patch also prevents multivalue date range fields from displaying as expected. That also means that recurring Smart Date fields only display the first value.

I suspect we need a deeper refactoring, to use different logic for date fields that are ranges (where it's reasonable to expect multiple events per entity) from entities that need multiple fields for a single value (and where multiple events per entity are less likely). We currently have some of this logic within the getEventStartEndDates() method, but some different logic might be needed at a different level.

Here's a new MR with a tweaked approach. In my testing it eliminates the duplicate display for datetime fields, but preserves the multivalue display for ranges.