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

[Cynthia Williamson]

I don't think it was a bad idea to try to anticipate some basic needs for
permissions for out of the box EG, we found it useful to have something
there when we were starting out.  As the documentation develops and
improves, the enhancement of the out-of the box settings will be easier for
newbies.
Having said that though, I love the idea of developing library personas,
this is a very interesting idea Dan.   I wonder if this is something that
could be attempted at Hackfest at EG 2011?   A few years ago, we did some
work on student personas for customer service development at Mohawk so I
have a tad of experience ....wonder if others in the EG community have
more?
Oh & I do think the idea of a pop-up dialogue to say "you don't have
permission..." would be helpful .. I remember some early trouble shooting
where I spent of a bit of time narrowing down troubles folks were having
that ended up being about permissions.
Cynthia

On Sat, Oct 23, 2010 at 11:39 PM, Dan Scott <dan at coffeecode.net> wrote:

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



-- 
* Doug’s Law “You can have information or
you can have a life, but you can’t have both.”