As an admin I would like to be notified if someone is on the watchlist when checking them in

[binary1230]

(I think this is the way it was supposed to work? and now it's not working?)

tested on staging5 (which is in at-the-con mode, though I don't think it should make a difference). tested with attendees created via the admin interface and not from the prereg form

1. Add an entry marked active to the watchlist matching any one of the following criteria: First name, Last name, Email
2. Visit the attendee search page and locate that attendee
3. Click 'check in'
4. fill out form
5. expect a dialog box that says "HEY you can't check this person in because [reasons]"

ACTUAL: nothing happens right now?

I poked around in the code and don't.... see anything that should actually do this. It might explain why some of our watchlist people were able to check in without being cleared or mentioned in the DI logs.

@kitsuta , @earl7399 , or @ShevaDas do you guys know if I'm right in that this used to work at some point and now doesn't? Or perhaps, did it ever work? Did anyone ever see this in action?

Or, am I completely daft and totally got the workflow wrong and this is not at all how it's supposed to work? :)

[binary1230]

Linking to #2950 and #2942 because those may also be important for correct onsite operation.

hey @EliAndrewC do you know anything about how this is supposed to work?

[binary1230]

from looking around very very briefly, it strikes me we might want to add something here:
https://github.com/magfest/ubersystem/blob/master/uber/site_sections/registration.py#L5

That says vaguely:

if attendee.is_on_watchlist_or_whatever:
   return 'Attendee is on the watchlist for [reasons]'

[binary1230]

@kitsuta commented on the other bug (thanks!)

This functionality works off of is_not_ready_to_checkin here: https://github.com/magfest/ubersystem/blob/master/uber/models/attendee.py#L566

Attendees who match a watchlist entry have their badge status changed to WATCHED_STATUS, so they trip the 'badge status' checkin blocker. This is not very specific, but that's the point -- we really don't need a volunteer reading the screen to the attendee out loud saying "oh it says you're on the watchlist."

However, in most cases, the watchlist is supposed to be built before an attendee registers -- I did code it so that when you add an entry to the watchlist, the system looks for and change attendees. It sounds like what you're describing is that part not working.

[binary1230]

I realized, I need to test this again because I may have been fooled by the issue in #3066 into thinking I had an active watchlist entry when in fact I may have turned the entry off by mistake.

[binary1230]

and, after a little testing, I think #3066 isn't related to this bug (but we should totes fix both)

[kitsuta]

After further review, I actually specifically took out the part of the code that matches new watchlist entries to attendees -- I figured at the time that it was too dangerous, since admins could unknowingly flag attendees as on the watchlist even if they've already checked in.

Ideally I think the system would look for matches, and if it finds them, present them to the admin right then and there and require the admin to either mark the attendee as matching (exclusive), matching (non-exclusive), or non-matching. That way the matching process doesn't happen in the background and it's a lot less likely an admin would leave someone as 'watched' accidentally.