[ADVAPP-2635]: Rename QnA Advisors to Customer Advisors in code and database tables / columns

[rebecca-canyon]

Ticket(s) or GitHub Issue

• https://canyongbs.atlassian.net/browse/ADVAPP-2635

Technical Description

Create migration to rename tables, foreign columns, and permissions from QnA Advisors to Customer Advisors; update tests and policies in respect; update names of models, filament pages, etc

Any deployment steps required?

No

Cleanup Tasks

cleanup-tasks/2026_05_12_rename_qna_advisors_feature.md

---

Before contributing and submitting this PR, make sure you have Read, agree, and are compliant with the contributing guidelines.

[sonarqubecloud]

Quality Gate passed

Issues
38 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
15.4% Duplication on New Code

See analysis details on SonarQube Cloud

[Orrison]

One thing that can be a little tricky about renaming these is that we need to be sure that we don't have any polymorphic relationships that COULD have referenced these old names previously. Or else it would now fail to resolve those records.

If we want to be careful, you can keep the old key names, referencing the new class names, AFTER the definitions of the new string / class names. Like this:

'customer_advisor' => CustomerAdvisor::class,
'customer_advisor_category' => CustomerAdvisorCategory::class,
'customer_advisor_file' => CustomerAdvisorFile::class,
'customer_advisor_link' => CustomerAdvisorLink::class,
'customer_advisor_question' => CustomerAdvisorQuestion::class,
'qna_advisor' => CustomerAdvisor::class, // LEGACY, kept for backward compatibility
'qna_advisor_category' => CustomerAdvisorCategory::class, // LEGACY, kept for backward compatibility
'qna_advisor_file' => CustomerAdvisorFile::class, // LEGACY, kept for backward compatibility
'qna_advisor_link' => CustomerAdvisorLink::class, // LEGACY, kept for backward compatibility
'qna_advisor_question' => CustomerAdvisorQuestion::class, // LEGACY, kept for backward compatibility

This way, when NEW records are written, it will find the first morphmap record referencing CustomerAdvisor and save with customer_advisor, but then on READ out of the DB it will be able to still map qna_advisor to the new class FQCN

You also can get rid of / NOT do the legacy backwards compatibility items if you feel strongly that there are none, or you have a migration that renames all references to it in an pertinent DB column.

[Orrison]

Rather than actually writing out the same routes, you could define all the grouped routes in like a variable stored function and call it for both. That way this is smaller and easier to maintain. This is very rough, but something like:

$registerAdvisorRoutes = function () {
    Route::prefix('api/{advisor}')
        ->name('api.')
        ->middleware([
            EnsureCustomerAdvisorEmbedIsEnabled::class,
            EnsureCustomerAdvisorRequestComingFromAuthorizedDomain::class,
        ])
        ->group(function () {
            Route::get('/', CustomerAdvisorResourcesController::class)->name('assets');
            Route::post('/entry', ShowAdvisorController::class)->name('entry');
            // ... all the other routes ...
        });

    Route::get('{file?}', CustomerAdvisorResourceController::class)
        ->where('file', '(.*)')
        ->name('asset');
};

// Primary routes
Route::middleware(['api', EncryptCookies::class, CustomerAdvisorWidgetCors::class])
    ->name('widgets.ai.customer-advisors.')
    ->prefix('widgets/ai/customer-advisors')
    ->group($registerAdvisorRoutes);

// Legacy support
Route::middleware(['api', EncryptCookies::class, CustomerAdvisorWidgetCors::class])
    ->name('widgets.ai.qna-advisors.')
    ->prefix('widgets/ai/qna-advisors')
    ->group($registerAdvisorRoutes);