Filament Jira Feedback Laravel Package

Getting Started

• Install via Composer: composer require zynqa/filament-jira-feedback
• Publish the config file: php artisan vendor:publish --tag="filament-jira-feedback-config"
• Set Jira credentials in .env: JIRA_URL, JIRA_USERNAME, JIRA_API_TOKEN, JIRA_PROJECT_KEY (and optionally JIRA_ISSUE_TYPE)
• Register the plugin in your Filament panel provider:

  ->plugin(\Zynqa\FilamentJiraFeedback\FilamentJiraFeedbackPlugin::make())
  

• First use case: add a “Report issue” action to your Filament admin panel so authenticated users can create Jira issues with contextual information (current URL, user, browser) directly from the UI.
• Ensure you are on >=1.1.6 – that release fixes an issue where users could not report issues with the portal.

Implementation Patterns

• Global vs. per-panel registration – register the plugin in AdminPanelProvider for all admin users, or conditionally in specific panel providers (e.g., only for internal staff).
• Built-in topbar button – the plugin typically exposes a Filament action or topbar button; you can enable/disable it via config or plugin methods.
• Context auto-capture – issues usually include the current page URL, authenticated user ID, and user agent. Use this to speed up triage in Jira.
• Config-driven field mapping – map Filament form fields to Jira fields (summary, description, issue type, labels, components) in config/filament-jira-feedback.php. Keep environment-specific values (project key, issue type) in .env.
• Workflow integration – create a dedicated Jira project or use Jira automation to label, assign, and route portal feedback separately from internal engineering issues.
• Custom actions – you can add a Filament action to any resource or page that calls the package’s issue-creation service, rather than relying solely on the global button.
• Authorization – restrict who can submit feedback using Filament’s visible() / authorize() callbacks to avoid spam or accidental issue creation.

Gotchas and Tips

• Jira API token scopes – the token must have permission to create issues in the target project. A 401/403 in the modal usually means missing scopes or wrong project permissions.
• Project key vs. issue type – JIRA_PROJECT_KEY is required; issue type can be a name (e.g. Bug) or ID. If issue creation fails, verify the issue type exists and is allowed in that project.
• Config caching – after changing .env or config, run php artisan config:clear (and config:cache in production). Stale config is a common source of “it worked locally” bugs.
• SSL / self-hosted Jira – if your Jira instance uses a self-signed certificate, you may need to configure Guzzle options or set JIRA_VERIFY_SSL=false (not recommended in production).
• Debugging failed submissions – check storage/logs/laravel.log; the package typically logs the Jira API response. You can also test credentials directly with curl against /rest/api/3/issue.
• Upgrade note – 1.1.6 fixes the “users cannot report issues with the portal” bug (ZCP-85). No breaking changes are noted between 1.1.3 and 1.1.6, so upgrading is safe.
• Extension points – publish views (--tag="filament-jira-feedback-views") to customise the modal, or extend the plugin class to override the issue payload. Use Laravel events/listeners if you need to enrich the Jira description with application-specific data.