Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

issues: report from the generated views' error alerts and a per-record action, live updates of the Issues pages (follow-up of #7948)

Open
  • Is something wrong?
#7,952 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
44/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Active
Tech stack
java, javascript
Domain
backend-api-design, full-stack

Research direction

Read the follow-up context in #7948 and trace baseFormPage.applyApiError plus the per-page applyApiError copies, the generated view templates, and IntentEmissionCoverageIT. Then inspect the record overflow menu, both Issues pages and the existing /stomp endpoint, and DialogHub.showAlert with bk-message-box. Done means all four surfaces report issues with the right request or record context, Issues pages receive live updates, and the rendered alert assertions pass.

Written by the indexing model from the issue text.

Description

Follow-up of #7948, which ships the issues engine (request ids, the store on SystemDB, /services/issues/**, the lifecycle on Flowable), "Report an issue" in every shell's user menu, the Issues page beside the Inbox and the support desk in the monitoring shell.

These parts of #7948 were left out of its first PR:

1. "Report an issue" on the generated views' error surfaces

The Harmonia shells have no shared error dialog: each generated view shows a failure in its own alert (saveFailureMessage in manage/form-view and document/document-view; error, itemsError, itemError in the my-* and partner-* views, each with its own applyApiError in the page template). Every failure is already recorded with its request id in App.services.recentFailures, so the user menu's report is pre-filled. What is missing is the request id on the alert itself ("Reference: ...") and a "Report an issue" button there, which calls $store.issues.report({ requestId, entity, recordId }). The change covers:

  • baseFormPage.applyApiError and the per-page applyApiError copies, so they keep err.requestId;
  • every view template's error alert, power/my/partner, in both the form and the document branch;
  • IntentEmissionCoverageIT assertions on the rendered alert.

2. A per-record "Report an issue" action

This is the record overflow menu of the generated views, pre-filling the entity and the record id.

3. Live update of the Issues pages over STOMP

Both Issues pages re-read on open and on Refresh. An operator's reply should reach an open Issues page of the reporter, and a new issue the operator desk, over the existing /stomp endpoint.

4. The Workbench's error message box

The IDE header has the "Report an issue" entry, which opens the application shell's Issues page with the form open. DialogHub.showAlert error boxes (194 call sites) do not offer the button; adding it to the bk-message-box footer for type === 'error' changes the buttons every caller awaits, so it needs its own look.

Dominant language
Java
Stars
278
Forks
97
Avg merge
18h 53m
Merged PRs (30d)
228

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from eclipse-dirigible/dirigible

All issues in eclipse-dirigible/dirigible

Similar issues

More Java issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.