Some patrons register but we can't find them


#1

This is a weird one…

We had reports this was happening, but finally witnessed it today while helping someone register.

We had the registration page up on a laptop (https://gra.soldotna.org/Default.aspx?PID=3) and when ‘Register Now’ was clicked, the first registration page was blank instead of the Age field, and then subsequent pages asked for other fields that we don’t have set up to ask for. They finished the registration process.

  • We now can’t find the patron using the Control Room patron search.
  • When we tried to re-register them, the username was already in use.
  • After having them log into the front end and then link kid accounts to their own, I can find the patron in the Control Room ONLY after searching for their kid and then switching to the master account. Their name/username/etc does not pull in a search.
  • These “lost” patrons don’t show in reports either.
  • These “lost” patron accounts look/act normal on the front end. They can log time, earn badges/prizes, etc.

:sob:

So, three issues:

  • Where are these people being stored? We have multiple organizations (The default master, with two organizations)… I found 5 patron accounts created in the master, which accounts for some of the problem, but there are others who I know are registered and using, who I can find through their linked kid accounts, but they aren’t showing in the master or either of the two orgs by any other method). And there could be a number of non-linked accounts that are simply hidden.

  • How do I grab these patrons, once “found”, and get them to behave normally? THEY can log time and play along, but we as staff can’t find them normally or include them in reports.

  • How do I stop this seemingly-random blips from happening? (This is pretty much an impossible question at this point, but I had to throw it in there) Is the wireless connection cutting out maybe an issue? This is the only consistent environment I’ve been able to unearth - all cases of strangeness reported were by people using wireless/cellular.

In summary, :flushed:


Fix for multi-tenancy environments with 3.0.x and 3.1
#2

If it wasn’t the middle of the day in the middle of the week I’d mess with settings, but I can’t do that right now.

Thinking just about the patrons who are registering for the unused master: Would setting the Master Org’s default GRA “program” to Hidden help? What if I uncheck Active? Would those changes affect my sub-orgs and their programs?


#3

Holly:

First off, I’m so sorry this is happening. :frowning:

My hypothesis here (which you seem to at leas suspect) is that some how it got confused about which tenant/organization they were trying to sign up for. It’s possible this happened because nobody touched the browser for the session timeout period (which I thought defaulted to 60 minutes but it may be set to 20 minutes) and then when they went to submit the form it didn’t know what tenant they were trying to use anymore so it “guessed” the master tenant or another tenant. Of course, I’m assuming that it was sitting around long enough for the session to time out. Hitting “reload” or reloading your URL right before having someone register might mitigate that if it’s what’s happening.

I suspect what has happened is that those patrons are registered in a separate tenant/organization and somehow they were able to associate with family members who are in your tenant/organization. This shouldn’t have been allowed to happen, if that’s the case. If that’s what happened it would be a code problem and it would be on me.

When they log in, they are seeing your program? Or possibly another tenant/organization?

To answer your issues:

  1. There’s a single patron database table that all patrons are in (this is why people across tenants cannot use the same username currently). If they exist then they’re in that table. All I can figure is that they’re set with the wrong tenant.

  2. I’d need to know a little more to fully understand how to bring these people back into the fold (so to speak). My guess here is that the software doesn’t have the capability to do that as-is but we know these people exist in the database so one way or another we can get them in the right place (either a database query or adding a feature to the Control Room).

  3. If my hypothesis above is correct the fix for the symptom is to have them click that link just prior to registering to ensure their session hasn’t expired. I had thought that this problem was fixed in the work I did earlier on multi-tenancy (i.e. if the session is timed out it should redirect patrons to the Select.aspx document of the master tenant).

I could tell a bit more if I had access to your database or a backup of it. I’m not sure the comfort level providing me with either of those but it would help diagnose what’s going on. Also, as usual, any log files on the disk could help.


#4

Thanks, @harald! I’m just about to step out for some (much needed) lunch, but you’ve given me some great things to work with. I’ll keep poking and report back!


#5

Also, in response to this: honestly, I don’t know. We don’t really use hidden or inactive programs. This might be something to try though I’m not sure if you want to try it in your production instance with your program live.


#6

[quote=“harald, post:3, topic:173”]
… happened because nobody touched the browser for the session timeout period (which I thought defaulted to 60 minutes but it may be set to 20 minutes)

Where can I set the session activity / inactivity timeout timer setting?


#7

I did find web.config in the root folder of the SRP webserver.
I changed

  • 60 to 90 in timeout under <system.web>
  • 2880 to 3000 in timeout under
  • 600 to 900 in executionTimeout under

The complaint was that sessions (didn’t specify controlRoom or Patron) were too short when library staff is testing…and working desk at the same time :wink: