Contextual Preferences RFC
The problem
The circulation matrix has a column for each kind of rule it keeps track of; this makes adding to the matrix cumbersome and unsustainable.
System preferences are global, yet many of them should be configurable on a per branch or per patron type level.
The solution
A new table, let's call it contextualpreferences, that can house circulation rules and other kinds of preferences in a key-value based setup. This is infinitely extensible, and makes individual circ rules more granular (a universal hold limit can be set in just one row, instead in a column of every rule in the matrix).
Data structure
| Column name | Data Type | Allow NULL? | Key? |
| branchcode | VARCHAR(10) | yes | FK to branches |
| categorycode | VARCHAR(10) | yes | FK to categories |
| itemtype | VARCHAR(10) | yes | FK to itemtypes |
| preference | VARCHAR(64) | no | |
| value | text | yes | |
| preferencetype | VARCHAR(64) | yes |
PRIMARY KEY: (branchcode, categorycode, itemtype, preference)
Preference selection
NULL values in branchcode, categorycode, and itemtype are the DEFAULT values, and are selected (in the order currently determined by the circulation matrix) most specific to least specific. NULL/NULL/NULL is the global default combination for any given preference, and should exist in the database for any required values -- test for this
Implementation Plan
- build new data table and it's accessor module
- build new administration pages
- migrate in values, replacing old code accessors with new ones
- document, document, document