Closed (fixed)
Project:
Drupal core
Version:
8.2.x-dev
Component:
views_ui.module
Priority:
Normal
Category:
Bug report
Assigned:
Unassigned
Issue tags:
Reporter:
Created:
11 Dec 2015 at 22:49 UTC
Updated:
2 Aug 2016 at 14:14 UTC
Jump to comment: Most recent, Most recent file

Comments
Comment #2
mikeker commentedFirst stab at fixing the wording and getting the validation right. (Now also raises an error if you set a value but do not have a title/label).
Needs tests...
Comment #3
mikeker commentedComment #5
geertvd commentedWe can't really assume the value is always going to be an array.
By doing this, operations that don't require a value (like isEmpty) also get an error.
Fixed those issues but that caused a lot of reverts from the initial patch, didn't add any additional tests yet. Let's see if this already fixes the broken tests.
Comment #7
mikeker commentedOK, this was a bit more complicated a fix than I first thought. Starting with a tests-only patch.
Comment #8
mikeker commented@geertvd, Thank you for the review!
Sorry, I hadn't refreshed this page all weekend as I was working on it in bits and pieces when I had free time. I didn't see your earlier review and patch. Regardless, it looks like we were heading in the same directions with regards to handling the validation for things like "is empty" filters. I'll review your changes tomorrow and merge with mine if there are any differences. In the meantime, let me know if you think these test changes cover what's needed for basic grouped filter validation.
Comment #10
mikeker commentedThe attached patch takes a very similar approach to what @geertvd was doing in #5 in terms of covering the empty/not-empty operator. As I mentioned in #8, I hadn't seen the earlier work when I started mine, thus the interdiff is a little messy. Sorry about that.
Would love to hear from a VDC maintainer if there are other operator types that we should include in testing/validation.
Comment #11
lendudethis removes the only uses of
should that method not be removed as well? Or be marked deprecated?
The fact that that method exists though, makes me think that at some point there were value arrays with 0 being a valid value. Only thing I can thing of would be a boolean filter, but that currently uses a text filter #2469553: Views filtering on boolean fields doesn't use right formatter, so even that doesn't apply.
But thats the only thing I can think of that would fail with this fix, an array where 0 is a valid value.
using !empty() and empty() instead of all the =='' would make this easier to read, but that might just be me (or mean that I should really go to bed).
Manually tested this for the node type filter and fixes the issue there. Looks great otherwise.
Comment #12
geertvd commentedI also think this method should be removed, it doesn't seem to be used anywhere else, the @return comment is also a bit confusing.
Comment #13
mikeker commentedFrom #11:
I avoided
empty()only because a title could be (string) "0". I can't imagine why anyone would want to do that, but figured it was better safe than sorry... :)From #11 and #12:
I agree. I wasn't able to find a need for it in my manual testing. And in @geertvd's earlier patch it was removed. Sorry, fixed in this version.
Comment #14
mikeker commentedand the files...
Comment #15
lendudeHmm, why are we testing setting sort criteria? Am I missing something?
Comment #16
mikeker commentedThanks for the review, @Lendude!
Those tests were there originally, just moved around in this patch. I would also argue that it's within the scope of this test to verify the exposed sort options since this file is supposed to be testing the exposed form UI.
Comment #17
lendude@mikeker ah yeah missed all the - at the end there! Is all the rearranging necessary in the test file? Makes the patch much harder to read (and could be seen as unrelated changes).
the text seems to miss something at the end... is used/ is set, or change if to for?
Comment #18
lendudeOh and just manually tested the empty/not empty handling of the grouped date filter and that doesn't work. So maybe that needs the special handling as well?
Comment #19
mikeker commented@Lendude, you're right, date filters still don't work -- working on a fix.
re: moving tests around: It does make the patch harder to read, but the former state -- with all the tests in one, long method wasn't any good either. Considering this patch is adding a bunch of tests, I figured creating new methods for those tests was within the scope of this fix. At that point, it didn't make sense for some of the grouped filter tests to be in one place while others were in the new methods.
Gah... Thanks for catching that! ("if" should have been "for"). Will fix in the next patch.
Comment #20
mikeker commentedThe "is empty" date filter error has been opened as a followup to this issue: #2637854: Grouped date filter results in undefined index notice. There seems to be bigger problems with that so I'm moving that out of this issue in hopes that we can bring this to a close and work on the date filter separately.
This patch introduces a
hasValidGroupedValue()method toFilterPluginBase. The occasional oddball filter (like datetime) can override this with specifics for their situation (in datetime's case, adding the date/offset radio button element to the value option.It occurs to me that this could be useful outside of the grouped filter context and perhaps should be named
hasValidValueinstead. Thoughts?Also this patch returns
arrayFilterZero()toFilterPluginBase, but fixes it so that it functions correctly. It is needed for the case where the string "0" is entered as the value of a filter. Also adds tests for this.Comment #22
lendudemissing type hint
it tests a grouped filter group I'd say.
this could use some explaining
missing period at the end.
disabledtest?
Looking good!
hasValidGroupedValue()is a good addition I feel. I'd say not make it more general for now, this is getting big enough as it is.Comment #23
mikeker commented@Lendude, thanks for the review!
#1: Fixed
#2: Updated to "Determines if the given grouped filter entry has a valid value."
#3: There is a comment inside the conditional, but it was poorly worded. Fixed along with another in that block that will hopefully explain things better. Also moved the final return FALSE to the end of the method capture the odd case where $group['value'] is something other than a string or an array.
#4: Fixed.
#5: Yeah, naming things disabledtest is a great way to ensure those tests don't fail! :) Grr... leftover from when I was debugging and wanted the simpletests to run faster. Fixed.
Comment #24
mikeker commentedAdded @Lendude to the commit credit.Nevermind, it looks like I can't do that on core issues...Comment #25
lendude@mikeker but thanks for trying.
Manually tested it again with the node type filter, patch does its job. Not sure if the addition of
hasValidGroupedValue()is considered a API change. Since it doesn't change anything just gives you an extra option to do something more efficient (and the old method still works as always), I don't think so, but not sure.But this now looks good to me.
Comment #26
duneblDo you think we can have this patch available for Drupal 7
Comment #27
mikeker commented@DuneBL, I don't see why not. But it has to go into D8 first and then can be backported. Any additional manual testing on D8 would be helpful to ensure this doesn't introduce regressions.
Comment #28
alexpottI think given how this is fixed I think we need a CR and this can only really be fixed in 8.1.x - any contrib/custom filters might need to make similar changes - no? It might be good to get the "should not be an error" part displayed in the issue summary fixed in 8.0.x though...
Missing docblock and assert* functions should return a boolean.
Comment #30
dagmarRe-rolled. Fixed coding standards.
Comment #32
dagmarDuring the re-roll I placed arrayFilterZero() in the wrong file.
Comment #33
mikeker commentedItty-bitty code standards fix.
And thank you for the review, @alexpott, and the re-roll, @dagmar. Sorry I let this fall off my radar.
Comment #34
dagmarBack to RTBC since #28 has been addressed.
I also tested this on simplytest.me and can confirm is working as expected.
Comment #35
mikeker commentedre: #28
I added a CR (https://www.drupal.org/node/2712513, unpublished) as requested.
Contrib/custom filters will need to make a similar change only if their value is more complicated or holds multiple items (eg: date filters). It's a minor enough issue with a workaround so I feel fine putting it into 8.2.x without splitting the error portion into a separate patch.
Comment #36
dawehnerOh, I wasn't aware that this is actually possible, nice!
I really like the new named function, it just makes it easier to ready.
+1 for the changes in general
Comment #38
mikeker commentedApplies fine on 8.2.x for me... Try again, testbot!
Comment #40
lendude@mikeker no really didn't apply anymore. Reroll.
Comment #41
mikeker commentedThanks, @Lendude! My bad, I must've done a merge instead of applying the patch directly...
Back to RTBC as per #34 in hopes of getting this in during DrupalCon. (@Lendude, you here in NOLA? If so, ping me.)
Comment #42
lendude@mikeker nope, not in NOLA unfortunately.
Comment #44
mikeker commentedThe error in the Migration test is unrelated. Retesting.
Comment #45
lendudeFails were unrelated, so back to RTBC per #34 and #41
Comment #47
lendudeTestbot hiccup, back to RTBC
Comment #49
lendudeUnrelated fails, back to RTBC
Comment #50
alexpottCommitted 3bf487f and pushed to 8.2.x. Thanks!
Only committed to 8.2.x because of the addition of a method to the plugin base class.
Comment #52
alexpottFixed that on commit.