Checking in using key tag barcodes with iPad camera

[pokes2k]

We have been using Microsoft Surfaces for check-in with an attached scanner for reading both QR codes on phones AND plastic key tags that have a barcode on and corresponding 8 digit number on them (pic included). The numbers are entered in the alternate identifiers field of the Rock profile. We are researching a switch to iPad Air (5th Gen Wi-Fi) for check in and wanting to use the front camera as people walk up to scan both the QRs and key tags. QR codes are easily read, but it is not picking up barcodes. We're on v13 and have set up the iPads per the documentation, and according to the documentation, both QRs and the key tag barcodes should work. Screen shot of that section below.

We also have a rocketchat thread going here: https://chat.rockrms.com/channel/check-in?msg=wCfyrYLw3uJnfW3y4 Speculation is that the scanner is working as an input emulator to look up the profile information. Unsure if iPad camera can function in a similar manner.

Key tags we use

Steps to Reproduce

1. Setup iPad for check in per the Rock RMS documentation https://community.rockrms.com/documentation/bookcontent/10/247#ipadapplication
2. Use a barcode (not QR) to check family in.

Expected behavior:

User be able to scan plastic key tag barcode at iPad to lookup family User be able to select their family and check themselves in.

Actual behavior:

Nothing happens. No response from iPad check in client.

Versions

• Rock Version: Rock McKinley 13.3 (1.13.3.1)
• **Rock RMS check in application 1.10
• Client Culture Setting: en-US

[smross]

@pokes2k have you tested both the front and rear cameras on the iPads? Wondering if the rear camera works better...can you give that a shot?

I have also found that when setting up Mobile Check-in the lighting conditions can influence the ability of the front camera to read the barcode on a phone.

[pokes2k]

@smross yes sir, we tried front and back cameras, assuming that the back would have higher resolution. It kind of worked once, but there was a pretty good delay and it still did not pull up the record. Also tried different lighting conditions including changing the brightness and light settings within the checkin app.

[smross]

@pokes2k thanks for that info. You've done a good job of thinking it through.

Is there any chance you could try replicating this using the Demo site to narrow down a problem with Rock in general vs something that's only impacting your installation

[pokes2k]

@smross, sorry it took so long, but we did recreate it in the demo site. Here are the steps we took to recreate:

• We added a barcode number to Alisha Admin's profile.
• Made sure there was an active schedule to test against (we used the 4:30 test since it's basically on 24/7)
• used the weekly service check in config
• added a test ipad device to the check in and made sure it was selected on the ipad
• manually looked up Alisha to make sure everything was working
• tried both front/rear cameras

Unfortunately there is no response from the ipad client.

[smross]

Thanks for verifying @pokes2k I'll ask around in the community to see if there are others using barcode tags who may be able to help test this bug (and see if it can be replicated with their tags)

[smross]

@pokes2k I was wondering, do you know if this happens with tags printed on a different surface? It sounds silly, but I'm wondering if it's possible tags of a different size/on a different substrate would work.

[pokes2k]

@smross we kind of wondered the same and tested some different sized key tags and also tried barcodes on plain paper. Still no luck though.

[nairdo]

Just a quick update: The current iPad check-in app supports only QR and Code 128 type barcodes. We're looking at the possibility of adding support for Code 39 (which is probably the type you have on your printed key tag).

[pokes2k]

@nairdo thanks for the explanation and the link.

[bradencohen]

We added support for Code 39 barcode scanning to Rock Check-In version 1.10.1, which is available on the App Store.

[pokes2k]

@bradencohen Thank you for adding this support. We just had a successful test run with the update.