[Koha-bugs] [Bug 10904] would like to limit patron update request management by branch

[bugzilla-daemon at bugs.koha-community.org]

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10904

--- Comment #26 from Christopher Brannon <cbrannon at cdalibrary.org> ---
(In reply to Galen Charlton from comment #23)
> (In reply to Kyle M Hall from comment #8)
> > I think this behavior should be controlled by a new system preference
> > "IndependentBranchesPatronModifications". I also agree, IndependentBranches
> > behaviors need to be broken up into smaller sets in the future. This would
> > be a good place to start. Any new modules such as this one that need an
> > IndependentBranches behavior should have a separate preference.
> 
> I disagree that a new system preference is needed.  I think it is sufficient
> to make this behave like similar interface with regards to library selection:
> 
> * If IndependentBranches is on, you see only your libraries' stuff unless
> you're a superlibrarian
> * If IndependentBranches is off, it *defaults* to showing your library, but
> there's a selector available on the form to switch to another library.

Galen and Kyle,
Being the library that initially asked for this, I should add my two cents. 
Our consortium has this preference off (Don't prevent), because we do want to
allow staff from other libraries the ability to update patron records from any
library, update holds, etc.  I think initially, if when IndependentBranches  is
off (Don't prevent), this feature should default to the logged in library, and
should have an option to change to other libraries, as Galen stated above. 
However, it would be preferable to prevent libraries from touching some things
of other libraries, and allow them to touch others.

We opted to turn off the patron's ability to update their record when Koha
changed from e-mail notifications to this new setup, because ALL requests were
being displayed, and we didn't want everyone feeling like they had to manage
all request, or had to sift through it all.  Plus, there were some other
crucial elements missing from the new feature.  Having the library default to
the logged in library is fine by us.

As long as the number indicated on mainpage.pl reflects that.

Currently, the suggestions do NOT work that way, and has created problems.  I
can see the same problems occurring if this isn't addressed now.  If this
number doesn't reflect the default, then people are seeing a number and having
to click on the link to check if there are any requests from their patrons,
which is a waste of time.  The number should reflect the number of requests
your library has.  Maybe there should be two numbers.  One for the logged in
library, and a second for all requests.

I DO think that there should eventually be an enhancement to the
IndependentBranches for granularity control so that libraries don't even have
an option to touch certain things of other libraries, rather than the all or
nothing approach this preference dictates.  But I think that needs to be
another enhancement.  Unless you want to start tackling it one feature at a
time, like with this feature.

It seems that if we do go in the direction of granular permissions under this
preference, once it has been established that this is the direction we are
moving, then such granular preferences could be added under IndependentBranches
for features as they are added, and pre-existing features can be addressed in
independent enhancement requests.  But until this direction has been
established, I would leave it alone.

Anyway, I hope my ramblings help.  I would like to see this enhancement move on
(with the exception that the number indicated on mainpage.pl reflects the
logged in library), so we can let patrons update their accounts again.  :)

Christopher

-- 
You are receiving this mail because:
You are watching all bug changes.