I've found a confusing/inaccurate experience with Timestamp field widget when the field is required.

Steps to reproduce

Create a Timestamp field on a content type; set it to be required, with no default value.

When editing, I see:
edit date field

Expected
According to the help text - I can leave this field blank, and when I save the node, it will populate with the date/time at which I submitted.

Actual
I cannot leave this field blank - the HTML5 'required' attribute enforces populating it before form submit. If I remove that attribute with browser inspector, I can submit, but the form API marks the field with an error because the value was empty. Populating it with the current date/time does not happen, regardless.

Here, what the help text says seems to be incorrect.

Solution?
Enforcing the field to be required, as configured, makes sense. The current date/time default can still happen, when the node/add form is loaded. Perhaps in this case, the wording of the help text should be adjusted.

Comments

tea.time created an issue. See original summary.

mpdonadio’s picture

Version: 8.5.3 » 8.6.x-dev
Status: Active » Needs review
Issue tags: +Needs tests
StatusFileSize
new1.19 KB

Nice catch. Can you confirm the field type? I think we are actually talking about Timestamp fields and not the ones provided by the datetime.module. That text appears only in TimestampDatetimeWidget.

I would propose something like this to remain BC.

Version: 8.6.x-dev » 8.7.x-dev

Drupal 8.6.0-alpha1 will be released the week of July 16, 2018, which means new developments and disruptive changes should now be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

joachim’s picture

Status: Needs review » Needs work

Patch looks ok but there are no tests, so setting back to NW.

tea.time’s picture

Title: Date field - "Leave blank to use the time of form submission." is inaccurate if field is required / enforces a value even when field not required » Date field - "Leave blank to use the time of form submission." is inaccurate if field is required
Issue summary: View changes
Related issues: +#2978727: Use current time setting for the timestamp widget

@mpdonadio Hey Matt.

Yep my mistake, this is the Timestamp field type. (I'm not sure which component it belongs under in the issue metadata, though.) I updated the wording to refer to that.

I happened to find #2978727: Use current time setting for the timestamp widget which duplicates the second scenario I described (if the field is not required, the default to time of form submit prevents the ability to save with an empty value). Since your patch addresses the first scenario I described, I've removed the second one in favor of that other issue.

As to your patch, that makes sense - the field is required, thus the user must enter a value. I also like the idea of having a field setting for whether to default to the current time, which is actually what #2978727: Use current time setting for the timestamp widget proposes...

tea.time’s picture

Title: Date field - "Leave blank to use the time of form submission." is inaccurate if field is required » Timestamp field widget - "Leave blank to use the time of form submission." is inaccurate if field is required

(whoops - reference correct field type in issue title)

scott_euser’s picture

Status: Needs work » Needs review
Issue tags: -Needs tests
StatusFileSize
new7.96 KB
new6.63 KB

Tests added

scott_euser’s picture

mpdonadio’s picture

Test changes look good to me. Would like to limit scope to just this bug for the description text, and do the weirdness of being required in #2978727: Use current time setting for the timestamp widget.

mpdonadio’s picture

Status: Needs review » Needs work
Issue tags: +DrupalCampNJ2019
+++ b/core/tests/Drupal/FunctionalTests/Datetime/TimestampTest.php
@@ -59,39 +73,57 @@ protected function setUp() {
+    // Add entity form and view displays for both fields.
     EntityFormDisplay::load('entity_test.entity_test.default')
-      ->setComponent($field_name, ['type' => $widget_type])
+      ->setComponent($field_name_required, ['type' => $widget_type])
+      ->setComponent($field_name_optional, ['type' => $widget_type])
       ->save();
 

Ok, very weird quirk that I am seeing. Test looks completely valid, and I stepped through the HTML output. When I test manually via the UI for field creation, I can't get an empty blank value to show up on the node edit page. This is because the field config page uses the actual widget, which sets the default value upon submission for the field settings. o_O

So, I can't reproduce the screenshot in the IS right now. Going through logs as I seem to recall an issue around default values with either timestamp or datetime.

mpdonadio’s picture

And, after bouncing back to #2978727: Use current time setting for the timestamp widget, it looks like these problems are fairly coupled.

tea.time’s picture

This is because the field config page uses the actual widget, which sets the default value upon submission for the field settings.

Yeeeep, that drives me nuts too... I had a client asking why all their test articles had exactly the same date/time, haha.

It's been awhile since I took that screenshot in the OP but I think what I must have done was manually edit the exported config to set the default value to empty, and then imported that config. Because of the widget as you noted, there's no way to set it as such in the admin UI.

I'm not familiar with writing tests tbh, but since this patch is particularly altering the help text - should the test only need to check the help text according to whether the field is required vs. not required, and not check for empty values in the widget?

sahil432’s picture

Version: 8.7.x-dev » 8.8.x-dev

Drupal 8.7.0-alpha1 will be released the week of March 11, 2019, which means new developments and disruptive changes should now be targeted against the 8.8.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

pcambra’s picture

Adding another related issue, I think this is not accurate even for non-required fields, I've just tested this and got an error message: The Timestamp date is invalid. Please enter a date in the format 2020-10-18 17:15:27.

Adding a test that shows the case, not extending #7, just a test only patch.

pcambra’s picture

StatusFileSize
new1.66 KB

A better named one.

AshM’s picture

StatusFileSize
new1.19 KB

Patch works on 8.9.13.
It does not have tests.

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 11.x-dev » main

Drupal core is now using the main branch as the primary development branch. New developments and disruptive changes should now be targeted to the main branch.

Read more in the announcement.