Weave Code
Filament Jira Feedback Laravel Package
zynqa/filament-jira-feedback
A Filament plugin for collecting user feedback inside your admin panel and turning it into Jira issues. Let users submit bug reports and feature requests with context, then sync them to Jira for triage and tracking.
At a glance
Frequently asked questions about Filament Jira Feedback
- How do I install zynqa/filament-jira-feedback in my Laravel app?
- Install the package with Composer, publish its configuration, and then register the plugin in the relevant Filament PanelProvider. After that you supply your Jira credentials and project settings in the published config. No database migration is required because Jira remains the system of record for issues. Because the release notes are terse, run a smoke test that creates a real issue before rolling out.
- Which Laravel, Filament, and PHP versions does this plugin support?
- The exact version constraints are not confirmed in the available documentation, so treat them as unverified until you check the package's composer.json. Pin the plugin, Filament, Laravel, and PHP versions explicitly in your CI pipeline. Filament version coupling is one of the main technical risks with this package, so test any Filament upgrade against it. Validate in a non-production environment before bumping dependencies.
- Does it work with Jira Cloud, Jira Server, or Jira Data Center?
- The supported Jira deployment types are not confirmed in the release notes or documentation. The plugin talks directly to the Jira API, so compatibility depends on the API version your instance exposes. Verify against your team's actual Jira API version and authentication model in a test project first. If you run Jira Server or Data Center, confirm endpoint and auth compatibility before depending on it.
- What Jira credentials and permissions are required?
- You configure Jira credentials and project settings after publishing the package config, but the exact auth method is not documented in detail. Follow least-privilege practice and use credentials that can create issues in the target project and nothing more. Avoid personal admin tokens; prefer a dedicated service account so rotation is straightforward. Include credential rotation in your internal runbook, since credential handling is a key operational risk here.
- Can I target multiple Jira projects or issue types, such as bugs versus feature requests?
- The plugin maps feedback fields to a target Jira issue type, and project and issue-type settings live in the published configuration. Whether you can switch projects or issue types per submission is not clearly documented, so test the scenarios you need. If you require separate bug and feature-request workflows, map each to its own issue type and confirm validation matches Jira's field schema. Aligning required fields with Jira's schema up front avoids failed submissions later.
- Can users attach screenshots or files to their feedback?
- Attachment and screenshot support is not documented in the available information, so assume it is unconfirmed until you verify it. If file uploads are a hard requirement, test the submission path with an attachment in a non-production Jira project before committing. Many lightweight feedback bridges only post text fields, with the Jira issue as the place for follow-up context. Plan a fallback, such as asking reporters to attach files directly in Jira, if uploads are unsupported.
- Are feedback submissions queued or retried if the Jira API fails?
- The plugin appears to call the Jira API directly from the submission flow, and queuing or retry behavior is not confirmed. That means Jira latency, rate limits, and transient API errors can affect the reporter's experience during bursts. If reliability matters, wrap or extend the submission path so failures are logged and retried, or check whether the config exposes a queue option. Feedback volume is typically low, so direct submission is often acceptable for internal admin panels.
- How are Jira API errors and validation failures shown to the user?
- Error surfacing is not documented, so you should explicitly test both validation failures and API failures before rollout. Confirm what the reporter sees when credentials are wrong, a required Jira field is missing, or the API times out. A silent failure on the report-issue path is the worst outcome, since users assume the report was filed. Add logging around submissions so your team catches failures even if the UI message is unhelpful.
- How should I test and roll out this plugin safely in production?
- Start by confirming the Jira project, issue type, required fields, and least-privilege credentials. Install in a non-production Laravel and Filament environment, then smoke-test successful issue creation alongside validation and API failure cases. Promote to staging and run UAT with real reporter roles, gating access through Filament permissions or a policy. After rollout, monitor Jira issue creation and application error logs so regressions are caught quickly.
- Is the package actively maintained, and how does it compare to a helpdesk or feedback platform?
- Release 1.1.6 fixes a regression where users could not report issues, which is a positive maintenance signal but also proof that the submission path can break. Community support is via GitHub with no SLA, so own your dependency updates and keep an internal regression test for feedback submission. This is a narrow UI-to-Jira bridge, not a general-purpose helpdesk or feedback platform. It is a strong fit if you already run Filament and Jira, and a poor fit if you would have to adopt Filament just for feedback capture.
Weaver
How can I help you explore Laravel packages today?