Closed (fixed)
Project:
Drupal core
Version:
8.1.x-dev
Component:
comment.module
Priority:
Normal
Category:
Bug report
Assigned:
Unassigned
Issue tags:
Reporter:
Created:
18 Mar 2016 at 01:34 UTC
Updated:
18 Apr 2016 at 04:24 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #2
cafuego commentedAttached patch re-labels the existing handlers to match their database field and adds additional handlers for the created field.
I suspect that's the best way to fix it, as changing the field on the mislabeled handlers would change the data that existing views return, which we probably want to avoid.
Comment #3
cafuego commentedComment #4
kattekrab commentedComment #5
rteijeiro commentedShould we use the shortened syntax for arrays?
Comment #6
cafuego commented@rteijeiro Not in this patch, no. If you want to do that, do it in a separate issue and do the whole file.
Comment #7
jibranFix is fine but it needs tests.
Comment #8
jibranWell, these plugin are supplied by views and
NodeViewsDatais already using these so I think this fix is ok as is. And, we already have test coverage for\Drupal\views\Plugin\views\argument\Date*plugin inArgumentDateTest.But, I think VDC team should sign off this.
Comment #9
dawehnerWorks for me!
Comment #10
alexpottIs there any test coverage for the new fields? I guess not.
Comment #11
cafuego commentedBtw, the patch doesn't need any work to backport it to D7, there's already a working patch on issue #2689657: D7 Comment date views arguments uses incorrect database column.
Comment #12
jibranWe don't need tests here plugins are already tested with entity_test data. There are no tests for nodes. I don't see a point of adding those for comments. Leaving it NW because I think we need an update hook in comment module to clear the views comment data.
Comment #13
cafuego commentedAdded an empty update hook as per request from @jibran.
Comment #14
jibranThanks looks good now.
Comment #17
catchCommitted/pushed to 8.2.x and cherry-picked to 8.1.x. Thanks!
Agreed with jibran that I don't see explicit test coverage for this being useful - we'd only be testing the comment_views_data() hook implementation.
Let's open a new issue for Views 7.x-3.x for the backport so the core issue queue history gets retained.
Comment #18
kattekrab commentedViews 7.x-3.x issue already exists here:
#2689657: D7 Comment date views arguments uses incorrect database column
And what about for 8.0.x ?
Comment #19
dqdJFYI #1374090: Editing a comment still changes creation date too make sure that there are no overlapping side effects...