[OPEN-ILS-DEV] ***SPAM*** Re: Feature Proposal: Enhancements to Patron Statistical Categories

[Scott Prater]

Thanks, Thomas.


> On disallowing of setting "disallow free text" when you have no entries:

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.

> On the "one default entry" stuff:
>
> This may be best done as an inherited mapping of org unit, stat cat, and
> default. This would allow different org units to have different default
> entries, but still allowing a general consortium-level default if a library
> hasn't picked one. This may also be best done for both actor and asset stat
> cats, for multiple reasons.
>
> My reasoning for org unit level defaults is that as each org unit can have
> different entries. With no guarantee of consortia-wide entries available,
> there may not be a single entry that *can* be the default globally.

This also makes sense to me, and addresses a problem I hadn't really
spent much time on yet:  how to mark an entry as default in a clean
way in the db schema.  I'll take a look at the code and database
schema, see how the pieces fit together, and come back with a proposal
for inherited default entries.

> Other considerations:
>
> In addition to providing a "disallow free text" option, a regex validator
> for the free text might be useful. You could then say that an existing entry
> has to be selected OR the free text has to match the regex. This would
> allow, say, date entry in a specifically decided upon format, say a "Friend
> of Library Until" category. The entries could then include a "Permanent" or
> "Board Member" type option that isn't subject to the date regex.

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.

> Finally, I have worked with both the statistical categories and editor for
> them (adding the SIP Export options, for example) as well as the patron
> editor (dynamic required fields and multiple validation options) to be of
> help in getting this going. If you need assistance, let me know.

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.

-- Scott