Spam and Phishing Reduction - Volunteers and Committees

Bug 1017 - Volunteer titles can now be configured to stop exposing contact info for the volunteers listed. This info has been scraped in the past and used in phishing scams. Instead, we'll be configuring a single group contact email for most groups and hiding individual contact info. A select few groups such as the board of directors, RBAs, and SR600 owners will still have their contact info listed because members need to be able to reach them directly. We're in the process of contacting each group and making these configuration updates.

Team Events

Team events now support unpaved credit. Details in bug 993.

Kevin has fixed team event results submission to allow removing riders on team events. Previously the page needed to be reloaded to achieve this.

Event Names

The RUSA site now has preliminary functionality for assigning event names. Charlie performed a database and code migration to standardize on using the events table rather than the teamevents table to drive all event name functionality. The bug describes several use cases for event names. Currently only the brevet coordinator can edit these, and they're not consumed anywhere. There's a pending change that will allow RBAs to specify these when calendaring events. Event names will be required for LRM events since RUSA needs to know what name to use when submitting the annual schedule to LRM. These will be optional for other events, and will serve as placeholder text when viewing calendared rides until a route has been assigned. They can be useful when an RBA hasn't gotten their route approved yet or for when they haven't decided which route to use. The next steps are to flesh out some functionality to facilitate administrative tasks for the brevet coordinator in order to manage and maintain this data. Additional details in bug 822.

American Explorer Award Disputes

Gary DelNero is actively exploring outstanding disputes, and he has reached out to several people to collect more information. Gary, JLE, Lois, and Charlie are working together to define processes, strategies, and tooling to resolve disputes. The Colorado Last Chance 1200 (route 967) is serving as an initial case study.

Charlie built two new shiny tools for American Explorer analysis. One tool analyzes the impact of a permanent or brevet route on AmEx credit across all of RUSA. The other tool finds mismatches between credit that members have claimed vs calculated locations based on their results for a given period. American Explorer business logic has been consolidated to a central shared library to facilitate this new functionality. American Explorer volunteers will now also receive email notifications summarizing disputes as they are filed so that they can be addressed in a more timely manner.

Next steps for server upgrade

Paul has another server up and running on Test. Moving everything under FcgiWrap and moving off of uwsgi. Needs testing, particularly the Perl scripts. The Perl version will be updated as part of this.

Permanents

Permanents Program Payment with Membership

Bug 1026 - People continue to request consolidating perms payment with RUSA membership payment. Paul thinks it's feasible for the CGI system to send an event to the Drupal system to create a new perm program registration. If so we can also likely simplify the current workflow.

Bug 1043 - Trigger perm program registration processing from manual order fulfillment.

Permanents - Misc

Bug 1021 - Paul has a pending fix for the HTTP 500 error when someone tries to log in with an unrecognized username/email. This should cut down the confusion when people are unable to log in to the website.

Bug 1038 - Perl perms details pages now link to ride results for the selected permanent route.

Bug 1020 - Removed the defunct route owner sort option from the permanents search feature.

Award management

Bug 1024 - Added several new columns to the awards report to facilitate exporting awards data to ACP/LRM.

Bug 1029 - Fixed a display bug in award app management.

Bug 1030 - Code cleanup to standardize on a common awardtype mapping.

Foreign Events in RUSA Database

RUSA now has infrastructure and management tools to support foreign events and results as first-class RUSA data. Initially the scope is limited to LRM data, plus some tangential features for PBP. ACP/UAF/etc data can be considered as the dust settles. Most of the work is documented in bug 1031 but a lot is also documented in several offshoot tracking bugs. Current progress includes:

