...
For tech lead of mod-template-engine. Reference: UXPROD-5029. One requirement is a new option to add a bar code image for item.instanceHrid in templates. There are already functions generating bar code images in templates, but those functions assume that bar code values are in tokens named something with 'barcode', so some rearrangements in mod-template-engine are likely required to support image generation for values in tokens named differently, like 'item.instanceHrid'.
From UXPROD-5029:
{{item.instanceHrid}} {{item.instanceHridImage}} Instance HRID - A text and barcode representation of the Instance HRID
To be understood by the developers. Reference: UXPROD-5029. Any item can be tagged with one or more statistical codes, represented as a list of UUIDs in the item object. The codes would have a label and they would belong to a category (a code type), both of which could be looked up outside of the item itself. There is a requirement to be able to select certain codes as tokens, and if selected by the user they should be represented as boolean values based on whether or not the given codes are present on the item. It is not entirely clear, what criteria should be used in deciding which codes to make available for selection, exactly how the token selector UI would then present these options, and how the true/false value would ultimately be used in the notice/slip template. Mock-ups of the token selector and the template editor with data examples might help. It cannot be ruled out that some refactoring of the template engine would be required to support the logic of this. With clarified requirements, the performance impact could be analyzed. For example: Each such lookup -- be it by category, label or UUID -- would be very cheap, but if its done for many more items or codes than strictly necessary it could have a cumulative impact on the general check-in/check-out procedure, which is already strained by a large numbers of (equally cheap) look-ups.
To be investigated. Reference: UXPROD-5037. One requirement is to add a new boolean property with a default of false to the request object to indicate that a request is a reading room request. The ticket lists a task of back-filling existing requests with “false” since no requests are reading room requests so far. Back-filling might not be necessary, though, given that the default is already “false”.
Questions regarding the item? .
As an item is being picked up by the patron and returned by the patron, the request status will change. What about the item status?
In the earliest design considerations it was suggested that items were statically flagged as being reading room items; it appears that this idea has been abandoned?
What is the role of the statistical codes of code type “Reading room circulation”, that will be tagged on the item?