Allow the start time or the end time to be NULL, depending on field instance configuration.

I don't understand this test failure in GitLab CI:

Drupal\Core\Config\Schema\SchemaIncompleteException: Schema errors for field.field.entity_test.entity_test.field_under_test with the following errors: field.field.entity_test.entity_test.field_under_test:settings.require_start missing schema, field.field.entity_test.entity_test.field_under_test:settings.require_end missing schema

at

/builds/issue/time_field-3541135/tests/src/Kernel/TimeRangeFormatterTest.php:78

On my machine, the tests all pass. And the required settings are right there at tests/src/Kernel/TimeRangeFormatterTest.php:74

Hi @rudolfbyker,
I have tested the Time Field module on Drupal 11.2.3.

All features mentioned in the issue description are present and working correctly:

Optional Start time and Optional End time checkboxes are available in the field instance configuration.

Both Start time and End time can be set as optional when specifying default values.

Additional formatter options for only Start time or only End time are available in the field formatter configuration.

Screenshot attached for reference. Thanks.

Re #4: Locally you probably went through the update hook to get the fields. The test runner does this with what is in the schema.yml file. You can also try to uninstall the module and re-enable it, or try it on a fresh install. Check the status page for schema errors.

Is this correct?

field.field.time_range:
  type: field.field
  label: 'Time range field'
  mapping:
    settings:
      type: mapping
      mapping:
        require_start:
          type: boolean
          label: 'Require a start time'
        require_end:
          type: boolean
          label: 'Require an end time'

Why field.field? Should that not just be type mapping with everything below it? (just thinking out loud, didn't really look at the rest of the MR)

Locally you probably went through the update hook to get the fields.

I don't understand this sentence. What do you mean by "went through the update hook"?

You can also try to uninstall the module and re-enable it, or try it on a fresh install.

I'm not convinced that this will help, since Kernel tests do not use the local environment. They use a separate, empty database with a clean Drupal installation to execute.

Why field.field?

Good question! I think I was following a bad example when writing the schema. I searched everywhere and can't find proper documentation on what this should look like, other than this: https://www.drupal.org/docs/creating-custom-modules/creating-custom-fiel... → . So if I read that correctly, it should change to this?

field.field_settings.time_range:
  type: mapping
  label: 'Time range field settings'
  mapping:
    require_start:
      type: boolean
      label: 'Require a start time'
    require_end:
      type: boolean
      label: 'Require an end time'

I seem to have lost push access to my own issue fork, and I can't figure out why. Would you be able to add a commit with my proposed change from #7 ?

I don't understand this sentence. What do you mean by "went through the update hook"?

What I ment to say is that wherever you developed this, you probably got the fields through the update hook, and not the install process that only looks at the schema file.

I'm not convinced that this will help, since Kernel tests do not use the local environment. They use a separate, empty database with a clean Drupal installation to execute.

That is exactly what I'm trying to say :) there might be a mistmatch between the schema and update hook. Hence why it might work locally for you, but not in the test runner.

I seem to have lost push access to my own issue fork

If you're going through the GitLab UI, make sure you're logged in (check user icon top left).

got the fields through the update hook

I still don't have a clue what you mean by "getting fields through an update hook".

Hence why it might work locally for you, but not in the test runner.

I think you misunderstand me. If I run phpunit on my local machine, it creates a brand new Drupal installation for each test. That is how Kernel tests work, regardless if running in CI or locally. It does not use my local environment. I can destroy my local environment completely, and still run the tests, and get the same results.

If you're going through the GitLab UI, make sure you're logged in (check user icon top left).

I was logged in, but not going through the UI. I tried pushing via SSH, and got an access denied error. Today I tried it again, and it worked. Nothing changed on my development machine.

After aligning my PHPCS config with what is used in CI, I get the same results for PHPUnit locally and PHPUnit in CI. I found this surprising, because I thought that PHPCS and PHPUnit were totally independent.

Regardless of the above, I fixed the issues in subsequent commits. :) Please review.