Closed JGreenlee closed 6 months ago
Here is how I have the checkbox currently implemented
I think it may be worthwhile to consider other designs/ layouts because we now have multiple options for global filtering, and it's starting to get cluttered
95ded215f73bde8332fa58d173613f34228629cc: organize filtering options into a collapsible menu
Filter menu closed
Filter menu open
(this PR extends on #96 since the changes are fairly intertwined)
add filter to exclude 'test' users
'test' users are devs or program admininstrators whose data we usually want to keep separate from that of the participants themselves, identified by subgroup 'test' - in other words, if the opcode has "test" in it we should be able to filter out their data.
A checkbox is added below the datepicker to "Exclude 'test' users" (checked by default)
Filtering 'test' users from the UUIDs df is a simple task - drop any rows where 'user_token' contains 'test'. But the other dfs (for confirmed trips, survey responses, trajectories) do not have the 'user_token' column - only 'user_id'. So every time we want to filter these dfs, we'd have to cross-reference with the UUIDs table and lookup which 'user_id's correspond to test 'user_token's. (I think of this like a 'join' in SQL)
I think a more performant solution is to keep a separate 'excluded uuids' store, which is just a plain list of excluded UUIDs that we determined while loading the 'uuids' store. The other stores can depend on this, so they will not need to depend on the entire 'uuids' store and do those cross-referencing lookups each time.