chaim
d266380e6d
Two UI-breaking issues discovered after 2.10.0 hot-patch: * Hitting /#CaseMemory in the navbar returned a 404 because CaseMemory was missing a Controller class. The entity used to be accessed only through Case relation panels and SmartAssistant action endpoints, so the bare REST surface was never wired. Same one-liner fix pattern as the AssistantRule controller in 2.9.2. * Layouts were placed under Resources/metadata/layouts/... but EspoCRM expects them at Resources/layouts/... (without the metadata/ prefix). Result: every new entity rendered only one column / one row in list views because EspoCRM fell back to a generic default layout. Moved AssistantPrompt, AssistantRule, AssistantSkill, CaseMemory, UserProfile layouts to the canonical path. Verified all five list endpoints now serve the configured columns. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
18 lines
604 B
PHP
18 lines
604 B
PHP
<?php
|
|
|
|
namespace Espo\Modules\SmartAssistant\Controllers;
|
|
|
|
/**
|
|
* Standard CRUD over /api/v1/CaseMemory.
|
|
*
|
|
* Until SmartAssistant 2.10.0 the CaseMemory entity was created via
|
|
* CaseMemoryService::createMemory and listed via Case relation panels —
|
|
* never via the bare REST endpoint. Flipping `tab: true` exposes the
|
|
* navbar list view, which uses GET /api/v1/CaseMemory and needs this
|
|
* Controller class to exist (otherwise EspoCRM returns 404 "Controller
|
|
* does not exist"). Same pattern as the AssistantRule fix shipped in 2.9.2.
|
|
*/
|
|
class CaseMemory extends \Espo\Core\Controllers\Record
|
|
{
|
|
}
|