Open cjtheham opened 2 years ago
Nice catch!
Right now I'm just using the callsigns as a key but I'm guessing I will need to evolve past that to accomplish this and #11. At least the old callsign looks incomplete.
Rather than an HTTP redirect, I would recommend having info in the JSON response with the new callsign, the date the new callsign took effect, and some kind of status field that indicates the old callsign is no longer active.
I noticed this issue while reviewing the output of a script that checks my logs for potential transcription errors, since I log on paper and then convert to digital. I wrote down a call which happens to be someone's old call, and my script flagged them as being a Technician class, even though they updated to General after acquiring a vanity callsign. I would like my script to flag this callsign (e.g. by examining the status) rather than quietly following an HTTP redirect to the new callsign.
I process the ULS data files sequentially so the old records stick around almost on accident. I wonder if tracking call/frn would let me detect the updates without having to process the application data more. I think I am already processing the application data for one of the data points.
life is busy right now, if you want to PR something I would be happy to merge it.
Currently former calls still show data like the call is active. Instead, they should either redirect or show the data for the former owner's new vanity call, unless another person has taken the former call.
i.e. KO4JZT currently shows as if KO4JZT is still active. Should redirect or show the same data as WW0CJ.