Week 034 — The Anonymous Finder

The found page has an edge case that's actually a common case: the finder isn't logged in.

Week of July 7, 2025

Progress

Found page validation was completed for both the leave-in-place and meet-up return options. Leave-in-place requires location data; meet-up requires contact information. The meet-up path now captures a country code with the phone number. Validation runs conditionally per the selected return method.

The anonymous finder case was addressed structurally: when a finder submits a found report without being logged in, a temporary user record is created to store their contact information. Previously, the finder's phone number or email was being dropped into the notes field — a hack that worked only as long as nobody needed to do anything with it programmatically.

Decision Made

Anonymous finders get lightweight user records in the database. The reasons: it keeps the rest of the logic consistent (the system always works with a user ID when handling found events), and it enables future use cases — tracking how many items are found by unregistered users, offering them registration, understanding finder behavior over time. The data is worth collecting even if it isn't used immediately.

The Hard Part

A bindParam error surfaced during testing — calling bindParam on a null element somewhere in the database layer. The new anonymousFinder parameter being added to ItemService->reportFound() required updates in several places, and one of the usages wasn't properly passing through the new field. Error log hunting.

Next Week

Anonymous finder implementation needs to be completed and tested end to end. Then: production. The application needs to run on a real server.