Closed (fixed)
Project:
Recurring Events
Version:
8.x-1.x-dev
Component:
Code
Priority:
Normal
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
23 Oct 2019 at 01:42 UTC
Updated:
20 Nov 2019 at 00:04 UTC
Jump to comment: Most recent, Most recent file

Comments
Comment #2
technotim2010 commentedThat explains a lot. So if this was not producing an eventinstance entity with no bundles and just base fields, would this work?
So the approach i was wondering about is making it create a bundle of type eventinstance which might work with views properly.
Looking at the issue referenced that does not look like it will get a solution before D9 and maybe not even then.
A module that creates events, even as cleverly as this module does, is not that useful if the entity created is not usable in views.
You can list views and inherited fields but cannot make it interface with any display types beyond those in core.
Is this the best approach?
Regards
Tim
Comment #3
owenbush commentedThe issue here is not the lack of bundles (in fact, eventinstances have one bundle, called eventinstance) the issue here is basefields. Throughout the development of the module I've come across a number of places where core or third parties do not support basefields, or have assumed all fields are field UI fields. This is another example, if the patch for D8/9 is not forthcoming, I'll have to take a look myself at getting some sort of solution in place for recurring events, because you're right in the sense that if these things are not possible they severely reduce the functionality of this module.
For the most part basefields are completely supported by core. The difference here is a basefield which is a daterange field + views and I guess that got missed. The ideal solution is that views/daterange/core gets patched because that is the right thing to do moving forward. But I may have to intervene in the mean time.
Comment #4
technotim2010 commentedI was pondering, that given the release date of 8.8 is in December, and since following that issue @Joachim has rolled a patch I might rebuild my prototype to 8,8 dev and apply the patch and see if that fixes things in any way.
That would make sense and possibly give us a way forward. If it works, while not proving that Joachims patch works (at least not enough for it to get into core yet) we could at least have a solution.
I will look at this over the weekend.
Comment #5
owenbush commentedGreat, please do let me know how it goes.
Comment #6
owenbush commentedAttached is a patch to add datetime filtering, sorting, and argument support the eventinstance datetime_range basefields.
Comment #7
owenbush commentedComment #8
technotim2010 commentedI will test and review this first.
Be done today,
Tim
Comment #9
technotim2010 commentedHi
I can confirm that this resolves the issue of being unable to filter by event instance datetime using the module. Filters, including grouped filters now work as expected.
It does nothing to resolve the issue with FullCalendarView though. No date data is shown on the calendar.
Something else is still missing.
Regards
Tim
Comment #10
the_glitch commentedThis patch works as a fix in accordance with this issue. I'm not familiar with FullCalendarView so I'm yet to discover that problem/issue.
Comment #11
owenbush commentedGreat. I'll mark this as RTBC.
The fullcalendar_view thing is a bigger fish - related to basefields and is unlikely to be solveable from this module's point of view. It will need to be a patch to fullcalendar_view I think.
Comment #12
mrpauldriver commentedComment #14
owenbush commentedThis has been merged into the 8.x-1.x-dev branch. Marking this as fixed.