Add Parent/Guardian Field to Patron Summary Record

[edoceo]

Add a field displaying the Parent or Guardian of a Patron on display of a juvenile patron record so staff can quickly make the association when viewing the Brief Patron screen. This field will be added below the Library Card field in the Patron Info section.

Evergreen: master
OpenSRF: master
PostgreSQL 9.2, Gentoo.

[edoceo (edoceo)]

Here is the patch for this, shows the name if one is on file.

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=commit;h=fba79fa4ab98cbc766ec13dda94c153bd5df5d17

[Jason Etheridge (phasefx)]

It's worth noting that ident_type2 and ident_value2 are already displayed on both variants of the patron summary pane, though the value is not labelled as Parent/Guardian like it is in the patron editor.

Incidentally, I don't like how the Parent/Guardian concept appropriated the ident2 slot in the editor, particularly without a dedicated Parent/Guardian ident type. :-/ Probably not worth changing at this point, though.

[Pasi Kallinen (paxed)]

We will need a dedicated parent/guardian field - there are some laws governing this in Finland.

[edoceo (edoceo)]

Pasi,
  I'm not sure what you're asking? In Evergreen this data is generally
tied into identifier2 for the records of juveniles. If you need custom
work or consulting on Evergreen my company is available for hire. If you
would like the Evergreen Community to consider a feature please post a
request on https://bugs.launchpad.net/evergreen/ - if you have questions
on the Evergreen usage our mailing list is quite active - you can subscribe
to it here:
http://libmail.georgialibraries.org/mailman/listinfo/open-ils-general

/djb

--
David Busby
Edoceo, Inc.
http://edoceo.com/
206.282.6500

On Mon, Mar 18, 2013 at 1:35 AM, Pasi Kallinen <email address hidden>wrote:

> We will need a dedicated parent/guardian field - there are some laws
> governing this in Finland.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1089767
>
> Title:
> Add Parent/Guardian Field to Patron Summary Record
>
> Status in Evergreen - Open ILS:
> Triaged
>
> Bug description:
> Add a field displaying the Parent or Guardian of a Patron on display
> of a juvenile patron record so staff can quickly make the association
> when viewing the Brief Patron screen. This field will be added below
> the Library Card field in the Patron Info section.
>
> Evergreen: master
> OpenSRF: master
> PostgreSQL 9.2, Gentoo.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/evergreen/+bug/1089767/+subscriptions
>

[Pasi Kallinen (paxed)]

The data shows up in that field and can be seen in the patron summary page, but AFAIK, there's no actual functionality that uses it. (For example, and off the top of my head, no collection letters shall be sent to a juvenile, but to the parent/guardian)

When I've talked with the people here who know this stuff better, I'll file a wishlist "bug".

[Pasi Kallinen (paxed)]

(That example was one where we'll need that)

[Mike Rylander (mrylander)]

I'm with Jason regarding the annexing of ident*2 is a misstep.

First, there is the user group functionality, which has the concept of a group lead and was designed originally to help fill this roll. It's not specifically about families, but can certainly be used in this way, or as s stepping stone to what Pasi needs. It already embeds the core concept (user A is suborinate in some way or ways to user B) without ad-hoc removal of other features.

Second, there is the as-yet unfleshed, but more well-matched "friend" infrastructure that allows things like taking actions for others, or being assigned responsibilities for others, like paying fines. Proceeding down that path would be a more fruitful, IMNSHO.

The patch posted might be useful as a locally retained customization to get some over the hump in the short term, but it isn't a longterm solution.

[Galen Charlton (gmc)]

> The data shows up in that field and can be seen in the patron summary
> page, but AFAIK, there's no actual functionality that uses it. (For
> example, and off the top of my head, no collection letters shall be sent
> to a juvenile, but to the parent/guardian)

There is an additional mechanism already present that could be a
starting point, namely patron groups. Patrons that are linked
together via actor.usr.usrgroup will have the total fine balance owed
by the group displayed in the staff client, and designating a patron
as a group lead is effectively asserting that they're financially
responsible for the group.

There isn't currently much more to the feature than that, but even its
current state, it gives us the ability to store patron/responsible
patron relationships between patrons, from which to build things like
group notices and (perhaps) the ability for group leads to see the
financial obligations occurred by other group members.

[Pasi Kallinen (paxed)]

So, to summarize, there are three things that fulfill slightly similar roles, but don't actually do much: 1) the (overloaded) ident*2 fields, 2) the "friends" feature, 3) usrgroup -feature.

Would it make sense to merge all these?

[Kathy Lussier (klussier)]

Pasi,

I wouldn't want to merge the friends and usrgroup feature. We typically use usrgroup to link together family accounts where people share the same address. When pulling up the user record for one patron in the group, there is an easy way to see if there are outstanding fines/overdues for another member of the group.

Although the friends feature hasn't been leveraged yet, my understanding is that it would support voluntary relationships among users. Holds pickup is one area in which we've discussed the possibility of using the friends feature. You might want to designate a roommate, friend or co-worker as a person who is allowed to pick up your holds, but you certainly wouldn't want to link your patron account to theirs.

[Andrea Neiman (aneiman)]

Bumping this because with the advent of the webclient, the ident*2 field was (intentionally) given its correct name of "Secondary Identification" in the patron editor.

However, we have heard from customer libraries that they want Parent/Guardian restored -- so I'm nudging this ticket in the hopes that we can restart the conversation about creating a proper Parent/Guardian field for the patron editor.

[Terran McCanna (tmccanna)]

We've put some development funds into addressing this - please see:

https://bugs.launchpad.net/evergreen/+bug/1762480

[Andrea Neiman (aneiman)]

Great news! Thanks, Terran & PINES.

(I shake my fist at Launchpad search)