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?
