-
High-Level Design
Persistence Model
Introduce a dedicated JPA entity, tentatively:
IssueQueryHistory
Indicative fields:
iduserId(or principal identifier)queryText(raw DSL string)source(CLI | UI)context(GLOBAL | PROJECT, optional project identifier)createdAt
The DSL query string is stored verbatim. No AST persistence is required at this stage.
Backend API
Introduce a dedicated controller responsible solely for command history management.
Indicative endpoints:
POST /api/issue-query-history- Persist a DSL query execution
GET /api/issue-query-history- Retrieve recent queries for the authenticated user
- Supports pagination / limit
Both sztabquery CLI and Sztab UI will use this controller exclusively.
No UI-specific or CLI-specific persistence logic is allowed.
Client Responsibilities
sztabquery CLI
- After successful DSL execution, POST the query string to the history controller
- On startup (or via explicit command), fetch recent history for recall
Sztab UI
- On DSL execution, POST the query string to the history controller
- Provide optional UI affordances for:
- viewing recent queries
- re-inserting a previous query into the editor
-
Time Estimate
Total estimated effort: ~6.5–8 hours
This feature spans backend persistence, API design, CLI integration, and UI wiring.
Detailed Work Breakdown
Backend – Domain & Persistence (1.5–2 hours)
- Design
IssueQueryHistoryJPA entity - Define fields, constraints, and indexes (user, timestamp)
- Add repository interface
- Add Flyway migration for table creation
- Basic unit test for persistence (optional but recommended)
Estimate: 1.5–2.0 hours
Backend – REST Controller & Service Layer (1.5–2 hours)
- Implement dedicated controller:
POST /api/issue-query-historyGET /api/issue-query-history
- Enforce user scoping from security context
- Add pagination / max-limit guard
- Ensure controller remains UI/CLI agnostic
- Error handling and validation
Estimate: 1.5–2.0 hours
sztabquery CLI Integration (1–1.5 hours)
- Add client call to persist DSL query after successful execution
- Add lightweight history fetch support (initially hidden or behind command)
- Ensure failures in history persistence do not break query execution
- Manual verification via CLI
Estimate: 1.0–1.5 hours
Sztab UI Integration (1.5–2 hours)
- Wire DSL execution to history POST endpoint
- Add API client for fetching recent history
- Optional: minimal UI affordance for recalling queries
- Verify behavior in:
- GlobalIssues page
- ProjectIssues page
Estimate: 1.5–2.0 hours
Cross-Cutting Validation & Cleanup (0.5 hour)
- Verify consistent ordering and timestamps
- Verify user isolation
- Code cleanup and naming consistency
- Final manual test pass (CLI ↔ UI continuity)
Estimate: 0.5 hour
Work Log (Planned)
### Work Log - Designed shared command-history concept spanning CLI and UI - Defined persistence strategy using JPA-backed entity - Implemented Flyway migration and repository for query history - Added dedicated REST controller for history management - Integrated history persistence into sztabquery CLI execution path - Integrated history persistence into Sztab UI DSL execution flow - Verified cross-interface continuity of query history - Performed manual validation and cleanup - Design
-
rksuma@Ramakrishnans-MacBook-Pro sztab % git checkout wolnosc Already on 'wolnosc' rksuma@Ramakrishnans-MacBook-Pro sztab % git pull Your branch is up to date with 'origin/wolnosc'. Already up to date. rksuma@Ramakrishnans-MacBook-Pro sztab % git checkout -b feature/issue-dsl-command-history Switched to a new branch 'feature/issue-dsl-command-history' rksuma@Ramakrishnans-MacBook-Pro sztab % -
rksuma@Ramakrishnans-MacBook-Pro sztab % vi frontend/src/components/issues/IssueQueryEditor.tsx rksuma@Ramakrishnans-MacBook-Pro sztab % git add frontend/src/components/issues/IssueQueryEditor.tsx rksuma@Ramakrishnans-MacBook-Pro sztab % git status On branch wolnosc Your branch is up to date with 'origin/wolnosc'. All conflicts fixed but you are still merging. (use "git commit" to conclude merge) Changes to be committed: modified: backend/src/main/java/com/sztab/controller/query/IssueQueryController.java new file: backend/src/main/java/com/sztab/model/QueryHistory.java new file: backend/src/main/java/com/sztab/repository/QueryHistoryRepository.java new file: backend/src/main/java/com/sztab/service/impl/query/QueryHistoryServiceImpl.java new file: backend/src/main/java/com/sztab/service/query/QueryHistoryService.java modified: frontend/src/api/issueQueryApi.ts modified: frontend/src/components/issues/IssueQueryEditor.tsx modified: frontend/src/types/issueQuery.ts modified: query-cli/pom.xml modified: query-cli/src/main/java/com/sztab/cli/QueryExecutor.java modified: query-cli/src/main/java/com/sztab/cli/SztabQueryCli.java rksuma@Ramakrishnans-MacBook-Pro sztab % git commit [wolnosc de041ef] Merge branch 'feature/issue-dsl-command-history' into wolnosc rksuma@Ramakrishnans-MacBook-Pro sztab % git push origin wolnosc Enumerating objects: 19, done. Counting objects: 100% (19/19), done. Delta compression using up to 12 threads Compressing objects: 100% (7/7), done. Writing objects: 100% (7/7), 669 bytes | 669.00 KiB/s, done. Total 7 (delta 6), reused 0 (delta 0), pack-reused 0 To https://tigase.dev/sztab.git 67f233d..de041ef wolnosc -> wolnosc rksuma@Ramakrishnans-MacBook-Pro sztab % git branch -d feature/issue-dsl-command-history git push origin --delete feature/issue-dsl-command-history Deleted branch feature/issue-dsl-command-history (was bfef3c4). remote: remote: Create a pull request for 'feature/issue-dsl-command-history' by visiting: remote: https://tigase.dev/sztab/~pulls/new?target=1325:wolnosc&source=1325:feature/issue-dsl-command-history remote: To https://tigase.dev/sztab.git - [deleted] feature/issue-dsl-command-history rksuma@Ramakrishnans-MacBook-Pro sztab %
| Type |
New Feature
|
| Priority |
Normal
|
| Assignee | |
| Version |
1.8
|
| Sprints |
n/a
|
| Customer |
n/a
|
Issue Votes (0)
Problem Statement
Sztab now exposes the Issue Query DSL through two distinct user interfaces:
At present, each interface maintains its own ephemeral command history (or none at all). This breaks user continuity: queries composed and refined in one interface are not visible or reusable in the other.
This issue proposes introducing a shared, persistent DSL command history, common to both sztabquery CLI and Sztab UI, so that a user’s query activity forms a single, continuous session regardless of interface.
Goals
Non-Goals (Explicitly Out of Scope)
These may be considered in later iterations.
Benefits
Notes
This feature deliberately treats the DSL command as the unit of work, not the UI action that produced it. The backend remains agnostic to whether a query originated from a terminal or a browser.