I'm facing exactly the same issue here as #7. Starting from the version 1.1.0 and including the latest dev (dev-1.0.x 1314827), when making the webform booking field mandatory, validation is not letting it through.
My temporary quick/dirty fix was to edit webform_booking/src/Plugin/WebformElement/WebformBooking.php and change line 539 from
if (!empty($element['#required']) && (empty($value) || empty($value['slot']))) {
to
if (!empty($element['#required']) && (empty($value))) {
It results in omitting the slot validation in that field and only validating the date/time part. As I mentioned above, I'm considering it a dirty hack as it doesn't solve the issue in a long-term and how the date/time/slot is saved.
The old (prior to 1.1.0) date/time format was YYYY-MM-DD HH:MM (regardless of the US/Rest of the world issue), and it gave us a lot of flexibility. Despite not being a dedicated date field, I could easily prepopulate a dedicated date field with its value to further use it in views and apply sorting by date, datepicker, etc.
The new format is YYYY-MM-DD HH:MM | X, where X is the slot quantity. This approach changes a lot negatively, at least for me and takes away that flexibility.
@rfmarcelino, could you reconsider removing the slot value from that field and place it in a dedicated field? Is there any practical or technical meaning that stays behind that change?
I can confirm this issue is no more in the last dev release. It can be pushed to the next stable.
@rfmarcelino, thanks a bunch!
This functionality is broken for all releases starting from 1.0.13. For 1.0.13 the fix is simple but for the 1.1* versions it is not that easy to make it to work.
@rfmarcelino, can you please look into it when you have a second?
My bad is a dupe of Do not use constant AUN_CASE_LEAVE_ASIS in auto_username.settings.yml 🐛 Do not use constant AUN_CASE_LEAVE_ASIS in auto_username.settings.yml RTBC
zimny → created an issue.
Cheers!
Looking at the commit from the linked reference in my previous comment, I have slightly modified rfmarcelino's original code to match my needs and after some testing and to my surprise I wanted to let you know that it works and does exactly what I wanted.
I am not sure yet how to apply those commits, so please see below the attached code. Feel free to do the testing and possibly push it to the future updates. I am quite sure it can come handy.
WebformBookingController.php
// Adjusting end date based on 'days_visible' if set.
if (isset($config['#days_visible']) && is_numeric($config['#days_visible'])) {
$visibleDate = (new \DateTime())->modify('+' . $config['#days_visible'] . ' days');
if ($actualEndDate > $visibleDate) {
$actualEndDate = $visibleDate;
}
}
WebformBooking.php
protected function defineDefaultProperties() {
$properties = parent::defineDefaultProperties() + [
...
'days_visable' => '0',
...
// Days visable.
$form['appointment_settings']['days_visible'] = [
'#type' => 'number',
'#title' => $this->t('Days Visiblee'),
'#default_value' => $this->getDefaultProperty('days_visible'),
'#description' => $this->t('Number of days from now a booking can be made'),
];
I think that at this stage we still have to create a condition that takes into account the original "Days in Advance" setting to ensure that those two not interfere with each other, i.e. "Days in Advance" number can not be higher than "Days Visible".
What do you think?