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

[Sharp, Chris]

> 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.

PINES is currently working on a permissions "re-vamp" (going through the permissions one by one and deciding which group needs what at which level) - I'll keep this in mind so we can share our results as a possible permissions scheme for others (and it will obviously help PINES during upgrades/reinstalls to have our default set in the core code).

Chris Sharp
PINES Program Manager
Georgia Public Library Service
1800 Century Place, Suite 150
Atlanta, Georgia 30345
(404) 235-7147
csharp at georgialibraries.org
http://pines.georgialibraries.org/

----- Original Message -----
> From: "Dan Scott" <dan at coffeecode.net>
> To: "Evergreen Discussion Group" <open-ils-general at list.georgialibraries.org>
> Sent: Saturday, October 23, 2010 11:39:56 PM
> Subject: Re: [OPEN-ILS-GENERAL] We have a problem "Profile group"
> 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?