[FOLIO-2517] Filtering by optional boolean properties Created: 18/Mar/20 Updated: 03/Feb/21 Resolved: 03/Feb/21 |
|
| Status: | Closed |
| Project: | FOLIO |
| Components: | None |
| Affects versions: | None |
| Fix versions: | None |
| Type: | Task | Priority: | P3 |
| Reporter: | Marc Johnson | Assignee: | Unassigned |
| Resolution: | Won't Do | Votes: | 0 |
| Labels: | potential-decision, tech-debt | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original estimate: | Not Specified | ||
| Issue links: |
|
||||||||||||||||||||
| Sprint: | |||||||||||||||||||||
| Description |
| Comments |
| Comment by Marc Johnson [ 18/Mar/20 ] |
|
Cate Boerema Charlotte Whitt Zak Burke Michal Kuklis Svitlana Zmiivska Julian Ladisch Have I missed or misrepresented anything in the above description? |
| Comment by Michal Kuklis [ 18/Mar/20 ] |
|
It looks great Marc Johnson |
| Comment by Zak Burke [ 18/Mar/20 ] |
|
That's not quite right because the two "no" queries are not equivalent: staffSuppress == "false" staffSuppress="*" NOT staffSuppress == "true" The first query will not find values where staffSuppress is undefined. |
| Comment by Cate Boerema (Inactive) [ 19/Mar/20 ] |
|
Looks good to me, Marc Johnson. Would this be a good candidate for the new "Feature level design" process where the design/plan is captured on the wiki (per this process https://folio-org.atlassian.net/wiki/display/TC/2020-03-04+Cross-team+PR+Review+Discussion+Part+2)? We could make documenting the design on the wiki part of the acceptance criteria for this spike. |
| Comment by Marc Johnson [ 19/Mar/20 ] |
|
Zak Burke Thanks, I've hopefully corrected the example query. Let me know if it is still incorrect |
| Comment by Marc Johnson [ 19/Mar/20 ] |
I don't know. I would suggest it wouldn't be, because it isn't really a feature level design, rather a cross cutting design. That said, I'm not sure of the practical difference, as it is likely this topic could go to the Tech Leads for a decision. And that might involve similar activities. We likely need Craig McNally and Jakub Skoczen thoughts on that.
Sure. I'd likely want Craig McNally and Jakub Skoczen input on how to organise that documentation. If part of our goal is to have living documentation, it needs to be discoverable. I don't think there is much to discover about this, unless we want to confirm the performance and upgrade assumptions? |
| Comment by Craig McNally [ 20/Mar/20 ] |
|
I agree that this probably doesn't warrant an entire document on its own. However I could imagine something like this would be part of a larger feature level design doc (for say inventory search and filter, a la
One thing we were hoping to capture in the feature level design docs is a log of design decisions... Problem, options, pros/cons of each, which approach was selected and why; More or less what we have here. |
| Comment by Marc Johnson [ 25/Mar/20 ] |
I agree. As the search and filter work started a while ago and has been mostly front-end work (as performance has been excluded from scope) there hasn't been much technical design. Jakub Skoczen Craig McNally Should I consider putting one together for this feature (I already have at least two that I need to write, I'm likely to be busy with them for a while)?
I agree. This feels like general guidance rather than a design decision for a specific feature. My concern is that it could get lost in the midst of a feature design document. Craig McNally Jakub Skoczen Could we start doing documenting this kind of guidance? Where should it go, on the wiki? |
| Comment by Marc Johnson [ 03/Feb/21 ] |
|
Closing as pre-dates the new decision making process and has not progressed |