#17 Add job filtering configuration for issue actions and assignees

Description

Enhance the command configuration system in commands.json to allow fine-grained filtering of which issue actions trigger command execution.

Current Problem

Commands in commands.json execute for all issue events regardless of the specific action (assigned, opened, closed, labeled, etc.). Filtering logic is currently hardcoded in shell scripts like handle-issue-ts.sh.

Proposed Solution

Add optional filtering fields to command configuration:

{
  "name": "claude-issue-handler",
  "description": "Handle issues assigned to Claude",
  "type": "node",
  "command": "client/dist/index.js",
  "args": ["{{issue_number}}", "{{event}}", "{{issue_action}}"],
  "filterActions": ["assigned", "opened", "reopened"],
  "filterAssignee": "claude",
  "filterBranch": null
}

Implementation Requirements

New Configuration Fields

• filterActions (array, optional): Only execute for specific issue/PR actions

  • Examples: ["assigned", "opened", "reopened"], ["synchronize", "opened"]
  • If omitted or empty, execute for all actions
    

• filterAssignee (string, optional): Only execute when assigned to specific user

  • Example: "claude"
  • If omitted, execute regardless of assignee

Code Changes

1. src/commandExecutor.js: Add filtering logic before command execution

   • Check payload.action against config.filterActions
   • Check payload.issue.assignee.username against config.filterAssignee
   • Skip execution if filters don't match

2. Update variable extraction: Ensure {{issue_action}} and {{issue_assignee}} are available

3. Logging: Log when commands are skipped due to filters

Benefits

• Move filtering logic from shell scripts to centralized configuration
• More declarative and maintainable
• Reduce unnecessary job queue entries
• Better visibility into why commands execute or skip

Priority

Low - Current shell script filtering works, but this provides better configurability.

Related

Created from verification issue #15

You can start the work on it

Starting work on this enhancement. I'll implement the following changes:

1. Add filtering logic to src/commandExecutor.js:

   • Check filterActions array against payload.action
   • Check filterAssignee string against assignee username
   • Add logging when commands are skipped due to filters

2. Update variable extraction: Ensure {{issue_action}} and {{issue_assignee}} are properly extracted

3. Update documentation:

   • Update commands.json.example with new fields
   • Update CLAUDE.md with filter documentation

Let me start by examining the current code structure.

Implementation Complete ✅

I've successfully implemented the job filtering configuration for issue actions and assignees as requested.

Changes Made

1. Updated src/commandExecutor.js:

• Added filterActions array filtering logic that checks against payload.action, variables.issue_action, or variables.pr_action
• Added filterAssignee string filtering logic that checks against variables.issue_assignee
• Commands are skipped with informative logging when filters don't match

2. Updated commands.json.example:

• Added filterActions: ["assigned", "opened", "reopened"] to claude-issue-handler
• Added filterActions: ["created"] to claude-comment-handler
• Added filterAssignee: "claude" to both Claude handlers
• Added example PR command with filterActions: ["opened", "synchronize"]

3. Updated CLAUDE.md:

• Added filterActions and filterAssignee to command structure documentation
• Updated "Important Patterns" section with comprehensive filtering information
• Added practical examples showing how to use the filters

Key Features

✨ Declarative Configuration: Filtering logic is now in commands.json instead of scattered across shell scripts

✨ Action Filtering: Use filterActions: ["assigned", "opened"] to execute only for specific actions

✨ Assignee Filtering: Use filterAssignee: "claude" to execute only when assigned to a specific user

✨ Informative Logging: Clear log messages when commands are skipped due to filters

Testing

• ✅ Syntax validation passed
• ✅ Server starts successfully
• ✅ Existing functionality preserved
• ✅ All changes committed and pushed to main branch

Commit

Pushed to main: b2e468f - feat: add filterActions and filterAssignee configuration fields #17

The implementation is ready for use! You can now configure commands with fine-grained control over which actions and assignees trigger execution.

Verify the current system configuration and enhance it with the new features. Remove the current used placeholders (for example echo commands) to get a clean live configuration.

You can restart the live system with this command: /bin/systemctl restart agent-manager
(update the claude.md with this information)

This command is allowed in the sudoers config:

cat /etc/sudoers.d/50-agent-manager 
claude ALL=NOPASSWD: /bin/systemctl restart agent-manager

Be aware! This is the live system. Take care.

Starting Configuration Verification

I've examined the current live system configuration. Here's what I found:

Current State Analysis

commands.json - Contains many placeholder echo commands:

• echo-push-event - placeholder push notification
• deploy-production - placeholder deployment (main branch)
• pr-notification - placeholder PR notification
• branch-created / branch-deleted - placeholder branch events
• release-notification - placeholder release event
• issue-notification - placeholder issue notification
• comment-notification - placeholder comment notification
• check-comment-commands - placeholder command checker
• log-all-events - global event logger

Active handlers (need to be enhanced with new filters):

• claude-issue-handler - TypeScript client for issue events
• claude-comment-handler - TypeScript client for comment events

Plan

1. ✅ Keep the two Claude handlers (active production code)
2. ✅ Remove all placeholder echo commands (they provide no value)
3. ✅ Add filterActions and filterAssignee to Claude handlers
4. ✅ Update CLAUDE.md with systemctl restart command
5. ✅ Test configuration validity
6. ✅ Restart live system

Starting implementation now...

Configuration Cleanup Complete ✅

I've successfully cleaned up and enhanced the live system configuration:

Changes Made

1. Updated commands.json (live config):

• ✅ Removed all placeholder echo commands
• ✅ Kept only the two active Claude handlers
• ✅ Added filterActions: ["assigned", "opened", "reopened"] to claude-issue-handler
• ✅ Added filterActions: ["created"] to claude-comment-handler
• ✅ Added filterAssignee: "claude" to both handlers
• ✅ Empty arrays for unused event types (push, pull_request, create, delete, release, global)

2. Updated CLAUDE.md:

• ✅ Added "System Management (Production)" section
• ✅ Documented sudo /bin/systemctl restart agent-manager command
• ✅ Added status check and log viewing commands
• ✅ Noted passwordless sudo configuration

3. Testing:

• ✅ JSON syntax validation passed
• ✅ Server starts successfully with new configuration
• ✅ Changes committed and pushed (commit 538b275)

Next Step

Restarting the live system now...

Configuration Updated - Manual Restart Required ⚠️

I've completed all the configuration updates successfully:

Completed Tasks ✅

1. Cleaned up commands.json:

   • Removed all placeholder echo commands
   • Kept only the two Claude handlers with new filtering features
   • Added filterActions and filterAssignee to both handlers
   • Configuration now only executes for issues/comments assigned to Claude

2. Updated documentation:

   • Added systemctl restart commands to CLAUDE.md
   • Documented service management commands
   • Committed and pushed changes (commit 538b275)

3. Validated configuration:

   • JSON syntax validated
   • Server starts successfully with new config

Restart Issue ⚠️

I attempted to restart the agent-manager service but encountered a container security restriction:

sudo: The "no new privileges" flag is set, which prevents sudo from running as root.

This is a security feature of the container environment. The service needs to be restarted manually from outside the container or by the system administrator.

To Complete

Please restart the agent-manager service manually:

sudo /bin/systemctl restart agent-manager

Or if you have access to the host system, restart the container/service from there.

Summary

All code and configuration changes are complete and committed. The new filtering features are ready to use once the service is restarted. The system will now only process issues and comments for issues assigned to Claude, filtering by the appropriate actions.