Non-Intuitive OUS type can cause Default Net Access Level setting to fail

[Jason Boyer]

When registering a new patron in the webclient the "Default level of patrons' internet access" isn't currently used, with the field initially showing as invalid. Since we have such a setting we may as well use it.

[Jason Boyer (jboyer)]

Here it is, including an enhancement to the OUS Editor to use the correct type for that setting rather than making you use raw ID numbers (or as I have seen in our database, various permutations of the word "filter").

Post application this can be tested thusly:
Set a default access level in the OUS (don't worry about any potentially invalid data in existing entries, they're essentially ignored.) See that you can 1, select the name of the level from a list and 2, you can tell what the setting is without having an encyclopedic knowledge of the seed data.
Register a patron, note that the net access level you selected is pre-selected.
Victory.

Branch lives here: http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/jboyer/lp1802682_default_net_access working/user/jboyer/lp1802682_default_net_access

[Bill Erickson (berick)]

Jason, I'm unable to confirm this bug. When I change the value, it's reflected in the Register New Patron interface after a refresh. It looks like the value is getting applied in the set_new_patron_defaults() function.

+1 to the setting datatype change, though.

[Jason Boyer (jboyer)]

In yet further necrobranchy I offer up this code in the place of my earlier attempt:
https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/jboyer/lp1802682_cnal_ous_type / working/user/jboyer/lp1802682_cnal_ous_type

Thinking back on this bug I imagine what happened initially was that the name of the desired value was entered into the default value setting which then made it appear that the value wasn't being used.

[Terran McCanna (tmccanna)]

Works for me! My signoff is at:

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

[Mike Risher (mrisher)]

I tried this out on the https://terran-master.gapines.org server. Here's the steps I went through for testing:

1. With a BR1 workstation set "Default level of patrons' internet access" to "No Access"
2. Visit the register patron page, clear cache and do a hard refresh
3. Look at the default net access level and confirm that it's "No Access"

Step 3 failed for me. No default access level was set. It appears the registration page disregarded the "No access" default I set in step 1.

I also tested this on a server without the patch. The behavior was the same, but in step 1 I had to type out the words "No Access" rather than using a dropdown menu to select the value. Is that part of the behavior the patch changes as well? Is this what's meant by "Non-Intuitive OUS type" - a value other than one of the options in the dropdown menu?

Holding off marking this "needs repatch" for now, because I want to be sure I went through the correct steps to test this.

[Terran McCanna (tmccanna)]

Hi Mike - terran-master doesn't have that patch installed. It's on acorn.evergreencatalog.com

[Mike Risher (mrisher)]

Aha! Thank you for seeing my error, Terran. I re-did the testing on the acorn.evergreencatalog.com server and I see the default net access level showing. That part looks great. I have no objections to the sign off on this.

Am I correct in thinking that the "Non-Intuitive OUS type" problem is being solved by the dropdown that lets you choose the type of net access?

[Jason Boyer (jboyer)]

Mike, you're right in that the ability to select from a dropdown is the fix but the root issue is that without this change staff just have to know that the correct values to enter into that setting are database ids (3 for No Access), not the textual names displayed in the dropdown. When you type the name of the setting the value is un-set in the user editor.

[Galen Charlton (gmc)]

Pushed down to rel_3_6. Thanks, Jason and Terran!