• 3 new database tables to store this data. foreign_events stores event data and indexes a list of results for the event. foreign_results stores results data (RUSA#, cert#, time). foreign_mresults indexes foreign results for each RUSA member.
• Handling for foreign events/results across the RUSA website. Several places like the RUSA store, award application validation, back office awards management, and member results pages have business logic for handling award application records and need to be able to interpret foreign event/results records.
• Back office management. Dave and Charlie will manage this data initially. This should be expanded to more people over time to handle data corrections, backfilling data for new RUSA members, and adding data for new foreign events/results. The back office has a new section called FOREIGN EVENTS with items:
  • [foreign events] - Manage foreign events and results. Currently new events must be backfilled via a script, but after that they can be edited. Results can be hand-entered or uploaded via CSV. The dashboard has 3 separate views:
    (1) show all - All foreign events, with an edit link for each.
    (2) show only events with RUSA finishers - Same as (1), but filtered to just the ones that have results assigned.
    (3) flatten all results - The table is expanded to provide a report of all foreign LRM results. There's an edit link for each result.
  • [foreign award qualifiers] - A dashboard for managing hand-entered foreign events data in award applications. If the member has a corresponding PBP or foreign LRM entry in the RUSA DB, the dashboard makes it easy to replace the hand-entered data with the DB result. PBP results are suggested based on date+cert+distance+details. LRM results are suggested based on cert. The tool has 3 separate views: (1) show all, (2) show only PBP, and (3) show only LRM.
  • It's now possible to directly modify foreign entries in award applications. Previously the two ways to do this were: (1) a DB admin could hand-modify the encoded event data, or (2) the application could be deleted and resubmitted. Care should be taken when editing this data, because it's not subjected to the same validation business logic as the initial award application submission. It still does some high-level validation however.

Once we have foreign event/results data in our system, there are several potential uses for it:

1. Streamlined award applications. Once foreign results are in the system, they can be available for selection in award applications. For some awards like K-Hound, the usage of these foreign results can be automated. Foreign events that are already in the RUSA system will not require manual verification by the award volunteer, and these applications can be approved immediately by the system.
2. More accurate and consistent data for award applications in the RUSA DB. The hand-entered foreign results in award applications are full of junk. The data is often inaccurate (wrong date; wrong cert; wrong distance; ambiguous or incorrect organizer / event name details). This significantly increases the overhead for approving and exporting this data.
3. More data at our disposal for processing award applications. E.g. we would be able to utilize event country data in ISR and Lepertel applications.
4. RUSA can provide a starting point if LRM or ACP ever decide to associate unique rider IDs to their results. E.g. LRM tries to identify individuals who have completed 10+ LRM or LRM+PBP events, however their matching scheme is based on heuristics and has false negatives/positives. RUSA will have some similar issues with its initial backfill, however a lot of the existing data has already been vetted by RBAs/members, and any future data can be vetted.
5. Foreign results could be displayed in member results pages (grayed out and exempt from RUSA credit), similar to what we do today for PBP. This could even include pre-RUSA IR events, such as Boston-Montreal-Boston.
6. RUSA could display result history for riders from before they joined RUSA (grayed out and exempt from RUSA credit), the same as we'd do for foreign events. This would be handled in the same vein as pre-RUSA BMB results (for which participants were obviously not RUSA members).

LRM/PBP Data Management

The web team has done a significant amount of data cleanup and backfilling:

• LRM cert formats in the RUSA DB have been aligned with LRM data. A lot of certs had a "US-" or "US" prefix. In some cases, we had incorrect cert #'s and several of those were fixed. Sometimes LRM issues an overlapping cert# and applies a suffix, e.b. "8663A". Those suffixes were added for a couple cases. Upwards of 3000 RUSA certs were cleaned up. Details in bug 400.
• RUSA's PBP certs were corrected for 8 PBP editions: 1975, 1979, 1983, 1987, 1991, 1995, 1999, and 2003. These were using an internal RUSA numbering scheme (e.g. PBP-1999-1, …) that did not align with ACP-recognized cert #'s. About 1500 certs were fixed. Details in bug 1040.
• All PBP and LRM data has been cleaned up in award applications. Somewhere around 400 manual foreign entries were cleaned up.
• Found some RUSA/LRM results mismatches for the 2011 Colorado High Country. The RUSA data was verified and these were communicated to the brevet coordinator to reconcile with LRM. Details in bug 1041.
• Discovered 19 finish time discrepancies between RUSA vs LRM data. These are all off by a single digit, and are suspected to be data entry errors on the part of LRM before more modern data entry practices were adopted. Details in bug 1037.
• (WIP) We're in the process of backfilling foreign LRM results that RUSA doesn't currently have on record. LRM has roughly 21,000 results to date, and an initial analysis indicates about 1/4 (!) of those are from riders who have a RUSA #. The current process involves extrapolating from our current LRM data and using miscellaneous heuristics to make best-effort RUSA # assignments to eligible LRM results. Verification of this data can then be crowdsourced to RUSA membership and backfilled into our database for use by the system. We'll want volunteers and processes to help keep this data fresh going forward. Details in bug 1042.

Misc content updates

Bug 1036 - Updated broken contact links.

Bug 1011 - Cleaned up red edit links on Audax Rules.

Bug 1035 - Award proposals are now directed to the Awards Review Committee.

Other recent changes

Bug 1001 - Award type definitions can now configure separate volunteers for handling the trinket vs the award application. When members submit award applications requiring approval, they are now instructed to contact the application volunteer when relevant. All the applicable award types are now configured with an application volunteer. I've also added email notifications whenever an award application is submitted that requires approval. Previously these would have just spammed the wrong RUSA volunteers.

Bug 1015 - The brevet routes search function now has a few sorting options.

Bug 832 - Handling for 7+ digit ACP cert numbers.

Bug 1034 - Fixed a big where 8k600's didn't reappear after filtering and clearing filters on individual results pages.

Bug 1039 - Country selection is no longer broken when adding/modifying results.