chicago-tool-library
Category counts are incorrect and inflexible
Is your feature request related to a problem? Please describe. We currently use a materialized database view to easily get a list of categories and how many children are within each one. Here's the database view, and here's the model we use to query it.
The main issue we're seeing is that the status of items isn't taken into account when determining the count of items within it. So we sometimes end up with a category that says the contain 5 items, but only actually has 4 when they are viewed (see example below).
Additionally, we'd like to be able to have these counts update based on search queries or other filtering we're doing, and so having them determined at query time instead of ahead of time in the view will make this more attainable.
Describe the solution you'd like
- We'd like the number of items within each category in the category list to only include items that have the status "available" and always be up to date.
- We'd like to have an implementation that we can add additional conditions to (say, to add filtering or searching).
Screenshots
@jim - can we get some clarity here... is the "count" you are referring to the count of results on the top of the page? or the count in the categories in the left menu nav?
The reason I'm confused is I'm not sure why the counts are off in the left side... is this a seed specific issue? When we combine this with the availability filter in #672 it might get odd. As an end user, I think I'd expect the left navigation to always sum count statically, but the "results" count to always dynamically count the matching results based on current filter/sort settings. (I don't expect the left navigation to remove/add items that are based on the content pane search...)
I mentioned this to our 2 UX folks and they felt similarly.
discussed this as a group just now... our suggestion is to stick with keeping the left hand navigation hierarchy as static total counts and keep the dynamic result counts in the content pane.
I'm going to look into the seed count bug and see if I can determine the cause by comparing the admin vs. member views
found it... A-422 is marked as retired (unavailable) and displays in the librarian view... on the member side it does not display (hence the -1 proper result count) but it seems the left hand navigation counts do NOT account for this.
I suggest this issue pivot to fous on fixing that... thoughts @jim ?
Sounds good to me. I'll move this one out of the list of labeled things, but keep it in the list of issues for now in case we want to reference it.