No subject
Fri Apr 16 10:15:54 EDT 2010
*
--00032555c02655850e04935c1998
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
I don't think it was a bad idea to try to anticipate some basic needs f=
or permissions for out of the box EG, we found it useful to have something =
there when we were starting out.=A0 As the documentation develops and impro=
ves, the enhancement of the out-of the box settings will be easier for newb=
ies.=A0 <br>
Having said that though, I love the idea of developing library personas, th=
is is a very interesting idea Dan.=A0=A0 I wonder if this is something that=
could be attempted at Hackfest at EG 2011?=A0=A0 A few years ago, we did s=
ome 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 mo=
re?=A0 <br>
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 troubl=
e shooting where I spent of a bit of time narrowing down troubles folks wer=
e having that ended up being about permissions. <br>
Cynthia<br><br><div class=3D"gmail_quote">On Sat, Oct 23, 2010 at 11:39 PM,=
Dan Scott <span dir=3D"ltr"><<a href=3D"mailto:dan at coffeecode.net">dan@=
coffeecode.net</a>></span> wrote:<br><blockquote class=3D"gmail_quote" s=
tyle=3D"border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8e=
x; padding-left: 1ex;">
<div class=3D"im">On Sat, Oct 23, 2010 at 08:29:55AM -0400, Cynthia William=
son wrote:<br>
> agreed - that it makes sense to have a default setting with fewer rath=
er<br>
> than more permissions ... I wasn't necessarily arguing that out of=
the box a<br>
> circulator should have more permissions =A0- just that many libraries =
will<br>
> have many different workflows & needs at the circ desk. =A0Should =
more options<br>
> be added to the out of the box settings? =A0Not sure, I bet there are =
really<br>
> systems where a volunteer empties the drop box and the library might w=
ant<br>
> that person to only be able to check in books. =A0Don't think we c=
ould ever<br>
> please everyone in this regard. =A0The flexibility of the system is bo=
th its<br>
> joy and its frustration :)<br>
<br>
</div>Yes, flexibility; there are over 400 different permissions, permissio=
n<br>
groups can inherit from parent groups, permissions are scoped by depths<br>
in the hierarchy, and users can belong to multiple groups. The "do not=
<br>
assign patron registration permission to a group out of the box"<br>
argument would require potential adopters to understand all of that to<br>
be able to go through a simple test drive of Evergreen with anything<br>
other than the all-powerful "admin" user. For the potential adopt=
er in<br>
that scenario, Evergreen's flexibility is just a synonym for complexity=
<br>
with few positive connotations.<br>
<br>
And I suspect that's why the "seed data" SQL script has inclu=
ded a<br>
comment since at least 2006 that says:<br>
<br>
-- XXX Incomplete base permission setup. =A0A patch would be appreciated.<b=
r>
<br>
I've been chipping away at that over time. I have no illusions that the=
<br>
choices we've made so far are the right choices for every library; I=
9;m<br>
sure they are not. But my approach has been to err on the side of having<br=
>
permissions granted, in the assumption that a library that gets to the<br>
point of actually putting Evergreen into production will become much<br>
more interested in permissions models and be able to remove permissions,<br=
>
if needed.<br>
<br>
Let's assume, though, that it was a bad idea for me to be trying to<br>
provide useful out-of-the-box permissions for the generic out-of-the-box<br=
>
permission groups. Another option, for a sufficiently motivated and<br>
interested group of people, would be to rip out the base permissions<br>
scheme from Open-ILS/src/sql/Pg/950.data.seed-values.sql and create new<br>
sets (emphasis on plural) of basic configurations, based on documented<br>
assumptions.<br>
<br>
For example, there could be a basic configuration set for a library<br>
system that shares an Evergreen instance strictly for the cost-sharing<br>
of hardware/hosting/system administration. So there would be heavily<br>
restricted holds configuration settings, patron opt-in would be enabled,<br=
>
and permissions would be granted at branch depths. And perhaps the<br>
library hierarchy consists of branches connected directly to the<br>
consortium.<br>
<br>
There could also be a basic configuration set for a state library system<br=
>
in which patrons can be registered and edited at any branch in the<br>
consortium, holds and transits occur across systems (with differing<br>
thresholds, etc). Something like the original use case for Evergreen,<br>
say :)<br>
<br>
There could also be a "no configuration" option that would enable=
<br>
experienced Evergreen administrators to load their own preferences from<br>
scratch. This could have a library hierarchy that only consists of a<br>
single consortium branch.<br>
<br>
These options could be added as a flag to <a href=3D"http://eg_db_config.pl=
" target=3D"_blank">eg_db_config.pl</a>, which would<br>
make it easy for a potential adopter to try out different<br>
configurations.<br>
<br>
So, if that theoretically motivated and interested group were to come up<br=
>
with these different base configuration sets, we could document them<br>
(using them as illustrative examples of how to set things up in<br>
Evergreen and why Evergreen's complexity is actually a good thing, not<=
br>
just a PITA); we could develop new functionality while keeping these<br>
base configuration sets (library personas, if you will) in mind to<br>
consider how a new feature would be used by each of our targeted system<br>
types; and we could write tests that exercise Evergreen functionality in<br=
>
these different environments, rather than relying on quick tests with<br>
the "admin" user or reports from the field to flag obvious proble=
ms.<br>
<br>
All this is obviously about more than just adding one permission to a given=
<br>
group for a better out of the box experience. But it's an opportunity t=
o<br>
bring together a few different threads that have come up on the list and<br=
>
in IRC and in my mind in the past, and maybe it will spark other ideas.<br>
<br>
Mmm, one other thought on a different angle - if a given staff user<br>
doesn't have permission to add users with any kind of profile, we might=
<br>
want to pop up a dialogue to tell them that explicitly as soon as they<br>
enter into the "Register Patron" window - and perhaps list which =
groups<br>
(if any) do have the ability to add users, and / or link to the<br>
pertinent documentation on registering users & the corresponding<br>
permission requirements?<br>
</blockquote></div><br><br clear=3D"all"><br>-- <br><b> Doug=92s Law =93You=
can have information or <br>you can have a life,=20
but you can=92t have both.=94<br>From Player One by Douglas Copeland<br></b=
><br>
--00032555c02655850e04935c1998--
More information about the Open-ils-general
mailing list