Ideas, enhancements, and future considerations captured during development. Items here are NOT committed to any phase — they’re candidates for prioritization.
admin.bualum.co)Added: December 4, 2025 (Phase 1 planning)
Idea: Create a separate admin portal at admin.bualum.co that consolidates settings from both Lookup Portal and Champion Portal.
Benefits:
Considerations:
Status: Captured for future consideration. Current plan continues with verification queue in Lookup Portal, but this is a strong candidate for Phase 2 or later.
Added: December 4, 2025 (Phase 1 planning)
Idea: Users with permissions to multiple portals should have an easy way to switch between them.
Implementation options:
Status: Should implement in Phase 1.5 when building the Champion Portal header. Simple dropdown with links to Lookup/Champions based on user permissions.
Added: December 4, 2025 (Phase 1.1 implementation)
Idea: Admin interface to edit district display names without direct database access.
Context: Districts are imported from CSV with long MSA names (e.g., “Nashville-Davidson–Murfreesboro–Franklin”) but we want short display names (e.g., “Nashville”). The csv_name column preserves the original for import matching, while name is the editable display name.
Scope:
Target: Phase 1.5 (Admin tools) or Phase 2
Priority: Medium — seed script auto-generates short names, but staff will want to customize ~50 key metros
Status: Should implement in Phase 1.5 when building the Champion Portal header. Simple dropdown with links to Lookup/Champions based on user permissions.
Added: December 4, 2025
Idea: Type-ahead autocomplete for ZIP code entry that shows city/state as user types.
Priority: Low (ZIP entry is one-time during signup)
Added: December 4, 2025
Idea: Client-side image cropping before upload to ensure consistent profile photos.
Libraries to consider: Cropper.js, react-image-crop
Priority: Medium (better UX, but not blocking)
Added: December 4, 2025
Idea: Add service worker and manifest for Progressive Web App capabilities.
Benefits:
Priority: Medium (good for mobile-first, but not Phase 1)
Added: December 11, 2025 (Phase 1.4)
Issue: Champions have no clear way to change their email address. Email serves dual purposes:
Considerations:
Possible flows:
contact_email field, keep email for auth onlyPriority: Medium — users will ask for this eventually
Target: Phase 2
Added: December 11, 2025 (Phase 1.4)
Implemented: December 12, 2025 (Phase 1C)
Issue: The current flow asks for “Legal First Name” and “Preferred First Name” which feels bureaucratic. The legal name isn’t really needed except for identity matching.
Solution Implemented: Option 2 — single “First Name” field for most users, collapsible section for optional legal name and maiden name
Changes:
pref_first_name) and Last Name (last_name)first_name) - if different from preferredcollege_last_name) - maiden nameset_first_name_from_pref automatically sets first_name from pref_first_name if not providedvalidates :first_name to validates :pref_first_nametoggle-legal-name handles expand/collapse with icon rotationResult: Cleaner, less bureaucratic signup flow while still capturing legal name when needed
Added: December 11, 2025 (Phase 1.4)
Issue: The profile show/edit pages feel “clunky and full of words” with similar styling across sections. Hard to scan.
Problems identified:
Research needed:
Possible improvements:
Priority: Medium-High — affects user perception of quality
Target: Phase 2 (UX polish sprint)
Added: December 4, 2025
Idea: Tool for staff to merge duplicate Champion accounts if someone signs up multiple times before verification.
Priority: Low (can handle manually initially)
Added: December 4, 2025
Idea: Build Champion Portal features with RESTful API endpoints to support future native mobile app.
Status: Keep in mind during Phase 1 implementation. Controller actions should be API-friendly.
Added: December 4, 2025
Idea: Champions in small districts (non-highlighted areas) may not have a full “district view” if there are few champions nearby.
Possible solutions:
Priority: Address during Phase 1.4 (Directory) or Phase 2
Items intentionally deferred from specific phases:
| Item | Original Phase | Reason Deferred | Target Phase |
|---|---|---|---|
| Push notifications | Phase 1 | Not needed for MVP | Phase 4+ |
| Map view | Phase 1 | Complexity | Phase 5 |
| Visit mode (secondary cities) | Phase 1 | Complexity | Phase 5 |
| Apple Sign In | Phase 1.3 | Focus on Google first | Future |
| Facebook OAuth | Phase 1.3 | Focus on Google first | Future |
| SSO account linking | Phase 1.3 | Complexity (edge case handling) | Phase 2+ |
| Account settings (connect/disconnect Google) | Phase 1.3 | Profile edit covers basics | Phase 1.4 or 2 |
| Sync imported affinities to profile | Phase 1.4 | Requires BUID verification first | Phase 2+ |
Drop cp_profile_changes table |
Phase 1.1 | Superseded by crm_data_changes |
Post-Affinaquest |
cp_profile_changes TableAdded: December 9, 2025 (Affinaquest unified sync planning)
Context: The cp_profile_changes table was created in Phase 1.1 as a changelog for CRM exports. It has been superseded by the unified crm_data_changes table (see UNIFIED_DATA_SYNC.md).
Current Status:
Cp::ProfileChange model exists but unusedMigration Plan:
crm_data_changes table (Affinaquest Phase 1)crm_data_changes (Phase 1.4 or 2)cp_profile_changes table after Champion Portal is using unified tableCp::ProfileChange modelMigration to Create:
class DropCpProfileChanges < ActiveRecord::Migration[7.1]
def up
drop_table :cp_profile_changes
end
def down
# Recreate table if needed to rollback
create_table :cp_profile_changes do |t|
t.references :cp_champion, foreign_key: { to_table: :cp_champions }, null: false
t.string :field_name, null: false
t.string :table_name, null: false
t.text :old_value
t.text :new_value
t.string :changed_by_type
t.bigint :changed_by_id
t.timestamps
end
add_index :cp_profile_changes, [:cp_champion_id, :created_at]
add_index :cp_profile_changes, :created_at
add_index :cp_profile_changes, :field_name
end
end
Target: After Affinaquest import is live and Champion Portal profile editing uses crm_data_changes
Added: December 8, 2025 (Phase 1.4 planning)
Idea: For verified champions (those with BUID linked), show their CRM-imported affinities from alumni_affinities and allow bulk add to their cp_affinities profile.
Flow:
alumni_affinities for their BUIDcp_affinitiesBenefits:
Priority: Medium — nice engagement boost, but self-selection works fine for MVP
Target: Phase 2 (post-MVP)
Last updated: December 9, 2025