Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.Problem/Motivation
Currently in recurring_events_registration there's a boolean views filter for whether an event instance has availability or not for registration. It might be handy to add a numeric filter (e.g. there are 2 or greater available slots for registration for an event instance) since there's likely common use cases for this (especially re: the 'add guests' feature request in https://www.drupal.org/project/recurring_events/issues/3257502).
Proposed resolution
Attached patch adds a numeric views filter "Registration Availability Count" for event instance views.
| Comment | File | Size | Author |
|---|---|---|---|
| #7 | recurring_events-numeric_views_filter-3265779-7.patch | 10.88 KB | owenbush |
| #7 | interdiff-3-7.txt | 7.46 KB | owenbush |
| recurring_events_registration-add_availability_count_filter.patch | 6.88 KB | bgilhome |
Comments
Comment #2
bgilhome commentedSome users might also want a contextual argument (e.g. could be used with Contextual Range Filter module (https://www.drupal.org/project/contextual_range_filter) to filter a range of availability counts) - updated patch & interdiff attached.
Comment #3
bgilhome commentedI forgot to add the views_data diff - here's the updated patch and interdiff to 1.
Comment #4
owenbush commentedThis is good stuff, thank you. I wonder if it is worth waiting until #3264621: Use computed fields for availability, registrations & waitlist counts is merged, so this can be updated to use the computed fields.
Comment #5
owenbush commentedComment #6
owenbush commentedThis is now probably ready to be updated to use the computed fields. I'll take a look this week.
Comment #7
owenbush commentedAttached is a new patch and an interdiff. Basically all I changed was to no longer need the RegistrationCreationService because we now have a computed field to determine the availability for an event, and then I also tweaked the logic in some of the operators to take into account the fact that some events can have an unlimited (-1) capacity.
For example filtering for any event with:
1. More than X spaces - should always return the unlimited events
2. Less than X spaces- should never return the unlimited events
3. Between X and Y spaces - should never return the unlimited events
4. Not between X and Y spaces - should always return the unlimited events
etc.
Comment #8
bgilhome commentedThat's great! Thanks @owenbush!
Comment #11
owenbush commentedThis has been merged into the latest dev branches 8.x-1.x and 2.0.x