[OPEN-ILS-GENERAL] We have a problem "Profile group"

[Dan Scott]

On Sat, Oct 23, 2010 at 08:29:55AM -0400, Cynthia Williamson wrote:
> agreed - that it makes sense to have a default setting with fewer rather
> than more permissions ... I wasn't necessarily arguing that out of the box a
> circulator should have more permissions  - just that many libraries will
> have many different workflows & needs at the circ desk.  Should more options
> be added to the out of the box settings?  Not sure, I bet there are really
> systems where a volunteer empties the drop box and the library might want
> that person to only be able to check in books.  Don't think we could ever
> please everyone in this regard.  The flexibility of the system is both its
> joy and its frustration :)

Yes, flexibility; there are over 400 different permissions, permission
groups can inherit from parent groups, permissions are scoped by depths
in the hierarchy, and users can belong to multiple groups. The "do not
assign patron registration permission to a group out of the box"
argument would require potential adopters to understand all of that to
be able to go through a simple test drive of Evergreen with anything
other than the all-powerful "admin" user. For the potential adopter in
that scenario, Evergreen's flexibility is just a synonym for complexity
with few positive connotations.

And I suspect that's why the "seed data" SQL script has included a
comment since at least 2006 that says:

-- XXX Incomplete base permission setup.  A patch would be appreciated.

I've been chipping away at that over time. I have no illusions that the
choices we've made so far are the right choices for every library; I'm
sure they are not. But my approach has been to err on the side of having
permissions granted, in the assumption that a library that gets to the
point of actually putting Evergreen into production will become much
more interested in permissions models and be able to remove permissions,
if needed.

Let's assume, though, that it was a bad idea for me to be trying to
provide useful out-of-the-box permissions for the generic out-of-the-box
permission groups. Another option, for a sufficiently motivated and
interested group of people, would be to rip out the base permissions
scheme from Open-ILS/src/sql/Pg/950.data.seed-values.sql and create new
sets (emphasis on plural) of basic configurations, based on documented
assumptions.

For example, there could be a basic configuration set for a library
system that shares an Evergreen instance strictly for the cost-sharing
of hardware/hosting/system administration. So there would be heavily
restricted holds configuration settings, patron opt-in would be enabled,
and permissions would be granted at branch depths. And perhaps the
library hierarchy consists of branches connected directly to the
consortium.

There could also be a basic configuration set for a state library system
in which patrons can be registered and edited at any branch in the
consortium, holds and transits occur across systems (with differing
thresholds, etc). Something like the original use case for Evergreen,
say :)

There could also be a "no configuration" option that would enable
experienced Evergreen administrators to load their own preferences from
scratch. This could have a library hierarchy that only consists of a
single consortium branch.

These options could be added as a flag to eg_db_config.pl, which would
make it easy for a potential adopter to try out different
configurations. 

So, if that theoretically motivated and interested group were to come up
with these different base configuration sets, we could document them
(using them as illustrative examples of how to set things up in
Evergreen and why Evergreen's complexity is actually a good thing, not
just a PITA); we could develop new functionality while keeping these
base configuration sets (library personas, if you will) in mind to
consider how a new feature would be used by each of our targeted system
types; and we could write tests that exercise Evergreen functionality in
these different environments, rather than relying on quick tests with
the "admin" user or reports from the field to flag obvious problems.

All this is obviously about more than just adding one permission to a given
group for a better out of the box experience. But it's an opportunity to
bring together a few different threads that have come up on the list and
in IRC and in my mind in the past, and maybe it will spark other ideas.

Mmm, one other thought on a different angle - if a given staff user
doesn't have permission to add users with any kind of profile, we might
want to pop up a dialogue to tell them that explicitly as soon as they
enter into the "Register Patron" window - and perhaps list which groups
(if any) do have the ability to add users, and / or link to the
pertinent documentation on registering users & the corresponding
permission requirements?