Fix: Jira dashboard config params not reaching notifier

[dc-larsen]

Summary

Fixes two bugs preventing Jira settings configured in the Socket dashboard from being used by the Jira notifier:

• Parameter name mismatch: Dashboard API returns jiraUrl (normalized to jira_url), but notifications.yaml defined the param as name: server. The manager looks up params by name, so jira_url was never found.
• Priority bug in param resolution: The code would set val from app_config, then overwrite it with p_default if the env var wasn't set, despite the comment saying app_config should have highest priority.

Customer Impact

A customer reported that Jira integration configured via the dashboard wasn't working. Logs showed:

Loaded notifier: jira - enabled via app_config:jira_url
JiraNotifier: exception searching for existing issue: Invalid URL '/rest/api/3/search/jql': No scheme supplied.

The notifier was enabled (because the manager saw jira_url in app_config), but the actual URL value wasn't passed through.

Changes

• notifications.yaml: Renamed Jira params from server/project to jira_url/jira_project to match dashboard config keys
• manager.py: Fixed param resolution order (default → env var → app_config, with app_config having highest priority)
• jira_notifier.py: Updated to look for the correct param names with fallback to auth dict for backwards compatibility

Test plan

• Created test script to reproduce the bug (Jira URL from app_config not reaching notifier)
• Verified fix locally - all four Jira params (jira_url, jira_project, jira_email, jira_api_token) now resolve correctly from simulated dashboard config
• Manual test with actual dashboard configuration

🤖 Generated with Claude Code

[dc-larsen]

Manual Testing Completed

Tested the fix locally against a real Jira instance with dashboard-configured credentials.

Setup

• Test repo: dc-larsen/socket-basics-test
• Org: david-s-github (enterprise plan)
• Jira config set in Socket dashboard (not env vars)

Before Fix (v1.0.26)

Loaded notifier: jira - enabled via app_config:jira_url
JiraNotifier: exception searching for existing issue: Invalid URL '/rest/api/3/search/jql': No scheme supplied.
JiraNotifier: exception creating main issue: Invalid URL '/rest/api/3/issue': No scheme supplied.

After Fix (this branch)

Mapped API key 'jiraUrl' -> 'jira_url' = https://socket-team-gxcexsgc.atlassian.net/
Mapped API key 'jiraProject' -> 'jira_project' = KAN
Mapped API key 'jiraEmail' -> 'jira_email' = david@socket.dev
Mapped API key 'jiraApiToken' -> 'jira_api_token' = [redacted]
...
JiraNotifier: searching with JQL: project = "KAN" AND summary ~ "Socket Security Results..."
https://socket-team-gxcexsgc.atlassian.net:443 "POST //rest/api/3/search/jql HTTP/1.1" 200 None
JiraNotifier: created main issue KAN-4
JiraNotifier: added comment to issue KAN-4 for Trivy Container Results: Dockerfile

Result

Jira issue KAN-4 created successfully with the Trivy scan results attached as a comment.

The fix correctly resolves the parameter name mismatch and priority bug described in the PR.

[lelia]

Conditionally approved, pending your thoughts on whether we should add in those additional safeguards first - you'd know better than me what the typical customer use cases are. I also modified the PR branch to include a few things that helped me verify the changes, in absence of access to a real JIRA instance:

• config wiring script to verify the dashboard config without making API calls
• unit tests to cover new notifier functionality (you can run these with ./venv/bin/python -m pytest and they should not rely on any external services).

[dc-larsen]

Thanks for the review and the tests.

Comments 1 & 2 (backwards compat for server, project, email, api_token): We don't need fallbacks. The old names never worked from the dashboard. normalize_api_config has always mapped jiraUrl → jira_url (config.py:927-928), so no customer could have relied on the old yaml param names. CI users set env vars like INPUT_JIRA_URL, which resolve via the env_variable field regardless of param name. For email/api_token, the auth dict fallback already covers the one real path (the enrichment block at manager.py:247-252).

Comment 3 (empty env var guard): Agreed. Pushed 35a5e75 with the str(ev).strip() != "" guard on the env var check. An accidental INPUT_JIRA_URL="" in CI would have silently overwritten valid config with an empty string.