> 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 [email protected] http://pines.georgialibraries.org/ ----- Original Message ----- > From: "Dan Scott" <[email protected]> > To: "Evergreen Discussion Group" <[email protected]> > 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?
