Fixed cascade logic for dropdown options filtering #30
Conversation
|
Hi Brandon, I'm working on testing the updates to evagram and I've found that I'm able to view an experiment name even though I haven't selected a User. Are you also getting this behavior? 
|
Yes, I just noticed that I have been getting this behavior as well, but I found where the issue was in the initial load of the page and have fixed the bug. |
|
After killing pg4admin processes I had on port 5432 and then running docker-compose.yaml (my local database is now able to use 5432:5432) and then running evagram-input, I'm able to see the new input data. Bugfix works on my end. Excellent work! |
There was a problem hiding this comment.
A few overall comments that may not be immediately relevant to the bugfix:
- First of all, great work on fixing this bug!
- Please add """ docstrings to every function.
- Some of the functions here are helpers, not "views" themselves. Namely everything from
get_ownersand beyond. Would it be appropriate to import them from a newutilmodule? I want to keep theviewsas minimal as possible.
That sounds like a good idea! Where would the |
|
@brandonzhu09 Should it go in |
Description
Bugfix for improper cascading logic when listing the valid dropdown options in the data viewer. Resolved this issue by applying the correct number of filters at each update option event in the backend.
Resolves issue GEOS-ESM/evagram_input#9.
As shown in the image, there are no longer groups that do not belong to the variable as well as the owner, experiment, and observation associated with it.