Task #58
openv19.18 frozen waiting for ticket list
0%
Description
- Handover — YDB FluentSupport Tools freeze
We freeze the current development here.
Current accepted working release:
v19.18 — soft release reload overlay
Use this as the current baseline:
[Download v19.18](sandbox:/mnt/data/ydb-fluentsupport-tools-v19-18-soft-release-reload-overlay.zip)
- Current working features
v19.18 keeps the stable behavior from the previous good line and adds the softer release refresh UX.
Working / accepted:
| Feature | Status |
| ------------------------------------------------------- | ------- |
| Conflict badge | Working |
| Release ticket button | Working |
| Forward ticket button availability | Working |
| Assignment badge | Working |
| Assignment shown near FluentSupport UI | Working |
| Reply ownership guard | Working |
| Admin archive button | Working |
| Header initials / current user | Working |
| Table-like ticket list | Working |
| After YDB Release, current browser reloads with overlay | Working |
After clicking Release ticket, the current browser shows:
Ticket released. Updating view…
Then it reloads shortly. This clears FluentSupport’s stale native assignee dropdown.
- Important lessons / decisions
- Do not fight the native FluentSupport assignee dropdown
Attempts to rewrite, hide, or override the native assignee dropdown caused problems:
- flashing between old agent and unassigned
- loss of conflict badge
- missing Release / Forward buttons
- unstable UI
Decision:
Do not rewrite FluentSupport’s native assignment dropdown directly.
Use our YDB badge/mirror for live truth, and only reload the current browser after our Release action.
- Do not force reload all viewers
Full reload for all browsers viewing the same ticket is disruptive.
Decision:
For now:
- agent who clicks Release may reload
- other agents should not be force-reloaded
- future approach should use non-disruptive prompts or partial refresh
- Bad / discarded versions
Do not use these as baselines:
| Version | Reason |
| --------------------------------- | ------------------------------------------------------------ |
| v19.06 | ticket-list assignment refresh failed |
| v19.08 | broke conflict/release/forward |
| v19.10 | caused flashing native assignee |
| v19.13 | all-viewers reload not reliable |
| v19.14 | ticket-list status refresh failed and broke release behavior |
| v19.15 | broken rollback; no updates/release/forward |
| native dropdown override attempts | too risky |
- Next development direction
We stop modifying ticket detail behavior now.
Next work should be only the ticket list.
Goal:
Build a reliable live operational ticket list showing:
| Ticket # | Subject | Status | Assigned to |
| -------- | ------- | ------ | ----------- |
Possibly later:
- Last update
- Waiting time
- Priority
- Source
- Product/tag
- Current viewers
- Handling state
- Best approach for next phase
Do not scrape or fight FluentSupport’s frontend.
Instead, use server/database as source of truth.
The FluentSupport ticket table already seems to contain useful fields such as:
- ticket ID
- `agent_id`
- `status`
- possibly priority/timestamps/customer/source
Next step should be:
1. inspect FluentSupport ticket tables
2. identify exact table/field names
3. create a YDB REST endpoint returning live state for visible ticket IDs
4. update only the YDB table-like ticket list cells
5. avoid touching ticket detail page logic
Future optional extension:
Create a linked YDB table for extra operational metadata, for example:
- last viewed by
- current handling state
- release events
- refresh prompts
- custom ticket flags
- dashboard-only fields
- Frozen baseline instruction
Continue from:
v19.18
Next modifications:
Ticket list only.
Files
No data to display