"Email checkout receipts by default?" Doesn't Always Display in Patron Self-Registration

[John Amundson]

Evergreen 3.2.10ish

We have recently started enabling patron self-registration in the OPAC on a library-by-library basis for our network.

In doing so, we have found that "Email checkout receipts by default?" doesn't display in Self-Registration using our current setup.

From Jason Stephenson:
"The reason is that we have a single, consortium-wide event definition for Email Checkout Receipt, and opac.allow_pending_users is not true consortium-wide.

When the self-registration interface determines whether or not to display that option, it looks for an event for Email Checkout Receipt owned by one of the orgs that allows patron self-registration."

It would be nice if the setting could be made aware of the Organizational tree. For example, if the event is set at CONS and self-registration is enabled for BR1, then the option to email checkout receipts by default should display for self-registration at BR1.

[Jason Stephenson (jstephenson)]

Below is a branch that uses the ancestor tree when searching for events related to the opt-in settings for the org. units that allow patron self-registration:

https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/dyrcona/lp1890629

It works in my limited testing with CWMARS data.

[Diane Disbro (ddisbro)]

What? Is it possible for patrons to create their own accounts?

Thanks.
Diane Disbro
Pronouns: she/her
Branch Manager/Circulation Coordinator
Union Branch
Scenic Regional Library
251 Union Plaza Drive
Union, MO 63084
[phone]
<email address hidden>

On Fri, Aug 14, 2020 at 1:15 PM Jason Stephenson <email address hidden>
wrote:

> Below is a branch that uses the ancestor tree when searching for events
> related to the opt-in settings for the org. units that allow patron
> self-registration:
>
> https://git.evergreen-
>
> ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/dyrcona/lp1890629
>
> It works in my limited testing with CWMARS data.
>
>
> ** Also affects: evergreen/3.4
> Importance: Undecided
> Status: New
>
> ** Also affects: evergreen/3.5
> Importance: Undecided
> Status: New
>
> ** Changed in: evergreen
> Milestone: None => 3.6-beta
>
> ** Changed in: evergreen/3.4
> Milestone: None => 3.4.5
>
> ** Changed in: evergreen/3.5
> Milestone: None => 3.5.2
>
> ** Tags added: pullrequest
>
> --
> You received this bug notification because you are subscribed to
> Evergreen.
> Matching subscriptions: EV bug mail
> https://bugs.launchpad.net/bugs/1890629
>
> Title:
> "Email checkout receipts by default?" Doesn't Always Display in Patron
> Self-Registration
>
> Status in Evergreen:
> New
> Status in Evergreen 3.4 series:
> New
> Status in Evergreen 3.5 series:
> New
>
> Bug description:
> Evergreen 3.2.10ish
>
> We have recently started enabling patron self-registration in the OPAC
> on a library-by-library basis for our network.
>
> In doing so, we have found that "Email checkout receipts by default?"
> doesn't display in Self-Registration using our current setup.
>
> From Jason Stephenson:
> "The reason is that we have a single, consortium-wide event definition
> for Email Checkout Receipt, and opac.allow_pending_users is not true
> consortium-wide.
>
> When the self-registration interface determines whether or not to
> display that option, it looks for an event for Email Checkout Receipt
> owned by one of the orgs that allows patron self-registration."
>
> It would be nice if the setting could be made aware of the
> Organizational tree. For example, if the event is set at CONS and
> self-registration is enabled for BR1, then the option to email
> checkout receipts by default should display for self-registration at
> BR1.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/evergreen/+bug/1890629/+subscriptions
>

[Terran McCanna (tmccanna)]

Diane - you can enable a patron self-registration form on the OPAC. This doesn't create a full account, it just creates a "Pending" account and then staff can convert that to a full account. For example, in PINES, some libraries have self-registration kiosks set up so that patrons can fill out their information online rather than filling out a paper form and then they go to the desk to show their ID and get their card:

http://docs.evergreen-ils.org/3.2/_patron_self_registration.html

[Gina Monti (gmonti90)]

I consent to sign off on this patch with my name, Gina Monti, and email <email address hidden>.

[Diane Disbro (ddisbro)]

Thanks, Terran. We are already using the feature you describe to create Internet Only accounts.

[Galen Charlton (gmc)]

Hmm, I think the patch could lead to cases where a patron is given an option to register with an opt-in setting that doesn't actually apply to their library. Consider a consortium where one system has email checkout receipts enabled but another does not, but all branches allow patron self-registration. As near as I can tell, with the patch, in that scenario the opt-in setting would always show up on the form, even if the patron is registering for a branch that doesn't enable the setting.

[Jason Stephenson (jstephenson)]

Galen, what you've described is also true without the patch. In the case of a consortium where only some members allow patron registration and then only some of these allow opt-in for email of checkout receipts. The option will still be enabled for any location that allows patron registration, even if only 1 of them allows opt-in to checkout receipts. (It's true of any of the opt-in settings.)

I thought about fixing that, but it requires knowing which location was chosen from the registration drop down, or gutting the interface and only allowing registration when branch URIs are set up or the global location option is somehow set to a location that allows patron registration. I didn't like any of those solutions.

I decided that resolving this issue was outside the scope of the bug as we saw it at CW MARS.

[Terran McCanna (tmccanna)]

Removing the signoff and adding needsdiscussion due to the comments.

IMO, I think the whole form behavior could be improved by overhauling it and making it self-aware of which org unit is selected from the main dropdown, but that's a much bigger project.

I'd lean towards moving forward with this patch for now because it appears to be an improvement for some situations even though it doesn't fix all situations. However, I don't have a really strong feeling one way or the other.

[Gina Monti (gmonti90)]

Bug squash 3/2024

I tried looking this up in the MOBIUS test server but didn't see the change reflected.