Rename custom API format handling from custom_rest to custom_rest with backward compatibility, add guided model selection with custom entry in provider settings, and rebrand app naming to Troubleshooting and RCA Assistant across UI, metadata, and docs.
Made-with: Cursor
Apply canonical rustfmt formatting in files touched by the clippy format-args cleanup so cargo fmt --check passes consistently in CI.
Made-with: Cursor
Inline format arguments across Rust modules to satisfy clippy -D warnings, and configure Cargo to prefer system OpenSSL so clippy builds do not fail on missing vendored Perl modules.
Made-with: Cursor
Replace format!("msg: {}", var) with format!("msg: {var}") across 8 files
to satisfy the uninlined_format_args lint (-D warnings) in CI run 178.
Co-Authored-By: Claude Sonnet 4.6 (1M context) <noreply@anthropic.com>
The ARM64 build was failing because explicitly specifying
--target aarch64-unknown-linux-gnu on an ARM64 runner was
triggering cross-compilation logic.
Changes:
- Remove rustup target add (not needed for native build)
- Remove --target flag from cargo tauri build
- Update artifact path: target/aarch64-unknown-linux-gnu/release/bundle
→ target/release/bundle
This allows the native ARM64 toolchain to build without
attempting cross-compilation and avoids the pkg-config
cross-compilation configuration requirement.
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
## Integration Settings Persistence
- Add database commands to save/load integration configs (base_url, username, project_name, space_key)
- Frontend now loads configs from DB on mount and saves changes automatically
- Fixes issue where settings were lost on app restart
## Persistent Browser Window Architecture
- Integration browser windows now stay open for user browsing and authentication
- Extract fresh cookies before each API call to handle token rotation
- Track open windows in app state (integration_webviews HashMap)
- Windows titled as "{Service} Browser (TFTSR)" for clarity
- Support easy navigation between app and browser windows (Cmd+Tab/Alt+Tab)
- Gracefully handle closed windows with automatic cleanup
## Bug Fixes
- Fix Rust formatting issues across 8 files
- Fix clippy warnings:
- Use is_some_and() instead of map_or() in openai.rs
- Use .to_string() instead of format!() in integrations.rs
- Add missing OptionalExtension import for .optional() method
## Tests
- Add test_integration_config_serialization
- Add test_webview_tracking
- Add test_token_auth_request_serialization
- All 6 integration tests passing
## Files Modified
- src-tauri/src/state.rs: Add integration_webviews tracking
- src-tauri/src/lib.rs: Register 3 new commands, initialize webviews HashMap
- src-tauri/src/commands/integrations.rs: Config persistence, fresh cookie extraction (+151 lines)
- src-tauri/src/integrations/webview_auth.rs: Persistent window behavior
- src/lib/tauriCommands.ts: TypeScript wrappers for new commands
- src/pages/Settings/Integrations.tsx: Load/save configs from DB
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Implement working cookie extraction using Tauri's IPC event system:
**How it works:**
1. Opens embedded browser window for user to login
2. User completes authentication (including SSO)
3. User clicks "Complete Login" button in UI
4. JavaScript injected into webview extracts `document.cookie`
5. Parsed cookies emitted via Tauri event: `tftsr-cookies-extracted`
6. Rust listens for event and receives cookie data
7. Cookies encrypted and stored in database
**Technical implementation:**
- Uses `window.__TAURI__.event.emit()` from injected JavaScript
- Rust listens via `app_handle.listen()` with Listener trait
- 10-second timeout with clear error messages
- Handles empty cookies and JavaScript errors gracefully
- Cross-platform compatible (no platform-specific APIs)
**Cookie limitations:**
- `document.cookie` only exposes non-HttpOnly cookies
- HttpOnly session cookies won't be captured via JavaScript
- For HttpOnly cookies, services must provide API tokens as fallback
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Implement three authentication methods for Confluence, ServiceNow, and Azure DevOps:
1. **OAuth2** - Traditional OAuth flow for enterprise SSO environments
2. **Embedded Browser** - Webview-based login that captures session cookies/tokens
- Solves VPN constraints: users authenticate off-VPN via web UI
- Extracted credentials work on-VPN for API calls
- Based on confluence-publisher agent pattern
3. **Manual Token** - Direct API token/PAT input as fallback
**Changes:**
- Add webview_auth.rs module for embedded browser authentication
- Implement authenticate_with_webview and extract_cookies_from_webview commands
- Implement save_manual_token command with validation
- Add AuthMethod enum to support all three modes
- Add RadioGroup UI component for mode selection
- Complete rewrite of Integrations settings page with mode-specific UI
- Add secondary button variant for UI consistency
**VPN-friendly design:**
Users can authenticate via webview when off-VPN (web UI accessible), then use extracted cookies for API calls when on-VPN (API requires VPN). Addresses enterprise SSO limitations where OAuth app registration is blocked.
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
- Added max_tokens and temperature fields to ProviderConfig
- Custom REST providers now send modelConfig with temperature and max_tokens
- OpenAI-compatible providers now use configured max_tokens/temperature
- Both formats fall back to defaults if not specified
- Bumped version to 0.2.9
This allows users to configure response length and randomness for all
AI providers, including Custom REST providers which require modelConfig format.
- Updated wiki-sync job to use secrets.Wiki for authentication
- Simplified clone/push logic with token-based auth
- Wiki push will now succeed with proper credentials
- Bumped version to 0.2.8
The workflow now uses the 'Wiki' secret created in Gitea Actions
to authenticate wiki repository pushes. This fixes the authentication
issue that was preventing automatic wiki synchronization.
- Added wiki-sync job to .gitea/workflows/test.yml
- Runs only on pushes to master branch
- Automatically copies docs/wiki/*.md to Gogs wiki repository
- Supports token-based authentication via secrets.GITHUB_TOKEN
- Handles wiki initialization if repository doesn't exist
- Bumped version to 0.2.7
Wiki sync will now automatically update the Gogs wiki at
https://gogs.tftsr.com/sarman/tftsr-devops_investigation/wiki
whenever docs/wiki/ files are modified on master.
Fixes:
- Added shell:allow-open permission to fix OAuth integration flows
- Added user_id field to ProviderConfig for Custom REST provider CORE ID
- Added UI field for user_id when api_format is custom_rest
- Made userId optional in Custom REST provider requests (only sent if provided)
- Added X-msi-genai-client header to Custom REST provider requests
- Updated CSP to include Custom REST provider domains
- Bumped version to 0.2.6
This fixes:
- OAuth error: 'Command plugin:shell|open not allowed by ACL'
- Missing User ID field in Custom REST provider configuration UI
- Added GenAI API User Guide.md with complete API specification
- Added HANDOFF-MSI-GENAI.md documenting custom provider implementation
- Includes API endpoints, request/response formats, available models, and rate limits
- Extended ProviderConfig with optional custom fields for non-OpenAI APIs
- Added custom_endpoint_path, custom_auth_header, custom_auth_prefix fields
- Added api_format field to distinguish between OpenAI and Custom REST provider formats
- Added session_id field for stateful conversation APIs
- Implemented chat_custom_rest() method in OpenAI provider
- Custom REST provider uses different request format (prompt+sessionId) and response (msg field)
- Updated TypeScript types to match Rust schema
- Added UI controls in Settings/AIProviders for custom provider configuration
- API format selector auto-populates appropriate defaults (OpenAI vs Custom REST provider)
- Backward compatible: existing providers default to OpenAI format
Phase 2.2: OAuth2 flow - Part 3 (Callback server) COMPLETE ✅
Implemented:
- Local HTTP server on localhost:8765 using warp
* GET /callback?code=...&state=... - OAuth redirect handler
* GET /health - Health check endpoint
* Graceful shutdown with oneshot channel
- Automatic callback handling
* Server auto-starts on first initiate_oauth call
* Background task listens for OAuth redirects
* Automatically exchanges code for token
* Stores encrypted token in database
* Logs audit event for each successful OAuth
- Updated initiate_oauth command
* Starts callback server if not running
* Stores (service, verifier) tuple in OAuth state
* Returns auth URL to open in browser/webview
- Updated handle_oauth_callback_internal
* Accepts AppState reference (not State)
* Called automatically by callback server
* Exchanges code, encrypts token, stores in DB
- Beautiful success/error HTML pages
* Green checkmark on success
* Auto-closes window after 3 seconds
* Clear error messages on failure
- Global state management
* OAUTH_STATE: Maps state key -> (service, verifier)
* CALLBACK_SERVER_SHUTDOWN: Holds shutdown channel
* Thread-safe with Mutex wrappers
Dependencies added:
- warp 0.3 - Lightweight HTTP framework
TDD tests (7 passing with --test-threads=1):
Callback server tests:
* Health endpoint verification
* Callback parameter parsing
* Missing/partial parameter handling
* Graceful shutdown
Integration command tests:
* OAuth state storage and retrieval
* Multiple key management
* OAuthInitResponse serialization
COMPLETE OAUTH2 FLOW:
1. User calls initiate_oauth("confluence")
2. Callback server starts (if not running)
3. Frontend receives auth URL
4. User opens URL in browser/webview
5. User authorizes, redirected to localhost:8765/callback?code=...
6. Callback server receives redirect
7. Token exchanged automatically
8. Token encrypted and stored in DB
9. Success page shown to user
10. Window auto-closes
Next: Frontend components (AuthWindow, Settings UI, CSP updates)
Changed variant from 'outline' to 'secondary' for better visibility
in dark theme. The outline variant had insufficient contrast making
the button difficult to read.
Add professional disclaimer warning that users must accept before
creating issues. Modal appears on first visit to New Issue page.
Disclaimer covers:
- AI can make mistakes and hallucinate
- AI may provide incorrect or outdated information
- Commands may have unintended consequences
- User bears full responsibility for any actions taken
- Best practices for using AI recommendations safely
Features:
- Modal overlay with clear warning sections
- Color-coded sections (red for risks, yellow for responsibility)
- Scrollable content area for long disclaimer
- Acceptance stored in localStorage (persists across sessions)
- Re-shows modal if user tries to create issue without accepting
- Cancel button returns to dashboard
Tested: TypeScript compilation ✓, Rust formatting ✓
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Replace pandoc-based DOCX export with native Rust implementation
using docx-rs crate. DOCX export now works out of the box without
requiring users to install external tools.
Changes:
- Added docx-rs dependency to Cargo.toml
- Implemented export_docx() in exporter.rs
- Removed pandoc subprocess calls from docs.rs
- Uses same markdown parsing as PDF export
- Handles titles, headings, and normal text with appropriate styling
Tested:
- Rust compilation ✓
- Rust formatting ✓
- TypeScript types ✓
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Fresh start with clean release history.
All previous tags and releases have been cleaned up.
This commit will trigger auto-tag to create v0.2.0.
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
1. Download Button Visibility:
- Changed from variant=outline to default variant (solid background)
- Provides better contrast and icon visibility in both themes
- Removed unnecessary text-foreground class
2. DOCX Export Support:
- Added DOCX export via pandoc conversion
- Writes temp markdown file, converts with pandoc, cleans up
- Returns clear error if pandoc not installed
- Supports same workflow as MD/PDF exports
3. Triaging Status Investigation:
- triaging status is defined in schema and used in dashboard counts
- Currently not automatically set when entering triage
- Kept in filter dropdown as part of the data model
Tested: Rust compilation, TypeScript types, Rust formatting
Note: DOCX export requires pandoc to be installed on the system.
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
- Use jq instead of grep for JSON parsing
- Add explicit error checking for RELEASE_ID
- Add informative logging for debugging upload failures
- Fail fast if release ID cannot be retrieved
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Update tauri.conf.json version to match release tags. This ensures
macOS properly replaces the app when installing from DMG.
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
The linux-arm64 job runs on a native ARM64 runner, so cross-compilation
setup is not needed. Removed dpkg --add-architecture, cross-compiler,
and architecture-specific package suffixes. This fixes "held broken
packages" error during dependency installation.
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
- Fix download icons (PDF/DOCX) not visible in dark theme by adding text-foreground class
- Fix "Read-only file system" error by using Downloads directory for exports with proper fallback
- Fix Search button visibility in History page by changing variant and adding icon
- Fix domain-only filtering in History page by adding missing filter.domain handling
- Enhance audit log to capture full transmitted data (provider details, messages, content previews)
- Add dirs crate dependency for cross-platform directory detection
- Add success/error feedback for document exports with file path display
- Update Security page to display pretty-printed JSON audit details
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
- Remove .woodpecker/ directory entirely (not in use)
- Fix ARM64 build in .gitea/workflows/release.yml:
- Remove --platform flag (Docker version too old)
- Use cross-compilation instead (dpkg multiarch + gcc-aarch64-linux-gnu)
- Set PKG_CONFIG environment variables for ARM64 libraries
- Set CARGO_TARGET_AARCH64_UNKNOWN_LINUX_GNU_LINKER
This matches the working cross-compilation approach from commit d489338b.
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
- domainPrompts.ts: closing }; was inside the Record object after 'automation',
leaving hpe_infra/dell_hardware/identity orphaned outside the object — caused
3 TS1005/TS1109 errors and broke the macOS and all frontend builds
- release.yml: replace multiarch cross-compilation (broken due to WebKit arm64
package conflicts) with --platform linux/arm64 container option so QEMU runs
a native ARM64 image directly — no cross-compilation, no package conflicts
- Triage: move close intent check before the currentIssue guard so closing
works even if the session hasn't fully initialized yet
- Triage: save the user's close reason as a resolution step via addFiveWhyCmd
before marking resolved, ensuring Resolution page is never empty
- App: read version from Tauri getVersion() instead of hardcoded v0.1.1
- db.rs: add get_issue_messages command (joins ai_conversations + ai_messages)
- tauriCommands.ts: fix updateIssueCmd to pass updates as nested object
(was spreading inline — Rust expects {issueId, updates}); fix addFiveWhyCmd
parameter names to match Rust (stepOrder, whyQuestion, answer, evidence);
add getIssueMessagesCmd and IssueMessage interface
- Dashboard: X button on each open issue row to close (mark resolved) inline
- Triage: restore conversation history from DB when revisiting existing issues;
detect close intent patterns and mark issue resolved + navigate home;
auto-save resolution step via addFiveWhyCmd when AI advances why level
- tests: add issueActions.test.ts covering IPC arg structure and close intent
Add comprehensive documentation for integrating AWS Bedrock Claude models via LiteLLM proxy. Enables enterprise users to leverage existing AWS contracts while maintaining OpenAI-compatible API interface.
Changes:
- README.md: Add quickstart section for LiteLLM + Bedrock setup
- docs/wiki/LiteLLM-Bedrock-Setup.md: New comprehensive guide covering single/multi-account setup, Claude Code integration, troubleshooting, and auto-start configuration
- docs/wiki/AI-Providers.md: Update OpenAI-compatible section to reference LiteLLM
- docs/wiki/Home.md: Add LiteLLM guide to navigation and feature list
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
The linux-arm64 runner runs an x86_64 Docker container so cross-compilation
requires the ARM64 sysroot via dpkg --add-architecture arm64, gcc-aarch64-linux-gnu,
and arm64 variants of all system libraries. PKG_CONFIG env vars point to the
aarch64 library paths so Tauri can find webkit/gtk/etc at compile time.
Stat cards showed 0 immediately on mount because openCount was computed
from an empty issues array before the async loadIssues call resolved.
Now shows — during load, a red error banner if the backend call fails,
and a Refresh button. useEffect dependency changed to [] (fires once on
mount, not on every loadIssues reference check).
- NewIssue navigates directly to /triage — log upload is never a blocker
- ChatWindow: paperclip button opens Tauri file dialog; pending files shown
as removable chips above the input; send enabled with files and no text
- Triage: uploads selected files via uploadLogFileCmd, reads text content
(capped at 8KB), appends file contents to AI message for context while
showing only filenames in the chat bubble
- Images/binary files are referenced by name with a prompt for the user
to describe them
- NewIssue: navigate to /issue/:id/logs so log upload step is not skipped
- Dashboard: use issue.category instead of issue.domain (field name matches Rust)
- tests: add historyStore tests covering open count logic and field mapping
