Need Evergreen to capture who and where patrons are registered

Bug #1607827 reported by Blake GH
118
This bug affects 24 people
Affects Status Importance Assigned to Milestone
Evergreen
Confirmed
Wishlist
Unassigned

Bug Description

2.9.1

We have a need for the software to capture the org unit that the patrons was registered (not home library). We also would like to capture the staff client user that registered the patron. Might as well grab the workstation as well.

Tags: patron
Revision history for this message
Chris Sharp (chrissharp123) wrote :

Blake,

Could this be achieved by improvements to the auditor schema that would record the creation of user records (and not just updates), or would this information need to be visible in the client?

Chris

Revision history for this message
Blake GH (bmagic) wrote :

Chris,

This information needs to be visible in the staff client. At least that is the intent from our libraries.

Revision history for this message
Michele Morgan (mmorgan) wrote :

I would be in favor of recording the following in the actor.usr table:

creator
create date
editor
edit date

This is in keeping with the asset.call_number and asset.copy tables.

Revision history for this message
Mike Rylander (mrylander) wrote :

While it's not spelled the same, we do have an edit date field on actor.usr called last_update_time which is maintained by a trigger. And there is create_date.

For creator and editor, what values would we supply to existing records? Or would those be NULLable?

And, for "creating org unit" from Blake's original request, how would that be populated, if it were? Perhaps by home_ou?

Thanks!

Revision history for this message
Blake GH (bmagic) wrote :

Mike,

Perhaps the upgrade sql could use a value of "1" for editor and creator for those pre-existing actor.usr rows? Or not.

I believe the new editor and new creator columns should be a SQL foreign key references to actor.usr.id, don't you agree? Null might be OK actually, now that you mention it.

Upon row insert, the creating_workstation column could be populated with actor.workstation.id. The creating org unit could be equal to the actor.workstation.owning_lib.

Is there an issue with these ideas?

Michele - actor.usr already has create_date and last_edit_date.

Revision history for this message
Michele Morgan (mmorgan) wrote :

I would say the existing create_date and last_edit_date fit the bill.

As for the existing records, I'm leaning toward NULL for the creator and editor. I would agree with Blake that the creator and editor should reference actor.usr.id, and that the creating_workstation should reference actor.workstation.id.

As for the "creating org unit", do we actually need that if it would capture actor.workstation.owning_lib, since we'll already be capturing the workstation?

And while we're at it, would it be useful to capture the last_last_edit_workstation?

Revision history for this message
Joan Kranich (jkranich) wrote :

Both the creating_workstation and last_edit_workstation columns would be helpful.

Michele Morgan (mmorgan)
Changed in evergreen:
status: New → Confirmed
assignee: nobody → Michele Morgan (mmorgan)
Elaine Hardy (ehardy)
tags: added: patron wishlist
Changed in evergreen:
importance: Undecided → Wishlist
tags: removed: wishlist
Revision history for this message
Terran McCanna (tmccanna) wrote :

I'm adding the phrase "created by" in the comments so maybe I can find this bug next time I'm looking for it :D

Revision history for this message
Erica Rohlfs (erohlfs) wrote :

In the spirit of Terran's comment and because of a recent EG general list discussion, I'm adding "staff initials" - and add the ability to enter staff initials when creating a new patron account / patron registration in the comments so hopefully this bug will show up in future search results. Even though I agree with the more automated approach of logging the creator / modifier of a patron account :)

Revision history for this message
Bill Ott (bott) wrote :

At GRPL, we added a similar functionality circa 2012. We store a creator and create_date in actor.card, so we can see who issued each library card. By extension, this includes the original account creator. While it's not a clean patch because of our local git repo, I've attached a patch to show the deatils of the changes. They are pretty minor.

Revision history for this message
Jason Stephenson (jstephenson) wrote :

Michele,

Are you still looking into this? If not, could you unassign yourself from the bug?

Thanks,
Jason

Revision history for this message
Michele Morgan (mmorgan) wrote :

Thanks for the poke, Jason. I had plans to tackle this, but will unassign myself until those plans start to solidify.

Changed in evergreen:
assignee: Michele Morgan (mmorgan) → nobody
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.