Quoting Scott Prater <[email protected]>:
Here was my thinking on that: if possible, it would be good to avoid
the situation where a user goes to register a patron but can't,
because a statistical category is required, and the values must come
from a fixed list, but no entries have been added to the list.
Your explanation of how the statistical categories and entries are
created, and the consortial use case, makes sense to me. So rather
than not allowing the administrator to configure required fixed-field
categories without entries, we should simply point out that possible
gotcha in the documentation, and rely on administrators to make sure
their categories are correctly configured. If that sounds reasonable
to you, I'll update the proposal to remove that constraint.
The same problem exists for copies and a required asset stat cat,
technically. So however that is being handled (or not) is probably fine.
So this would imply that an optional regular expression would be
stored in the database, correct, separate from the entries. but
linked? I can see how that would be useful, but I (personally
speaking) would be reluctant to include it in this first round of
enhancements, and would be more inclined to save it for later, unless,
of course, it were a trivial change to implement at the same time I'm
implementing the others.
Yes, and implementing it would be trivial when doing the work of
disabling free-text input under certain circumstances. In fact,
disabling free-text input could be as simple as defining a regular
expression of "^$", that is to say it must be empty. If the field is
required it can't be empty, so if free text must be empty and the
field can't be you obviously need to pick a value. ;)
Thanks again. I'm sure I'll be back in touch; if you don't mind, to
start with I'd like to run database changes by you, for comments and
sanity check, once I've probed some more in the code and schemas.
Feel free.
Thomas Berezansky
Merrimack Valley Library Consortium
