- Issue created by @phenaproxima
- Status changed to Active
4 months ago 7:46am 6 September 2024 - 🇮🇳India kunal.sachdev
Now that ✨ Certain filters should only be shown if they are actually defined Needs work is fixed.
- 🇺🇸United States phenaproxima Massachusetts
I think this looks quite close to what I envisioned - great job!
The only thing that I object to here is the changes to BooleanFilter. I think that passing a set of options to it misunderstands the nature of a boolean filter.
A boolean filter really should only be a single checkbox, semantically speaking. I understand that Project Browser has shown them, previously, as option sets -- that's a strange decision, but it's one we could account for differently, rather than changing BooleanFilter to work like a set of options.
So, I'm kicking this back for that, but once that's done, we can work on resolving the test failures.
- 🇮🇳India kunal.sachdev
The current test failure is in
tests/src/Nightwatch/Tests/keyboardTest.js
in which there is a part where we are testing that when we are on the categories filter and we click tab then it shifts to next filter drop down i.e security coverage. This test is failing now because in this MR we are rendering the filters as it is which is defined from the backend and not hardcoding them. The previous hardcoding was done in a way such that the filters were displayed in the order :- categories -> security coverage -> maintenance status -> development status but now we accidentally in the backend have the filters defined in the order :- categories ->maintenance status -> security coverage -> development status. For now to fix the failure we can fix the order of the defined filters in backend but I think the major problem is that somewhere in the code we have hard coded the tab index for each filter which needs to be fixed (maybe in a new issue). - 🇺🇸United States phenaproxima Massachusetts
Virtually no complaints here. Amazing work!
I only would like to see a couple of follow-ups filed (one of which seems ambiguous), and using
assertSame()
instead ofassertEquals()
in most situations. Other than that, this just needs a little manual testing and then it's good to go. - 🇺🇸United States phenaproxima Massachusetts
This code looks good to me. I'm RTBCing it and sending it to @chrisfromredfin for manual testing and hopefully a merge.
- First commit to issue fork.
-
chrisfromredfin →
committed bbf8a47d on 2.0.x authored by
kunal.sachdev →
Issue #3470540 by kunal.sachdev, phenaproxima: Create some front-end...
-
chrisfromredfin →
committed bbf8a47d on 2.0.x authored by
kunal.sachdev →
- 🇺🇸United States chrisfromredfin Portland, Maine
Manually tested and re-reviewed. This is a big leap forward to moving out of proof-of-concept land and into "this is a real thing" land.
I would love to someday see a meta about revisiting all our tests and doing things like moving to assertSame(), but I may leave that for a core gate.
- Status changed to Fixed
about 1 month ago 8:19pm 12 November 2024 Automatically closed - issue fixed for 2 weeks with no activity.