c1476d5c52
Stop self-naming in the document generators and defer to NetworkStorageIntegration's single namer (rule N1): - FreeDocumentGenerator and GenericTemplateGenerator no longer bake in a date prefix, em-dash or contact name. They set the clean subject, upload explicitly to the case folder (the AfterSave hook fires before the Case link exists), then realign the Document + Attachment names to the canonical stored name returned by the upload. - CaseFolderManager sanitizes every model-chosen name server-side: writeFile splits dir/basename and de-duplicates via buildStoredFileName; createFolder, renameItem and moveItem sanitize their final segment. The LLM can no longer pick a raw filename. Refs Task Master #7 Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
106 lines
53 KiB
JSON
106 lines
53 KiB
JSON
{
|
|
"master": {
|
|
"tasks": [
|
|
{
|
|
"id": "1",
|
|
"title": "fix: broaden task detection to include Contact-linked tasks",
|
|
"description": "AlertCalculator, CaseContextBuilder, and OfficeContextBuilder only queried tasks with parentType='Case', missing tasks linked to case contacts (parentType='Contact'). This caused false 'no preparation task' alerts in Shira's daily standup.",
|
|
"status": "done",
|
|
"priority": "high",
|
|
"dependencies": [],
|
|
"details": "Root cause confirmed via production API: preparation tasks had parentType='Contact' because Shira created them linked to the contact entity. Fix broadens all task queries to include both Case and Contact parent types, plus NhActivity-linked tasks.",
|
|
"testStrategy": "Deploy to staging, trigger standup for a case with Contact-linked tasks, verify no false alert.",
|
|
"subtasks": [],
|
|
"updatedAt": "2026-04-14T06:08:19.494Z"
|
|
},
|
|
{
|
|
"id": "2",
|
|
"title": "Network-storage diagnostics + folder discovery",
|
|
"description": "Expose diagnostics when a case folder can't be listed and add endpoints (findCaseFolder, setCaseFolderPath) so Shira can locate and persist the correct network-storage path.",
|
|
"details": "",
|
|
"testStrategy": "",
|
|
"status": "done",
|
|
"dependencies": [],
|
|
"priority": "medium",
|
|
"subtasks": [],
|
|
"updatedAt": "2026-05-06T17:56:54.413Z"
|
|
},
|
|
{
|
|
"id": "3",
|
|
"title": "fix: extend client AJAX timeout 180s->600s and add slow-hint after 60s to prevent communication-error false-positive when ai-gateway takes >3min on first iteration (prod incident 2026-05-13)",
|
|
"description": "Production incident where multi-tool AI flows (delegation, memory writes, web search) occasionally exceeded the default 180s client timeout, causing \"Communication error\" to display even though the backend continued processing and eventually succeeded. Users saw false errors after ~3min wait.",
|
|
"details": "## Root Cause\nThe client-side `Espo.Ajax.postRequest('SmartAssistant/action/chat', ...)` call in `floating-chat.js:486` already has `{timeout: 600000}` (10 minutes), which was implemented in a previous fix. However, the production incident revealed that:\n\n1. Users still see \"שגיאה בתקשורת\" (Communication error) after ~3 minutes on complex multi-tool flows\n2. The \"חושבת...\" (Thinking...) spinner runs unchanged for the entire duration, giving no feedback that the system is still working\n3. The i18n files already contain a `SlowHint` label designed for this exact scenario but it was never wired up\n\n## Analysis of Current Code\n**File:** `files/client/custom/modules/smart-assistant/src/views/floating-chat.js`\n\n**Lines 460-475:** The `sendMessage()` method creates a loading message with \"חושבת...\" text and immediately sets up a 60-second timer (`slowHintTimer`) that changes the text to the `SlowHint` translation:\n```javascript\nvar slowHintText = this.translate('SlowHint', 'labels', 'SmartAssistant') ||\n 'חושבת... זה לוקח קצת יותר זמן כי אני מעבדת כמה מקורות במקביל';\nvar slowHintTimer = setTimeout(function () {\n $loading.find('.sa-thinking-text').text(slowHintText);\n}, 60000);\n```\n\n**Line 486:** The AJAX timeout is already set to 600000ms (10 minutes)\n\n**Lines 487, 505:** Both success and error handlers call `clearTimeout(slowHintTimer)` to clean up\n\n## Issue Discovered\nThe code is **already correct** and implements exactly what the task description requests:\n- ✅ 600s (10 minute) timeout is set\n- ✅ Slow hint timer switches text after 60s\n- ✅ Timer is properly cleaned up on completion/error\n- ✅ i18n labels exist in both `en_US` and `fa_IR`\n\n## Verification Needed\nSince the code already implements the fix, the production incident suggests one of:\n\n1. **Deployed version mismatch** - The production extension may not have the latest code deployed\n2. **Browser caching** - Clients may be running cached old JavaScript that lacks the timeout/hint\n3. **Different error source** - The \"Communication error\" might be coming from a network-level timeout (reverse proxy, Coolify, Traefik) rather than client JavaScript\n4. **EspoCRM core override** - EspoCRM's base `Espo.Ajax` might have a global timeout that overrides the per-request timeout\n\n## Implementation Steps\n\n1. **Verify current deployment** - Check that the production EspoCRM instance has the latest `SmartAssistant` extension installed with this exact code\n2. **Check manifest version** - Confirm `manifest.json` version number matches what's deployed\n3. **Browser cache bust** - Force client cache clear by:\n - Incrementing `manifest.json` version\n - EspoCRM admin may need to rebuild/clear cache\n4. **Server-side timeout audit** - Check these layers:\n - Traefik ingress timeout on the EspoCRM service\n - nginx/Apache timeout in EspoCRM container\n - PHP `max_execution_time` in EspoCRM (should be ≥600s for the SmartAssistant endpoint)\n - shira-hermes backend timeout (should be ≥600s)\n - ai-gateway proxy timeout to Claude API\n5. **Add defensive logging** - If the code is deployed but not working:\n - Add `console.log` when slow hint fires\n - Add `console.log` showing actual timeout value used\n - Check browser DevTools Network tab for actual request timeout\n6. **Verify i18n loading** - Ensure `SlowHint` label is actually loaded (check `this.translate('SlowHint', ...)` returns expected text)\n\n## Code Changes (if verification shows deployment gap)\n\n**None required** - the code already implements the fix correctly.\n\nIf verification reveals the code is NOT deployed, simply:\n1. Rebuild the extension package\n2. Upload to EspoCRM via Administration → Extensions\n3. Clear EspoCRM cache\n\n## Alternative: Server-Side Timeout Fix\n\nIf the issue is server-side, update these configs:\n\n**shira-hermes (FastAPI):**\n```python\n# In main app config\nuvicorn.run(app, timeout_keep_alive=600)\n```\n\n**EspoCRM PHP (SmartAssistant controller):**\n```php\nset_time_limit(600); // At start of chat action\n```\n\n**Coolify/Traefik:**\nCheck proxy timeout settings for the EspoCRM service.",
|
|
"testStrategy": "## Test Strategy\n\n### Phase 1: Verify Current Deployment\n1. **Check installed extension version**\n - Log into production EspoCRM (https://crm.prod.marcus-law.co.il)\n - Go to Administration → Extensions\n - Find SmartAssistant extension, note version number\n - Compare with `manifest.json` in this repo\n\n2. **Check deployed JavaScript**\n - In browser, open DevTools → Sources\n - Find `client/custom/modules/smart-assistant/src/views/floating-chat.js`\n - Search for \"timeout: 600000\" - should exist on line ~486\n - Search for \"slowHintTimer\" - should exist on line ~473\n - Search for \"SlowHint\" - should exist on line ~471\n\n### Phase 2: Browser Cache Verification\n1. **Hard refresh test**\n - Open production EspoCRM in incognito/private window\n - Navigate to any Case detail view\n - Open Shira chat panel\n - Check browser console for any JavaScript errors\n - Send a message that triggers slow processing (e.g., \"search the web for...\")\n - Verify \"חושבת...\" changes to \"חושבת... זה לוקח קצת יותר זמן...\" after 60 seconds\n\n2. **Cache headers check**\n - DevTools → Network → filter for `floating-chat.js`\n - Check `Cache-Control` and `ETag` headers\n - Note timestamp of file\n\n### Phase 3: Network Timeout Audit\n1. **Client-side timing**\n - Open DevTools → Network\n - Send message that takes >3 minutes\n - Watch the `SmartAssistant/action/chat` request\n - Note exact time when it fails (should be 600s, not 180s)\n - Check response status (timeout = no status, server error = 500/502/504)\n\n2. **Server logs correlation**\n - While test message is processing, tail these logs:\n ```bash\n # shira-hermes logs\n docker logs -f <shira-container> --since 1m\n \n # EspoCRM logs\n tail -f data/logs/espo-$(date +%Y-%m-%d).log\n \n # ai-gateway logs \n docker logs -f <ai-gateway-container> --since 1m\n ```\n - If logs show success but client shows error → client timeout\n - If logs show timeout/error → server timeout\n\n### Phase 4: Reproduction Test\n1. **Create slow scenario** (production or staging)\n - Open a complex case with many documents\n - Ask Shira: \"תעשי לי סיכום מלא של התיק כולל חיפוש באינטרנט על התקדים הרלוונטיים\"\n - This should trigger: delegation + memory search + web search + document analysis\n - Expected: Takes 2-4 minutes\n \n2. **Observe behavior**\n - ✅ At 60s: Text changes to \"חושבת... זה לוקח קצת יותר זמן...\"\n - ✅ At 180s: Still shows spinner (no error)\n - ✅ At 300s: Still shows spinner (no error)\n - ✅ At completion: Shows response, spinner removed\n - ❌ If error before 600s: Fix not deployed or server timeout\n\n### Phase 5: Post-Fix Validation\nAfter confirming fix is deployed:\n\n1. **Quick response test** (<10s)\n - \"מה שם התובע בתיק?\"\n - Should show \"חושבת...\" only, no slow hint\n\n2. **Medium response test** (30-90s)\n - \"הכן טיוטת תזכיר\"\n - Should show \"חושבת...\" then slow hint after 60s\n\n3. **Long response test** (>180s)\n - Complex multi-tool query\n - Should show slow hint, complete successfully\n\n4. **Error handling test**\n - Disconnect network after sending message\n - Should show \"שגיאה בתקשורת\" (real network error)\n - Reconnect and retry - should work\n\n### Success Criteria\n- ✅ Slow hint appears after 60 seconds on all requests\n- ✅ No \"Communication error\" before 600 seconds on working requests\n- ✅ Requests that take 3-5 minutes complete successfully\n- ✅ Timer cleanup confirmed (no memory leaks on rapid message sending)\n- ✅ i18n works in both Hebrew and English interface",
|
|
"status": "done",
|
|
"dependencies": [],
|
|
"priority": "medium",
|
|
"subtasks": [],
|
|
"updatedAt": "2026-05-13T12:48:21.525Z"
|
|
},
|
|
{
|
|
"id": "4",
|
|
"title": "Implement FreeDocumentGenerator, CaseFolderManager, AlertCalculator pending-status filter, CaseContextBuilder template query fix, and Document.markedForDeletion metadata",
|
|
"description": "Add comprehensive document management system with 6 new controller actions (createDocument, writeToFolder, createFolder, renameItem, moveItem, markForDeletion), integrate FreeDocumentGenerator for markdown-to-DOCX conversion, CaseFolderManager for secure network storage operations, fix AlertCalculator to filter pending-status cases, fix CaseContextBuilder template query bug, and add Document entity metadata for soft-delete tracking.",
|
|
"details": "## Implementation Overview\n\nThis task bundles several interconnected features that work together to provide Shira (the AI assistant) with comprehensive document management capabilities. The implementation consists of:\n\n1. **FreeDocumentGenerator** (`Services/FreeDocumentGenerator.php`, lines 1-276)\n - Creates DOCX documents from markdown text with Hebrew RTL support\n - Uses PhpOffice/PhpWord library for document generation\n - Handles markdown parsing: headers (# ## ###), bold (**text**), italic (*text*), bullet lists (- item)\n - Formats Hebrew dates in the header (e.g., \"14 במאי 2026\")\n - Automatically uploads to network storage via NetworkDocumentService\n - Returns: `{success, documentId, documentName, fileName, networkPath, message}`\n - Font: David, size 12, with proper RTL/bidi settings\n - File naming: `{YYYY-MM-DD} - {sanitized_title}.docx`\n\n2. **CaseFolderManager** (`Services/CaseFolderManager.php`, lines 1-335)\n - Security-focused wrapper around NetworkDocumentService\n - All operations constrained to case folder via path normalization\n - Rejects traversal attempts (../, null bytes, control characters)\n - Methods:\n - `writeFile(caseId, relPath, content)` - Write binary content to network storage\n - `createFolder(caseId, relPath)` - Create folders recursively\n - `renameItem(caseId, currentRelPath, newName)` - Rename files/folders (no slashes allowed)\n - `moveItem(caseId, sourceRelPath, targetRelPath)` - Move items between folders\n - `markForDeletion(caseId, fileRelPath)` - Soft-delete: move to \"מסמכים למחיקה\" folder with \"למחיקה - \" prefix\n - Path handling: accepts both case-relative paths and full storage-relative paths\n - Soft-delete updates linked Document entity with `markedForDeletionAt` and `markedForDeletionById`\n\n3. **AlertCalculator pending-status filter** (`Services/AlertCalculator.php`, lines 88-96)\n - Bug fix: suppress inactivity alerts for cases in legitimately inactive states\n - Skip `PendingDecision` status entirely (nothing lawyer can do until court rules)\n - Skip `PendingHearing` if future hearing is scheduled (`cNextHearing >= today`)\n - Prevents false-positive \"inactive case\" alerts during normal court waiting periods\n - Also broadened task queries to include `parentType=['Case', 'Contact']` (Task #1 fix)\n\n4. **CaseContextBuilder template query fix** (`Services/CaseContextBuilder.php`, lines 84-98)\n - Bug fix: broadened task queries to include Contact-linked tasks\n - Query now uses `OR` conditions: `['parentType' => 'Case', 'parentId' => $caseId]` OR `['parentType' => 'Contact', 'parentId' => $contactIds]`\n - Prevents false \"no preparation task\" alerts in Shira's daily standup\n - Production incident: preparation tasks had `parentType='Contact'` because Shira created them linked to contact entity\n\n5. **Document entity metadata** (`Resources/metadata/entityDefs/Document.json`)\n - New fields:\n - `markedForDeletionAt` (datetime, readOnly, tooltip)\n - `markedForDeletionBy` (link to User, readOnly)\n - New link: `markedForDeletionBy` (belongsTo User)\n - Enables audit trail for soft-deleted documents\n\n6. **Controller actions** (`Controllers/SmartAssistant.php`, lines 390-501)\n - `postActionCreateDocument` (lines 390-415): Generate free-form DOCX from markdown\n - Params: `caseId`, `title`, `body`, `documentType='letter'`, `recipient=null`\n - Delegates to FreeDocumentGenerator\n - `postActionWriteToFolder` (lines 417-437): Write binary file to case folder\n - Params: `caseId`, `relPath`, `contentBase64`\n - Decodes base64 content, delegates to CaseFolderManager.writeFile\n - `postActionCreateFolder` (lines 439-452): Create folder in case storage\n - Params: `caseId`, `relPath`\n - `postActionRenameItem` (lines 454-469): Rename file/folder\n - Params: `caseId`, `currentRelPath`, `newName`\n - `postActionMoveItem` (lines 471-486): Move file/folder\n - Params: `caseId`, `sourceRelPath`, `targetRelPath`\n - `postActionMarkForDeletion` (lines 488-501): Soft-delete file\n - Params: `caseId`, `fileRelPath`\n\n## Route Registration\n\nThe controller actions are **NOT** registered in `routes.json` yet (current file only has 11 routes, ends at line 98 with `executeTool`). The routes need to be added manually or through EspoCRM's automatic route discovery (controller methods prefixed with `postAction*` are auto-discovered).\n\n**Note:** EspoCRM automatically discovers controller actions following the naming convention `{verb}Action{ActionName}`, so these 6 actions should be accessible without explicit route registration at:\n- `POST /api/v1/SmartAssistant/action/createDocument`\n- `POST /api/v1/SmartAssistant/action/writeToFolder`\n- `POST /api/v1/SmartAssistant/action/createFolder`\n- `POST /api/v1/SmartAssistant/action/renameItem`\n- `POST /api/v1/SmartAssistant/action/moveItem`\n- `POST /api/v1/SmartAssistant/action/markForDeletion`\n\n## Shira-Hermes Integration\n\nThis extension pairs with shira-hermes (the AI backend, gitea.dev.marcus-law.co.il/espocrm-extensions/shira-hermes) which provides the user-facing tools that call these endpoints:\n- `create_document` tool → `createDocument` action\n- `write_to_case_folder` tool → `writeToFolder` action\n- `create_case_folder` tool → `createFolder` action\n- `rename_case_item` tool → `renameItem` action\n- `move_case_item` tool → `moveItem` action\n- `mark_for_deletion` tool → `markForDeletion` action\n\n## Files Modified\n\n1. `files/custom/Espo/Modules/SmartAssistant/Services/FreeDocumentGenerator.php` (new file, 276 lines)\n2. `files/custom/Espo/Modules/SmartAssistant/Services/CaseFolderManager.php` (new file, 335 lines)\n3. `files/custom/Espo/Modules/SmartAssistant/Services/AlertCalculator.php` (modified, +8 lines)\n4. `files/custom/Espo/Modules/SmartAssistant/Services/CaseContextBuilder.php` (modified, +14 lines)\n5. `files/custom/Espo/Modules/SmartAssistant/Controllers/SmartAssistant.php` (modified, +115 lines, 6 new actions)\n6. `files/custom/Espo/Modules/SmartAssistant/Resources/metadata/entityDefs/Document.json` (new file, 20 lines)\n\n## Dependencies\n\n- PhpOffice/PhpWord (already in composer.json)\n- NetworkStorageIntegration module (already exists)\n- NetworkDocumentService (used by FreeDocumentGenerator and CaseFolderManager)\n\n## Security Considerations\n\n1. **Path traversal prevention**: CaseFolderManager.normalize() rejects `..`, control characters, null bytes\n2. **Case folder isolation**: All operations verified to be within case root via assertWithinCaseRoot()\n3. **ACL checks**: All controller actions call checkAccess() to verify Case.read permission\n4. **Soft-delete only**: markForDeletion never physically deletes, preserves audit trail\n5. **Base64 validation**: writeToFolder validates base64 encoding before writing\n\n## Error Handling\n\n- Missing parameters → BadRequest exception with clear message\n- Path traversal attempts → Forbidden exception\n- File/folder not found → NotFound exception\n- Network storage failures → Error exception with context\n- Best-effort Document entity updates (logs warning on failure, doesn't block operation)",
|
|
"testStrategy": "## Testing Strategy\n\n### Phase 1: Unit Testing (Developer Console / API Client)\n\n#### 1.1 Test FreeDocumentGenerator via createDocument action\n```javascript\n// In EspoCRM developer console or via curl\nPOST /api/v1/SmartAssistant/action/createDocument\n{\n \"caseId\": \"{existing_case_id}\",\n \"title\": \"מכתב בדיקה\",\n \"body\": \"# כותרת ראשית\\n\\n**טקסט מודגש** וטקסט רגיל.\\n\\n- פריט ראשון\\n- פריט שני\\n\\n## כותרת משנית\\n\\nסיכום התיק.\",\n \"documentType\": \"letter\",\n \"recipient\": \"כבוד השופט\"\n}\n\n// Expected response:\n{\n \"success\": true,\n \"documentId\": \"...\",\n \"documentName\": \"מכתב בדיקה\",\n \"fileName\": \"2026-05-14 - מכתב בדיקה.docx\",\n \"networkPath\": \"תיקים/...\",\n \"message\": \"✅ המסמך \\\"מכתב בדיקה\\\" נוצר בהצלחה וצורף לתיק ולתיקיית הרשת.\"\n}\n\n// Verify:\n// 1. Document entity exists in EspoCRM with correct name and attachment\n// 2. DOCX file is in data/upload/{attachmentId}\n// 3. File is in network storage at networkPath\n// 4. Open DOCX and verify:\n// - Hebrew RTL rendering\n// - Date in Hebrew format at top\n// - Recipient line if provided\n// - Title is bold, centered\n// - Markdown formatting (bold, bullets, headers) is correct\n```\n\n#### 1.2 Test CaseFolderManager via writeToFolder action\n```javascript\nPOST /api/v1/SmartAssistant/action/writeToFolder\n{\n \"caseId\": \"{existing_case_id}\",\n \"relPath\": \"בדיקה/test.txt\",\n \"contentBase64\": \"VGVzdCBmaWxl\" // base64 for \"Test file\"\n}\n\n// Expected response:\n{\n \"success\": true,\n \"path\": \"{case_folder}/בדיקה/test.txt\",\n \"size\": 9\n}\n\n// Verify: File exists in network storage at returned path\n```\n\n#### 1.3 Test createFolder action\n```javascript\nPOST /api/v1/SmartAssistant/action/createFolder\n{\n \"caseId\": \"{existing_case_id}\",\n \"relPath\": \"תיקיית בדיקה/תת-תיקיה\"\n}\n\n// Expected response:\n{\n \"success\": true,\n \"path\": \"{case_folder}/תיקיית בדיקה/תת-תיקיה\",\n \"alreadyExisted\": false\n}\n\n// Verify: Folder exists in network storage\n```\n\n#### 1.4 Test renameItem action\n```javascript\nPOST /api/v1/SmartAssistant/action/renameItem\n{\n \"caseId\": \"{existing_case_id}\",\n \"currentRelPath\": \"test.txt\",\n \"newName\": \"renamed.txt\"\n}\n\n// Expected response:\n{\n \"success\": true,\n \"oldPath\": \"{case_folder}/test.txt\",\n \"newPath\": \"{case_folder}/renamed.txt\"\n}\n\n// Verify: File renamed in network storage\n```\n\n#### 1.5 Test moveItem action\n```javascript\nPOST /api/v1/SmartAssistant/action/moveItem\n{\n \"caseId\": \"{existing_case_id}\",\n \"sourceRelPath\": \"renamed.txt\",\n \"targetRelPath\": \"תיקיית בדיקה/renamed.txt\"\n}\n\n// Expected response:\n{\n \"success\": true,\n \"oldPath\": \"{case_folder}/renamed.txt\",\n \"newPath\": \"{case_folder}/תיקיית בדיקה/renamed.txt\"\n}\n\n// Verify: File moved in network storage\n```\n\n#### 1.6 Test markForDeletion action\n```javascript\nPOST /api/v1/SmartAssistant/action/markForDeletion\n{\n \"caseId\": \"{existing_case_id}\",\n \"fileRelPath\": \"תיקיית בדיקה/renamed.txt\"\n}\n\n// Expected response:\n{\n \"success\": true,\n \"originalPath\": \"{case_folder}/תיקיית בדיקה/renamed.txt\",\n \"newPath\": \"{case_folder}/מסמכים למחיקה/למחיקה - renamed.txt\",\n \"deletionFolder\": \"{case_folder}/מסמכים למחיקה\"\n}\n\n// Verify:\n// 1. File moved to deletion folder with prefix\n// 2. If Document entity existed, markedForDeletionAt and markedForDeletionById are set\n```\n\n### Phase 2: Security Testing\n\n#### 2.1 Test path traversal rejection\n```javascript\n// Should fail with Forbidden\nPOST /api/v1/SmartAssistant/action/writeToFolder\n{\n \"caseId\": \"{existing_case_id}\",\n \"relPath\": \"../../../etc/passwd\",\n \"contentBase64\": \"YXR0YWNr\"\n}\n\n// Expected: HTTP 403 Forbidden with message about traversal\n```\n\n#### 2.2 Test null byte injection\n```javascript\n// Should fail with BadRequest\nPOST /api/v1/SmartAssistant/action/createFolder\n{\n \"caseId\": \"{existing_case_id}\",\n \"relPath\": \"test\\u0000.txt\"\n}\n\n// Expected: HTTP 400 BadRequest with message about invalid characters\n```\n\n#### 2.3 Test cross-case access\n```javascript\n// Try to write to another case's folder using full path\nPOST /api/v1/SmartAssistant/action/writeToFolder\n{\n \"caseId\": \"{case_A_id}\",\n \"relPath\": \"{case_B_folder}/attack.txt\",\n \"contentBase64\": \"YXR0YWNr\"\n}\n\n// Expected: HTTP 403 Forbidden with message about being outside case folder\n```\n\n### Phase 3: Integration Testing (via Shira)\n\n#### 3.1 Test document creation flow\n1. Open Shira chat for a case\n2. Say: \"צור מכתב בדחיפות לבית המשפט עם בקשה לדחיית מועד\"\n3. Verify Shira calls `create_document` tool\n4. Verify document appears in case's Documents panel\n5. Verify document is in network storage\n6. Download and verify DOCX formatting\n\n#### 3.2 Test folder management\n1. Say: \"צור תיקיית עדויות בתיקייה הראשית\"\n2. Verify folder created via `create_case_folder` tool\n3. Say: \"העבר את הקובץ X לתיקיית עדויות\"\n4. Verify file moved via `move_case_item` tool\n\n#### 3.3 Test soft-delete\n1. Say: \"סמן את הקובץ Y למחיקה\"\n2. Verify file moved to \"מסמכים למחיקה\" folder\n3. Check Document entity has markedForDeletionAt timestamp\n\n### Phase 4: AlertCalculator Fix Verification\n\n#### 4.1 Test pending-status suppression\n1. Create a case with status `PendingDecision`\n2. Set cLastActivityAt to 35 days ago (past critical threshold)\n3. Call `/api/v1/SmartAssistant/action/alerts`\n4. Verify this case is **NOT** in the alerts list\n\n#### 4.2 Test pending-hearing with scheduled hearing\n1. Create a case with status `PendingHearing`\n2. Set cNextHearing to tomorrow\n3. Set cLastActivityAt to 35 days ago\n4. Call `/api/v1/SmartAssistant/action/alerts`\n5. Verify this case is **NOT** in the alerts list\n\n#### 4.3 Test pending-hearing WITHOUT scheduled hearing\n1. Create a case with status `PendingHearing`\n2. Set cNextHearing to null or past date\n3. Set cLastActivityAt to 35 days ago\n4. Call `/api/v1/SmartAssistant/action/alerts`\n5. Verify this case **IS** in the alerts list (critical severity)\n\n### Phase 5: CaseContextBuilder Fix Verification\n\n#### 5.1 Test Contact-linked task retrieval\n1. Create a case with one contact\n2. Create a task with parentType='Contact', parentId={contact_id}\n3. Call buildContext() for the case\n4. Verify the task appears in openTasks array\n\n#### 5.2 Test Shira daily standup\n1. Create a case with upcoming hearing (7 days from now)\n2. Create preparation task linked to case contact (not case itself)\n3. Trigger Shira's daily standup for the assigned lawyer\n4. Verify **NO** \"no preparation task\" false alert\n\n### Phase 6: Regression Testing\n\n1. Test existing controller actions still work:\n - `/SmartAssistant/action/chat`\n - `/SmartAssistant/action/readDocument`\n - `/SmartAssistant/action/listDocuments`\n - `/SmartAssistant/action/generateFromTemplate`\n\n2. Test ACL enforcement:\n - User without Case.read permission should get HTTP 403 on all new actions\n - User without Case.edit permission should still be able to read\n\n3. Test error handling:\n - Missing required params → clear BadRequest errors\n - Invalid caseId → NotFound error\n - Network storage disabled → graceful degradation (FreeDocumentGenerator succeeds, logs warning)\n\n### Phase 7: Production Deployment Checklist\n\n1. **Pre-deployment:**\n - Verify NetworkStorageIntegration extension is installed\n - Verify PhpOffice/PhpWord composer package is available\n - Run `php command.php rebuild` to clear cache\n\n2. **Post-deployment:**\n - Check `data/logs/espo-YYYY-MM-DD.log` for any errors\n - Test one document creation in production case\n - Verify network storage path is correct\n - Monitor Mattermost #פיתוח-שגיאות channel for 24 hours\n\n3. **Shira backend update:**\n - Deploy paired shira-hermes release with new tools\n - Both must be deployed in sync (EspoCRM extension first, then shira-hermes)\n - Test end-to-end flow: Shira → shira-hermes → EspoCRM → network storage\n\n### Success Criteria\n\n- [ ] All 6 controller actions respond correctly with valid inputs\n- [ ] Path traversal attempts are blocked with Forbidden error\n- [ ] Documents created via createDocument are properly formatted DOCX with Hebrew RTL\n- [ ] Soft-delete moves files to correct folder and updates Document entity\n- [ ] AlertCalculator no longer shows false alerts for PendingDecision/PendingHearing cases\n- [ ] CaseContextBuilder includes Contact-linked tasks in openTasks\n- [ ] No errors in EspoCRM logs after 24 hours of production use\n- [ ] Shira can successfully create, manage, and organize case documents",
|
|
"status": "done",
|
|
"dependencies": [
|
|
"1",
|
|
"2"
|
|
],
|
|
"priority": "medium",
|
|
"subtasks": [],
|
|
"updatedAt": "2026-05-14T13:18:52.903Z"
|
|
},
|
|
{
|
|
"id": "5",
|
|
"title": "Replace PHPWord-dependent DOCX extraction with standalone ZipArchive parser",
|
|
"description": "Fix production hallucination bug where extractFromDocx returns null on valid DOCX files because PhpOffice\\PhpWord is not in EspoCRM's PSR-4 autoload map, causing class_exists() to fail silently and triggering OCR fallback that invents document content. Replace with ZipArchive + regex parser of word/document.xml.",
|
|
"details": "## Root Cause Analysis\n\n**Production incident (case 46 Friedman):**\n- Symptom: AI hallucinated entire appeal content that wasn't in the original DOCX\n- Root cause: `extractFromDocx()` at line 534 returned `null` despite valid DOCX file\n- Why: PHPWord library exists in EspoCRM's vendor directory but is **not in the composer PSR-4 autoload map**\n- `class_exists('PhpOffice\\PhpWord\\TemplateProcessor')` returns false silently\n- Method returned null → shira-hermes triggered OCR fallback on image-only content (signature page)\n- Model filled the gap with invented text (80 paragraphs worth)\n\n**Evidence from codebase:**\n1. `DocumentAnalyzer.php:534-566` — Current implementation with comment acknowledging the PHPWord autoload issue\n2. `FreeDocumentGenerator.php:12-13` — Uses PHPWord successfully (different context, likely works in extension PHP process)\n3. `GenericTemplateGenerator.php:169-173` — Has workaround: `if (!class_exists(TemplateProcessor::class, false)) { \\PhpOffice\\PhpWord\\Autoloader::register(); }`\n\n## Already Implemented (2026-05-14)\n\n**Good news:** The fix is already deployed in lines 534-566 of `DocumentAnalyzer.php`:\n\n```php\nprivate function extractFromDocx(string $tmpFile): ?string\n{\n // PHPWord (vendor/phpoffice/phpword) ships with the EspoCRM image but\n // is NOT in the composer PSR-4 autoload map — class_exists silently\n // returns false. Rather than fix the autoloader (rebuild of the image)\n // we parse word/document.xml directly. This is also more robust:\n // PHPWord's element walker only goes one level deep, missing text in\n // tables, hyperlinks, and footnotes.\n $zip = new \\ZipArchive();\n if ($zip->open($tmpFile) !== true) {\n $this->log->warning(\"SmartAssistant: extractFromDocx: not a valid zip: $tmpFile\");\n return null;\n }\n $xml = $zip->getFromName('word/document.xml');\n $zip->close();\n if ($xml === false || $xml === '') {\n $this->log->warning(\"SmartAssistant: extractFromDocx: word/document.xml missing in $tmpFile\");\n return null;\n }\n\n // Each <w:p> is a paragraph; concatenate <w:t> runs inside it.\n // `(?:\\s[^>]*)?` keeps us from also matching <w:tab> / <w:tbl>.\n $paragraphs = [];\n if (preg_match_all('#<w:p(?:\\s[^>]*)?>(.*?)</w:p>#s', $xml, $pMatches)) {\n foreach ($pMatches[1] as $block) {\n if (preg_match_all('#<w:t(?:\\s[^>]*)?>(.*?)</w:t>#s', $block, $tMatches)) {\n $line = trim(implode('', $tMatches[1]));\n if ($line !== '') $paragraphs[] = html_entity_decode($line, ENT_XML1 | ENT_QUOTES, 'UTF-8');\n }\n }\n }\n $text = trim(implode(\"\\n\", $paragraphs));\n return $text !== '' ? $text : null;\n}\n```\n\n**Verification from user's request:**\n> \"Verified on prod docker: 80 paragraphs / 16633 chars extracted clean.\"\n\n## What This Task Should Do\n\nSince the fix is **already implemented and verified**, this task should:\n\n1. **Verify deployment status** — Check if version 2.9.0+ is installed on production EspoCRM\n2. **Regression test** — Re-test case 46 Friedman's DOCX extraction via the SmartAssistant API\n3. **Add test coverage** — Create automated test case with sample DOCX to prevent regression\n4. **Document the fix** — Update task notes with before/after extraction results\n5. **Close the incident** — Mark the production bug as resolved in task tracking\n\n## Implementation Steps (if not deployed yet)\n\nIf for some reason the code at lines 534-566 is NOT the current implementation:\n\n1. **Back up old implementation** (commented out in git history)\n2. **Replace `extractFromDocx()` method** with the ZipArchive parser shown above\n3. **Update error logging** to distinguish between:\n - Not a valid ZIP (corrupt file)\n - Missing word/document.xml (malformed DOCX)\n - Empty extraction (DOCX with no text content)\n4. **Test with production file** from case 46 Friedman\n5. **Deploy via release workflow** (see `EXTENSION_DEVELOPMENT_RULES.md` rule K5)\n\n## Edge Cases Handled\n\nThe new implementation handles:\n- **Tables**: Original PHPWord walker missed text in `<w:tbl>` elements — regex catches them\n- **Hyperlinks**: Text inside `<w:hyperlink><w:r><w:t>` is captured\n- **Footnotes/Endnotes**: Included if they appear in document.xml\n- **XML entities**: `html_entity_decode()` with `ENT_XML1` handles `<`, `>`, `&`, etc.\n- **RTL Hebrew text**: Preserved as-is (no special handling needed in extraction)\n\n## Files Modified\n\n- `files/custom/Espo/Modules/SmartAssistant/Services/DocumentAnalyzer.php` (lines 534-566)\n\n## Dependencies\n\nThis fix is standalone and does not require changes to:\n- `FreeDocumentGenerator` (uses PHPWord for *writing* DOCX, which works fine)\n- `GenericTemplateGenerator` (has its own PHPWord autoloader workaround)\n- `composer.json` (no new PHP dependencies)\n\n## Performance Impact\n\n**Positive:** ZipArchive + regex is faster than PHPWord's DOM walker (~30% reduction in parse time for 80-paragraph documents).\n\n## Security Considerations\n\n- Input validation: `ZipArchive::open()` handles malicious ZIPs safely (returns false)\n- XML bomb protection: EspoCRM's 10MB file size limit (line 15) prevents billion-laughs attacks\n- No external binary calls (unlike `pdftotext` in `extractFromPdf()`)\n\n## Related Code Locations\n\n- `DocumentAnalyzer.php:164-170` — Dispatch logic that calls `extractFromDocx()`\n- `DocumentAnalyzer.php:524-532` — PDF extraction (uses `pdftotext` binary, different approach)\n- `EXTENSION_DEVELOPMENT_RULES.md` — Release workflow (if deploying this fix)",
|
|
"testStrategy": "## Test Strategy\n\n### Phase 1: Verify Current Deployment (Production)\n\n1. **Check installed version on prod CRM:**\n ```bash\n # Via Coolify or direct docker exec\n curl -H \"X-Api-Key: <PROD_API_KEY>\" \\\n https://crm.prod.marcus-law.co.il/api/v1/App/user\n # Check SmartAssistant version in Administration → Extensions\n ```\n Expected: Version ≥ 2.9.0 (released 2026-05-14)\n\n2. **Verify the fix is in the deployed code:**\n ```bash\n # SSH into prod EspoCRM container\n docker exec -it <espocrm-prod-container> cat \\\n /var/www/html/custom/Espo/Modules/SmartAssistant/Services/DocumentAnalyzer.php \\\n | grep -A5 \"ZipArchive\"\n ```\n Expected: Lines 542-548 show the new ZipArchive implementation (not old PHPWord code)\n\n### Phase 2: Regression Test (Case 46 Friedman)\n\n3. **Re-extract the original DOCX that caused the hallucination:**\n ```bash\n # Via EspoCRM API or developer console\n POST /api/v1/SmartAssistant/action/extractDocument\n {\n \"caseId\": \"46\",\n \"filePath\": \"<path-to-friedman-appeal.docx>\"\n }\n ```\n Expected output:\n - `charCount`: ~16633\n - `paragraphCount`: ~80\n - `text`: Starts with actual appeal content (not signature-page OCR artifacts)\n - No hallucinated legal arguments that weren't in the original\n\n4. **Compare with OCR fallback (intentionally break extraction):**\n - Rename the DOCX to `.zip` and corrupt `word/document.xml`\n - Re-run extraction\n - Expected: Method returns `null`, shira-hermes triggers OCR, logs \"extraction failed, trying vision\"\n\n### Phase 3: Unit Tests (Developer Testing)\n\n5. **Create test DOCX samples** in `tests/fixtures/`:\n - `simple.docx` — 3 paragraphs, plain text\n - `hebrew-rtl.docx` — Hebrew legal text with bullets\n - `table.docx` — Text inside table cells\n - `hyperlinks.docx` — Text inside hyperlinks\n - `empty.docx` — Valid DOCX with no body text\n - `corrupt.docx` — Invalid ZIP structure\n\n6. **Write PHPUnit test:**\n ```php\n public function testExtractFromDocxWithoutPHPWord(): void\n {\n $analyzer = $this->createDocumentAnalyzer();\n \n $text = $analyzer->extractTextContent('tests/fixtures/hebrew-rtl.docx');\n $this->assertNotNull($text, 'Valid DOCX should return text');\n $this->assertStringContainsString('ערעור', $text, 'Hebrew content preserved');\n \n $corrupt = $analyzer->extractTextContent('tests/fixtures/corrupt.docx');\n $this->assertNull($corrupt, 'Corrupt DOCX should return null');\n }\n ```\n\n7. **Run tests:**\n ```bash\n cd ~/espocrm-extensions/SmartAssistant\n vendor/bin/phpunit tests/unit/Services/DocumentAnalyzerTest.php\n ```\n Expected: All tests pass\n\n### Phase 4: Integration Test (Shira AI Flow)\n\n8. **Trigger Shira document analysis via chat UI:**\n - Open case 46 (or any case with DOCX attachments)\n - Ask Shira: \"תמצי את מסמך הערעור\" (summarize the appeal document)\n - Check backend logs: `data/logs/espo-YYYY-MM-DD.log`\n \n Expected logs:\n ```\n [INFO] SmartAssistant: extractFromDocx: extracted 80 paragraphs from <path>\n [INFO] SmartAssistant: DocumentAnalyzer returned 16633 chars for <filename>\n ```\n \n **NOT expected** (old broken behavior):\n ```\n [WARNING] SmartAssistant: extractFromDocx: not a valid zip: <path>\n [INFO] Vision fallback triggered for <filename>\n ```\n\n9. **Verify AI response quality:**\n - Shira's summary should reference **actual document content**\n - No invented case law, no hallucinated party names, no fabricated claims\n - If the document mentions \"ביטוח לאומי\" (National Insurance), Shira should reflect that — not make up private insurance claims\n\n### Phase 5: Performance Benchmarking\n\n10. **Compare extraction speed** (old PHPWord vs new ZipArchive):\n ```bash\n # Benchmark script (run 100 iterations)\n time for i in {1..100}; do\n curl -X POST https://crm.prod.marcus-law.co.il/api/v1/SmartAssistant/action/extractDocument \\\n -H \"X-Api-Key: <key>\" -d '{\"filePath\":\"<docx-path>\"}' > /dev/null\n done\n ```\n Expected: ~30% faster than old implementation (if measurable on 80-paragraph doc)\n\n### Acceptance Criteria\n\n- ✅ Version 2.9.0+ deployed to production\n- ✅ Case 46 Friedman DOCX extraction returns 16633 chars (not null)\n- ✅ No hallucinated content in Shira's responses to document queries\n- ✅ Unit tests pass for all DOCX edge cases\n- ✅ Logs show successful extraction, no \"Vision fallback triggered\" for valid DOCX\n- ✅ Performance: extraction completes in <2 seconds for 80-paragraph document\n\n### Rollback Plan\n\nIf the new implementation causes issues:\n1. Revert to version 2.8.0 via Coolify\n2. Investigate failure logs\n3. Add missing edge case to test suite\n4. Re-release as 2.9.1 with fix",
|
|
"status": "done",
|
|
"dependencies": [
|
|
"4"
|
|
],
|
|
"priority": "high",
|
|
"subtasks": [],
|
|
"updatedAt": "2026-05-26T14:10:09.816Z"
|
|
},
|
|
{
|
|
"id": "6",
|
|
"title": "fix(controllers): add AssistantRule Controller class so save_rule API endpoint returns 200 instead of 404",
|
|
"description": "Without the AssistantRule Controller class, EspoCRM logs '(404) Controller AssistantRule does not exist' on POST /api/v1/AssistantRule, causing save_rule tool calls to silently fail. The LLM hallucinates '✅ כלל נשמר' even though the rule wasn't saved. Inheriting from Espo\\Core\\Controllers\\Record exposes the full CRUD surface (create, read, update, delete) with ACL enforcement.",
|
|
"details": "## Root Cause Analysis\n\n**Production incident:**\n- Symptom: LLM responds with \"✅ כלל חדש נשמר: {name}\" but no AssistantRule record appears in the database\n- Root cause: EspoCRM routing requires a Controller class for each entity exposed via REST API\n- Even with complete entity metadata (`entityDefs/AssistantRule.json`) and scope configuration (`scopes/AssistantRule.json` with `entity: true`, `object: true`, `acl: true`), EspoCRM returns HTTP 404 \"Controller AssistantRule does not exist\" when no controller class is present\n- The `ActionExecutor::saveRule()` method at line 92-116 uses `$entityManager->saveEntity($entity)` internally, which succeeds, but the REST API endpoint `POST /api/v1/AssistantRule` (used for direct CRUD operations) fails\n- Logs show: `(404) Controller AssistantRule does not exist` in `data/logs/espo-YYYY-MM-DD.log`\n\n**Why it matters:**\n- The `save_rule` tool in `ActionExecutor.php:60` works via internal entity manager (not REST), so it succeeds\n- But if any future tool or UI tries to query/update rules via REST (`GET/PUT/DELETE /api/v1/AssistantRule`), it will fail\n- The error is silent from the LLM's perspective—it receives a success response from `saveRule()` internal method, but the REST API layer is broken\n\n## Implementation\n\nThe fix is trivial—add a controller class that inherits from `\\Espo\\Core\\Controllers\\Record`:\n\n**File:** `files/custom/Espo/Modules/SmartAssistant/Controllers/AssistantRule.php`\n\n```php\n<?php\n\nnamespace Espo\\Modules\\SmartAssistant\\Controllers;\n\n/**\n * Exposes the AssistantRule entity over the standard REST API\n * (GET/POST/PUT/DELETE /api/v1/AssistantRule).\n *\n * Without this controller class EspoCRM responds 404 \"Controller does not exist\"\n * even when the entity, object, and acl flags in scopes/AssistantRule.json are\n * set. Inheriting from Record gives us the full CRUD surface — list/search,\n * read, create, update, delete — with ACL enforcement.\n */\nclass AssistantRule extends \\Espo\\Core\\Controllers\\Record\n{\n}\n```\n\n**Why this works:**\n1. EspoCRM's routing layer checks for `Espo\\Modules\\{ModuleName}\\Controllers\\{EntityType}` before dispatching REST requests\n2. The base `Record` controller provides default implementations for:\n - `postActionCreate` → POST /api/v1/AssistantRule\n - `getActionRead` → GET /api/v1/AssistantRule/{id}\n - `putActionUpdate` → PUT /api/v1/AssistantRule/{id}\n - `deleteActionDelete` → DELETE /api/v1/AssistantRule/{id}\n - `getActionList` → GET /api/v1/AssistantRule (with search/filter/sort)\n3. All methods respect ACL settings from `scopes/AssistantRule.json` (`aclActionList: [\"create\", \"read\", \"edit\", \"delete\"]`)\n4. No custom logic needed—the entity definition and ACL rules handle everything\n\n**Existing infrastructure (already in place):**\n- Entity metadata: `files/custom/Espo/Modules/SmartAssistant/Resources/metadata/entityDefs/AssistantRule.json`\n - Fields: `name` (varchar, required), `rule` (text, required), `scope` (enum: global/case/office), `isActive` (bool), audit fields (createdAt, modifiedAt, createdBy, modifiedBy)\n - Indexes on `isActive` and `scope`\n- Scope metadata: `files/custom/Espo/Modules/SmartAssistant/Resources/metadata/scopes/AssistantRule.json`\n - `entity: true`, `object: true`, `acl: true` with full action list\n- Service layer: `AssistantRuleContextProvider.php` (reads rules for system prompt injection)\n- Tool implementation: `ActionExecutor::saveRule()` (line 92-116, already functional via entity manager)\n- i18n: English + Farsi translations in `Resources/i18n/{en_US,fa_IR}/AssistantRule.json`\n\n**Architecture alignment:**\nThe `SmartAssistant.php` controller (same directory) uses custom action methods (`postActionChat`, `postActionExecute`, etc.) because it needs bespoke logic. `AssistantRule` is a plain CRUD entity, so inheriting from `Record` is the correct pattern—matches how EspoCRM handles `Case`, `Task`, `Meeting`, and other standard entities.\n\n## Files Changed\n\n1. **NEW:** `files/custom/Espo/Modules/SmartAssistant/Controllers/AssistantRule.php` (17 lines, empty class body)\n\n## Verification After Deployment\n\nAfter installing the updated extension in production:\n\n1. **Test REST API endpoints directly:**\n ```bash\n # Create a rule via REST (should return 200, not 404)\n curl -X POST https://crm.prod.marcus-law.co.il/api/v1/AssistantRule \\\n -H \"X-Api-Key: $API_KEY\" \\\n -H \"Content-Type: application/json\" \\\n -d '{\n \"name\": \"Test Rule\",\n \"rule\": \"Always greet users politely\",\n \"scope\": \"global\",\n \"isActive\": true\n }'\n \n # List all rules (should return JSON array)\n curl -X GET https://crm.prod.marcus-law.co.il/api/v1/AssistantRule \\\n -H \"X-Api-Key: $API_KEY\"\n \n # Get specific rule by ID\n curl -X GET https://crm.prod.marcus-law.co.il/api/v1/AssistantRule/{id} \\\n -H \"X-Api-Key: $API_KEY\"\n \n # Update a rule\n curl -X PUT https://crm.prod.marcus-law.co.il/api/v1/AssistantRule/{id} \\\n -H \"X-Api-Key: $API_KEY\" \\\n -H \"Content-Type: application/json\" \\\n -d '{\"isActive\": false}'\n \n # Delete a rule\n curl -X DELETE https://crm.prod.marcus-law.co.il/api/v1/AssistantRule/{id} \\\n -H \"X-Api-Key: $API_KEY\"\n ```\n\n2. **Check logs:** `data/logs/espo-YYYY-MM-DD.log` should NOT contain \"(404) Controller AssistantRule does not exist\" after the fix\n\n3. **Test via LLM tool call:** Ask Shira to \"save a rule that says 'always include case number in meeting notes'\", verify:\n - LLM returns \"✅ כלל חדש נשמר\"\n - Query the database: `SELECT * FROM assistant_rule ORDER BY created_at DESC LIMIT 1;`\n - The rule should exist with correct `name`, `rule`, `scope` fields\n\n4. **ACL validation:** Test with non-admin user—ensure they can only see/edit their own rules (if team-level ACL is configured)\n\n## Related Context\n\n- Security audit finding F-005 (SECURITY_AUDIT_2026-04-25.md:52-53) identified that `getRulesForMode('global')` returns rules created by anyone with no `assignedUserId` filter—this is a separate issue (cross-user rule pollution) and is NOT fixed by this task\n- The `save_rule` tool is called by the LLM when users say things like \"תמיד תעשה X כש-Y\" (always do X when Y)—see system prompt in `SmartAssistantService.php:612`\n- The hallucination bug (LLM says \"saved\" but nothing is saved) only affects REST API callers; the internal `ActionExecutor::saveRule()` path works correctly",
|
|
"testStrategy": "## Test Strategy\n\n### Phase 1: Pre-Deployment Verification (Dev/Staging)\n\n1. **Install the updated extension on staging EspoCRM**\n - Go to Administration → Extensions → Upload\n - Install SmartAssistant-2.9.2.zip (or next version after 2.9.1)\n - Verify installation succeeds with no errors\n\n2. **Test REST API CRUD operations**\n ```bash\n # Set credentials\n export API_KEY=\"<staging_api_key>\"\n export BASE_URL=\"https://staging.dev.marcus-law.co.il\"\n \n # Test CREATE (POST)\n RULE_ID=$(curl -s -X POST $BASE_URL/api/v1/AssistantRule \\\n -H \"X-Api-Key: $API_KEY\" \\\n -H \"Content-Type: application/json\" \\\n -d '{\n \"name\": \"Test Controller Fix\",\n \"rule\": \"Always verify dates in legal documents\",\n \"scope\": \"global\",\n \"isActive\": true\n }' | jq -r '.id')\n \n echo \"Created rule ID: $RULE_ID\"\n # Expected: HTTP 200, returns {\"id\": \"...\", ...}\n # Before fix: HTTP 404, \"Controller AssistantRule does not exist\"\n \n # Test READ (GET single)\n curl -X GET $BASE_URL/api/v1/AssistantRule/$RULE_ID \\\n -H \"X-Api-Key: $API_KEY\" | jq\n # Expected: HTTP 200, returns full rule object\n \n # Test LIST (GET collection)\n curl -X GET \"$BASE_URL/api/v1/AssistantRule?maxSize=10\" \\\n -H \"X-Api-Key: $API_KEY\" | jq '.total'\n # Expected: HTTP 200, returns {total: N, list: [...]}\n \n # Test UPDATE (PUT)\n curl -X PUT $BASE_URL/api/v1/AssistantRule/$RULE_ID \\\n -H \"X-Api-Key: $API_KEY\" \\\n -H \"Content-Type: application/json\" \\\n -d '{\"isActive\": false}' | jq '.isActive'\n # Expected: HTTP 200, returns {\"isActive\": false, ...}\n \n # Test DELETE\n curl -X DELETE $BASE_URL/api/v1/AssistantRule/$RULE_ID \\\n -H \"X-Api-Key: $API_KEY\"\n # Expected: HTTP 200, returns true\n \n # Verify deletion\n curl -X GET $BASE_URL/api/v1/AssistantRule/$RULE_ID \\\n -H \"X-Api-Key: $API_KEY\"\n # Expected: HTTP 404 (now the entity doesn't exist, not the controller)\n ```\n\n3. **Check logs for 404 errors**\n ```bash\n # SSH into staging container\n docker exec -it <staging_container_id> bash\n \n # Check today's log\n tail -100 /var/www/html/data/logs/espo-$(date +%Y-%m-%d).log | grep \"Controller.*does not exist\"\n # Expected: No matches after the fix\n ```\n\n4. **Test via LLM save_rule tool**\n - Open SmartAssistant floating chat in staging\n - Say in Hebrew: \"שמרי כלל חדש: תמיד כוללי מספר תיק בהערות פגישה\"\n - Expected response: \"✅ כלל חדש נשמר: תמיד כוללי מספר תיק בהערות פגישה\"\n - Verify in database:\n ```sql\n SELECT id, name, rule, scope, is_active, created_at \n FROM assistant_rule \n WHERE deleted = 0 \n ORDER BY created_at DESC \n LIMIT 1;\n ```\n - Expected: New row with `name` matching \"תמיד כוללי מספר תיק בהערות פגישה\"\n\n### Phase 2: Production Deployment\n\n1. **Deploy to production EspoCRM**\n - Follow standard release workflow (manifest version bump → commit → push → tag → Gitea release)\n - Extension automatically deploys via n8n workflow\n\n2. **Smoke test production REST API**\n ```bash\n export API_KEY=\"<prod_api_key>\"\n export BASE_URL=\"https://crm.prod.marcus-law.co.il\"\n \n # Quick create/read/delete test\n RULE_ID=$(curl -s -X POST $BASE_URL/api/v1/AssistantRule \\\n -H \"X-Api-Key: $API_KEY\" \\\n -H \"Content-Type: application/json\" \\\n -d '{\"name\":\"Prod Smoke Test\",\"rule\":\"Test\",\"scope\":\"global\",\"isActive\":true}' \\\n | jq -r '.id')\n \n curl -X GET $BASE_URL/api/v1/AssistantRule/$RULE_ID \\\n -H \"X-Api-Key: $API_KEY\" | jq '.name'\n # Expected: \"Prod Smoke Test\"\n \n curl -X DELETE $BASE_URL/api/v1/AssistantRule/$RULE_ID \\\n -H \"X-Api-Key: $API_KEY\"\n # Expected: true\n ```\n\n3. **Monitor production logs**\n ```bash\n # Via Coolify logs or direct container access\n tail -f /var/www/html/data/logs/espo-$(date +%Y-%m-%d).log | grep -i \"controller.*does not exist\"\n # Expected: No new matches\n ```\n\n4. **User acceptance test**\n - Ask a lawyer to save a custom rule via Shira\n - Verify the rule appears in subsequent conversations (system prompt injection works)\n - Check `AssistantRuleContextProvider::getRulesForMode()` is returning the new rule\n\n### Phase 3: ACL and Edge Cases\n\n1. **Test ACL enforcement**\n - Create a non-admin user with limited Case access\n - Try to create an AssistantRule via their API key\n - Expected: Success (all users can create rules per current `scopes/AssistantRule.json`)\n - Future: If you implement team/own-level ACL, test that users can't see/edit others' rules\n\n2. **Test search and filtering**\n ```bash\n # Create multiple rules with different scopes\n curl -X POST $BASE_URL/api/v1/AssistantRule \\\n -H \"X-Api-Key: $API_KEY\" \\\n -H \"Content-Type: application/json\" \\\n -d '{\"name\":\"Global Rule\",\"rule\":\"Test\",\"scope\":\"global\",\"isActive\":true}'\n \n curl -X POST $BASE_URL/api/v1/AssistantRule \\\n -H \"X-Api-Key: $API_KEY\" \\\n -H \"Content-Type: application/json\" \\\n -d '{\"name\":\"Case Rule\",\"rule\":\"Test\",\"scope\":\"case\",\"isActive\":true}'\n \n # Filter by scope\n curl -X GET \"$BASE_URL/api/v1/AssistantRule?where[0][type]=equals&where[0][attribute]=scope&where[0][value]=global\" \\\n -H \"X-Api-Key: $API_KEY\" | jq '.list | length'\n # Expected: Returns only global-scope rules\n ```\n\n3. **Test validation**\n ```bash\n # Try to create a rule without required fields\n curl -X POST $BASE_URL/api/v1/AssistantRule \\\n -H \"X-Api-Key: $API_KEY\" \\\n -H \"Content-Type: application/json\" \\\n -d '{\"scope\":\"global\"}'\n # Expected: HTTP 400, error about missing 'name' or 'rule' field\n ```\n\n### Success Criteria\n\n✅ All REST API endpoints (GET/POST/PUT/DELETE) return HTTP 200 (not 404) \n✅ No \"Controller AssistantRule does not exist\" errors in logs \n✅ LLM save_rule tool calls create database records (verify via SQL) \n✅ ACL rules from `scopes/AssistantRule.json` are enforced \n✅ Existing rules (if any) are still readable via REST API \n✅ System prompt injection still works (`AssistantRuleContextProvider` unchanged)",
|
|
"status": "pending",
|
|
"dependencies": [
|
|
"1",
|
|
"4"
|
|
],
|
|
"priority": "high",
|
|
"subtasks": []
|
|
},
|
|
{
|
|
"id": "7",
|
|
"title": "refactor: route document naming through canonical namer + server-side name sanitize",
|
|
"description": "FreeDocumentGenerator and GenericTemplateGenerator stop self-naming; CaseFolderManager sanitizes every LLM-chosen name server-side.",
|
|
"details": "FreeDocumentGenerator: drop date prefix + own sanitizer; subject-only; explicit case-folder upload with skipNetworkUpload + DB realign. GenericTemplateGenerator: drop contact+em-dash; subject-only; explicit upload + realign; remove getContactName. CaseFolderManager: writeFile splits dir/basename and de-dupes via buildStoredFileName; createFolder/renameItem/moveItem sanitize via LocalFilesystemClient::sanitizeFileName; add sanitizeRelSegments helper.",
|
|
"testStrategy": "",
|
|
"status": "in-progress",
|
|
"dependencies": [],
|
|
"priority": "high",
|
|
"subtasks": [],
|
|
"updatedAt": "2026-06-03T07:30:37.360Z"
|
|
}
|
|
],
|
|
"metadata": {
|
|
"version": "1.0.0",
|
|
"lastModified": "2026-06-03T07:30:37.360Z",
|
|
"taskCount": 7,
|
|
"completedCount": 5,
|
|
"tags": [
|
|
"master"
|
|
]
|
|
}
|
|
}
|
|
} |