TimestampFormatter / time_diff missing config schema

Created on 9 November 2023, 8 months ago
Updated 24 June 2024, 2 days ago

Problem/Motivation

In πŸ› Allow TimestampFormatter to show as a fully cacheable time difference with JS Fixed , a time diff formatting option is provided. Part of that implementation was a "fallback configuration", labeled 'description'. No config schema was added for description, leading to situations where my CI build fails that validates configuration.

Steps to reproduce

Have schema validator enabled; add a timestamp field to a view; try saving the view. Expected: the view gets saved. Actual: a config schema validation exception is thrown.

Proposed resolution

Provide the missing schema (the MR does this).

Remaining tasks

Fix the tests.

User interface changes

None.

API changes

None.

Data model changes

None.

Release notes snippet

πŸ› Bug report
Status

Needs work

Version

11.0 πŸ”₯

Component
DatetimeΒ  β†’

Last updated about 7 hours ago

Created by

heddn Nicaragua

Live updates comments and jobs are added and updated live.
  • Needs issue summary update

    Issue summaries save everyone time if they are kept up-to-date. See Update issue summary task instructions.

  • Needs tests

    The change is currently missing an automated test that fails when run with the original code, and succeeds when the bug has been fixed.

Sign in to follow issues

Merge Requests

Comments & Activities

  • Issue created by @heddn
  • First commit to issue fork.
  • Status changed to Needs review 7 months ago
  • πŸ‡­πŸ‡ΊHungary Boobaa
  • Pipeline finished with Failed
    7 months ago
    Total: 2423s
    #53847
  • Status changed to Needs work 7 months ago
  • πŸ‡ΊπŸ‡ΈUnited States smustgrave

    Can the rest of the issue summary be filled in please.

    Also change caused test failures.

  • πŸ‡­πŸ‡ΊHungary Boobaa
  • heddn Nicaragua

    Obviously we need tests added or this wouldn't have passed any if there were any. Tagging.

  • πŸ‡ΊπŸ‡ΈUnited States agentrickard Georgia (US)

    Here's a simple view that shows the issue -- let me see if I can work up an MR.

  • Pipeline finished with Canceled
    5 months ago
    #92082
  • Status changed to Needs review 5 months ago
  • πŸ‡ΊπŸ‡ΈUnited States agentrickard Georgia (US)

    OK, here's what I did.

    • Added that view as core/modules/node/tests/modules/node_test_views/test_views/views.view.test_field_created.yml
    • Reverted the schema commit

    If I read the code from core/modules/node/tests/src/Functional/Views/NodeTestBase.php, the setup() method should try to import the new view and then auto-fail schema checks.

  • Pipeline finished with Failed
    5 months ago
    Total: 159s
    #92084
  • Status changed to Needs work 5 months ago
  • πŸ‡ΊπŸ‡ΈUnited States smustgrave

    There's a test-only feature so don't need to push separately.

  • πŸ‡ΊπŸ‡ΈUnited States agentrickard Georgia (US)

    Well, I suspect this minor issue may be covering up a more major problem (which we should file separately).

    This is the YML from the test file:

                time_diff:
                  enabled: false
                  future_format: '@interval hence'
                  past_format: '@interval ago'
                  granularity: 2
                  refresh: 60
                  description: ''
    

    This is the YML from core views.view_content

                time_diff:
                  enabled: false
                  future_format: '@interval hence'
                  past_format: '@interval ago'
                  granularity: 2
                  refresh: 60
    

    When the schema change was made in core, the affected core views were not updated. The following core views are potentially affected:

    • views.view.media.yml
    • views.view.test_content_ajax.yml
    • views.view.test_field_created.yml
    • views.view.glossary.yml
    • views.view.content.yml
    • views.view.media_library.yml
    • views.view.media.yml
    • views.view.files.yml
    • views.view.moderated_content.yml
    • views.view.comment.yml
    • views.view.block_content.yml
    • core.entity_view_display.media.type_five.default.yml
    • core.entity_view_display.media.type_two.default.yml
    • core.entity_view_display.media.type_three.default.yml
    • core.entity_view_display.media.type_one.default.yml

    What does this potentially mean?

    1. Core is not updating its views consistently -- for both distribution and tests -- this seems like a process issue
    2. Views only updates yml elements when the plugin usage is added (not edited, so far as I can tell)

    If the affected core views had been updated with the original change was made, tests would have caught the issue.

  • Pipeline finished with Canceled
    5 months ago
    Total: 34s
    #92485
  • Status changed to Needs review 5 months ago
  • πŸ‡ΊπŸ‡ΈUnited States agentrickard Georgia (US)

    Here's an updated MR that does the following:

    * Removes the new test file
    * Adds the `description` element to `views.view.content.yml`

  • Pipeline finished with Failed
    5 months ago
    Total: 169s
    #92486
  • πŸ‡ΊπŸ‡ΈUnited States agentrickard Georgia (US)

    Update:

    * This merge shows the issue (and the test fails) https://git.drupalcode.org/project/drupal/-/merge_requests/5505/diffs?co...
    * Re-added the original patch / change
    * Updated all affected views

  • Pipeline finished with Failed
    4 months ago
    Total: 241s
    #93168
  • Status changed to Needs work 4 months ago
  • πŸ‡ΊπŸ‡ΈUnited States smustgrave

    Seems to have failures

    But if we are updating all views will need an upgrade path for existing sites

    Also not sure the title reflects what the MR is doing so tagged for that.

  • πŸ‡©πŸ‡ͺGermany Anybody Porta Westfalica

    Confirming this issue, we just ran into it. Resaving the view adds the empty string.

  • First commit to issue fork.
Production build 0.69.0 2024