Display holdings with no barcode

[damien-git]

We need to display FOLIO items with no barcode, but for some reason they are hidden in Vufind, and this is hard-coded. We can of course edit that template, but I was wondering why Vufind is hiding these items. Patrons might want to see if for instance an item is on order, or if one is available but only at the library (and hence doesn't need a barcode).
If there is a reason to hide them in some cases, I guess another config property could be useful (I know, there are lots of them already)...

[demiankatz]

@damien-git, this assumption has been built into the software almost from day one (the decision probably pre-dates me). I would have to guess that the thought was, if there is no barcode, there is no other data either -- but of course that assumption is not really true for all systems or all situations. I'm certainly not opposed to making this configurable... just a question of where/how.

A couple of thoughts that might help shape a decision:

1.) It might be a good idea to build a method somewhere that determines whether or not a given holding row should be displayed. This method could then be the place where we apply configurations, but it could also serve as an extension point if somebody has really specialized logic they would like to implement by extending a class. The two most obvious possible homes for this logic would be a view helper (maybe a new "holdings" helper that might be able to serve other purposes in the future) or the existing HoldingsILS RecordTab class (which would require less work to set up, but would result in the code being less easily shareable in other contexts).

2.) It appears to me that the status-full.phtml template used for displaying detailed holdings in search results does NOT apply this same barcode logic (unless the filtering is happening in the controller code; I confess I didn't do a deep dive or close inspection). It seems to me that we would want these things to behave consistently... and that would probably be a strong argument toward the "view helper" approach, since it could be applied to this template as well as the various holdings tab templates.

What do you think?

I should also note that GitHub discussions is a relatively new feature, and I'm not sure how many people are paying attention to it. If you want more input, I'm happy to share a link to this on the listservs, etc.

[damien-git]

I agree with you. The current code is a bit inconsistent, as it checks if there is a barcode within the block that only allows items with a barcode. And as you noticed, status-full.phtml does not check that that, so it displays more information than the full record page even though it is just for search results (I just checked it).
I am happy with the feeback I get from you here, I think it makes sense to move discussions from sourceforge to github at this point.

[demiankatz]

That seems like an argument for the view helper approach. Are you interested in taking a first stab at implementing something, or do you need more help/guidance to get started? I'm out of office tomorrow but can probably help in more detail next week!

As for moving from listservs to Discussions, I'm not sure that I'm entirely ready to abandon the listservs (they're at very least good for sending out announcements, minutes, etc.) but it certainly wouldn't hurt to encourage people to use Discussions for brainstorming and getting support. I know it's a year away now, but this might be a good conversation for next year's Summit.

[damien-git]

@demiankatz I could probably add a config to control this behavior, but I'm not sure how to write a view helper. From what I've seen, the templates (which are easily customizable), are usually used to output HTML, not to make decisions. And the output is different for status-full and the Holdings tab.

[demiankatz]

@damien-git, I've opened #2553 as a proof of concept for a holdings view helper that allows configurable empty barcode behavior.

I was hoping to also apply this logic to the status-full.phtml file, but I see now that it isn't possible, because status-full.phtml uses the output of "getStatus" while the holdings tab uses the output of "getHolding." According to the spec, getStatus does not need to include barcodes, so we can't apply the same rules there. This all seems to be further evidence that the existing default behavior doesn't really make sense... but I think there are a variety of paths we could take for addressing this (e.g. change the default behavior, change the way full status works, etc., etc.).

[damien-git]

@demiankatz Thanks for providing that PR, this was beyond what I could have done given my current understanding of Vufind.
My current feeling is that we should display all holdings in the holdingsils templates, regardless of barcodes. People can override these templates as well as status-full.phtml to add their logic if they need to. But we don't even know of a use case. I suspect there are currently more people who do not see these holdings when they would like to, than people who actually don't want to see them when they have no barcode. The only issue with that is backward-compatibility, and it would require a warning in the release notes.

[demiankatz]

That's a good point -- it would probably be less confusing in the long run to change the default behavior, unless somebody can come up with a compelling reason why the barcode filtering is necessary. This would help to address the current inconsistency with status-full.phtml, among other things. We could include a note in the changelog about it, and we could also indicate in the configuration file that alternate item filtering logic can be applied by customizing the view helper. I'll solicit some further opinions before making further changes, but hopefully we can keep this moving along!