Composite Record Attributes

[Mike Rylander]

This follows on from the new Multi-Valued Record Attributes work ( https://bugs.launchpad.net/evergreen/+bug/1269141 ).

In Evergreen, the administrator has the ability to define Record Attributes for use as filters and sorters. However, each field is defined separately, and there is no way to specify a combination of values in a single search filter. Because of this, one cannot create a single dynamic user interface component that uses more than one Record Attribute for filtering.

Likewise, even though combinations of Record Attribute Values can be evaluated within custom TPAC code, there is not centralized mechanism for defining and examining calculated or derived states or attributes of a bibliographic record, making custom UI behavior significantly more difficult to design and implement, as well as brittle and upgrade-resistant.

Overview
-------------

ESI will create an abstraction on top of the Record Attribute infrastructure to allow the aggregation of multiple, cross-Attribute values under a single search filter value, accessible through new, dynamic filters.

Each QueryParser filter will be created by the addition of a Composite Record Attribute Definition. For instance, one may wish to create a Composite Record Attribute Definition for an abstract "Item Type" interface component that uses information from the item_type, vr_format, bib_level and item_form Record Attribute Definitions, with each Composite Record Attribute Value having a different combination of Record Attribute Values from some or all of these Record Attribute Definitions. In this way, as single interface component might be presented as a dropdown with options such as "All Books", "All video recordings", "DVDs", "VHS Tapes", "E-Books", "Audio Books" and "Large Print Books". Of particular note are the "DVDs" and "VHS Tapes" entries, which include information from Record Attribute Definitions completely separate from the others. Additionally, the Composite Record Attribute Values defined by this Composite Record Attribute Definition can be used to drive behavioral logic, such as alternate icon display or link generation, in upgrade-friendly template adjustments.

Plan
------

This feature set will require UI, Database and QueryParser work to accomplish, with seed data work to implement examples.

Two new data structures are required: Composite Record Attribute Definition, which will record the filter name for use in queries and a translatable label for display in the OPAC and elsewhere, and group Composite Record Attributes together; Composite Record Attribute Values, which will record the new coded values to represent a combination of Record Attribute Values, a translatable label for display in interfaces, and a mapping table to aggregate entries in the Code Value Map under the Composite Record Attribute Value. The Composite Record Attribute Definition filter name must be unique with respect to both other Composite Record Attribute Definitions and existing Record Attribute Definitions. The derived values mapped from Composite Record Attribute Values will be stored in the record attribute table along side existing Record Attribute Values.

QueryParser will be modified to accept Composite Record Attribute Definitions as initial setup data. These will be interpreted in a way similar to Record Attribute Definitions, and will look like standard QP filter syntax elements for user input. When generating SQL, the Composite Record Attribute Values will be searched in exactly the same way as Record Attribute Values.

The seed data will ship a basic replacement for the record format filter implemented as an Composite Record Attribute Definition, and the TPAC will be given the ability to use this instead of the hard-coded version available today.

This work is also intended to support improved Metarecord Hold functionality by providing a configurable "format" selection set for use by MR hold users.

[Mike Rylander (mrylander)]

I can haz composite attributes!

You'll find the code, sans the "icon project" seed data that is still being defined, linked below. This is an official pullrequest, but merging can wait until the icon selector attribute defs are available, assuming that happens soon.

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/miker/composite-record-attributes

[Bill Erickson (berick)]

For reasons that are not clear, dojo.require()'s for Button and FilteringSelect are needed on one server but not another. *shrug*. Added the missing requires and pushed a rebased branch to

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/berick/composite-record-attributes

[Dan Wells (dbw2)]

I am really excited about this branch and its cousin, and would like to test them soon. Before I dive in, I have a few questions:

1) Are there release notes yet for this? I know there is a fair amount of description already available, and maybe it will be obvious how it works once I see it, but knowing ahead of time what to expect can really help.

2) We have quite a few potential 'cra' definitions (which we have been using via custom code) which might be useful for the seed data. Who is working on the icon selector attribute defs, and how best might we work with them?

Thanks!

[Mike Rylander (mrylander)]

Dan,

I'm glad you're excited! You can ignore it's cousin branch (MVF) now, as it's subsumed into this one. I posted that separately to help easy review for folks that wanted to start absorbing the new stuff early, but it shouldn't be considered separately. To that end, I may merge the upgrade scripts -- but I may not, since there's really only on duplicative part.

For (1), I'm working on release notes, which will be very similar to the initial description but with some updates from details and clarification that came about at implementation time and a basic UI description. There will also be end-user documentation, which we'll be creating over the next few weeks.

For (2), I don't know if the individuals actually creating those definitions are active within the community (though, of course, there are at least folks within their organization with whom you could liaise). MassLNC, SITKA and a couple other groups banded together to fund this work, but I'm not sure that "the usual suspects" from those orgs are doing the defining. However, any overlap will likely be orthogonal to their specific target (icon selection needn't be strictly the same as, say, a "formats" replacement). So, I would encourage all comers to offer example uses -- I bet we can come to a sample set for several use cases pretty quickly.

Note, too, that this branch is meant to support the Metarecord Holds work we're doing right now. Specifically, we'll be creating a CRA to manage constituent record format selection in a more flexible way than in the JSPAC days. So you can expect some example data targetted at that use case.

[Bill Erickson (berick)]

I've pushed two additional commits to a new collab branch (including all previous commits):

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/collab/berick/composite-record-attributes

1. Seed data for a new stock set of record format specifiers. This includes attribute definitions, coded values maps, and composite definitions. The new definitions are much more expressive than the old-style item_type-based formats. This commit also includes a new global flag for setting which record attribute you wish to use as your icon formats configuration (so you can change them without having to change the code and/or revert to the item_type approach). (Note, the TPAC will also leverage this for configuring metarecord holdable formats attributes).

I'm sure these will evolve over time, but eyes on them earlier means less churn (i.e. re-indexing).

2. The TPAC now looks for the icon format attribute and pulls format information from the record based on this attribute. I also copied the item_type-style icons into a new directory to match the new default attribute icon of "icon_format" (alternate name suggestions welcome) so that the opac can start using the new attribute out of the box, with limited visual change for now.

As a future follow-up to this, we should expand and improve the format icons so that each default format has a unique icon. As it stands, there are not enough images to uniquely identify all of the formats by image alone.

[Mike Rylander (mrylander)]

I've rebased this against master and squashed it down a good bit, removing some of the upgrade complexity in the process. Find the new branch at: http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/collab/miker/mvf-cra-squash-rebase

[Mike Rylander (mrylander)]

This is embodied in the metarecord holds branch at: https://bugs.launchpad.net/evergreen/+bug/1053397https://bugs.launchpad.net/evergreen/+bug/1053397

That branch contains all this code and more. Whoever decides to review (and hopefully commit) that other branch can ignore this one, and mark it invalid. IOW, the branch on this bug stands on its own but is a waypoint to the MR holds feature, assuming that goes in.

[Dan Wells (dbw2)]

Removing pullrequest from this bug, since this code is currently being reviewed in the metarecord holds bug referenced above.