#!/bin/bash
# Check PR status and CI checks
gh pr view 5315 --json statusCheckRollup --jq '.statusCheckRollup[] | select(.conclusion != "SUCCESS") | {name: .name, conclusion: .conclusion, detailsUrl: .detailsUrl}'

#!/bin/bash
# Read the failing test file
cat website/tests/test_security_incident_views.py

#!/bin/bash
# Check the views implementation
cat website/views.py | head -200

#!/bin/bash
# Check if there are any SecurityIncident related views
rg -n "class.*SecurityIncident.*View" website/views.py -A 20

#!/bin/bash
# Check models to understand the SecurityIncident structure
rg -n "class SecurityIncident" website/models.py -A 50

#!/bin/bash
# Check for any migration files related to SecurityIncident
fd -e py . website/migrations/ | xargs rg -l "SecurityIncident" | sort

#!/bin/bash
# Get the actual test failure logs from CI
gh run view 58121089153 --log | grep -A 50 "FAILED\|ERROR\|Traceback"

#!/bin/bash
# Find where views might be located
fd -e py views website/

#!/bin/bash
# Check URLs configuration for security incident routes
rg -n "security_dashboard|security_incident" website/ -g "*.py" | head -30

#!/bin/bash
# Check if there's a security app or module
fd -t d security website/

#!/bin/bash
# Look for view implementations in any Python files
rg -n "SecurityDashboardView|SecurityIncidentCreateView|SecurityIncidentDetailView|SecurityIncidentUpdateView" website/ -g "*.py"

#!/bin/bash
# Check the URLs file
cat website/urls.py | grep -A 5 -B 5 "security" || echo "No security routes found"

#!/bin/bash
# Read the security incident views
cat website/views/security_incidents.py

#!/bin/bash
# Read the security dashboard view
cat website/views/security.py

#!/bin/bash
# Find URLs configuration file
fd urls.py | head -10

#!/bin/bash
# Check if URLs are configured in the main BLT directory
cat blt/urls.py | grep -A 10 -B 2 "security"

#!/bin/bash
# Run the tests locally to see the actual error
cd /tmp && python -m pytest website/tests/test_security_incident_views.py -v 2>&1 | head -100

#!/bin/bash
# Try to get the CI logs from the workflow run
gh run view 20244535220 --log-failed 2>&1 | grep -A 30 "test_security_incident" | head -100

#!/bin/bash
# Check what tests are configured to run
cat .github/workflows/*.yml | grep -A 10 "test" | head -50

#!/bin/bash
# Try running django tests properly from the repo root
python manage.py test website.tests.test_security_incident_views --settings=blt.settings 2>&1 | head -150

#!/bin/bash
# Check if there's a pytest or test configuration
cat pytest.ini 2>/dev/null || cat setup.cfg 2>/dev/null | grep -A 10 pytest || echo "No pytest config found"

#!/bin/bash
# Let's check the actual test runner command from GitHub Actions
rg -n "python.*test|pytest|manage.py test" .github/workflows/ -A 2 -B 2

#!/bin/bash
# Get the actual failing test output by checking the workflow log URL
gh run view 20244535220 --log 2>&1 | grep -i "FAIL\|ERROR" -A 10 -B 2 | head -200

#!/bin/bash
# Check the SecurityIncident model's TextChoices values
rg -n "class Severity|class Status" website/models.py -A 5 | grep -A 5 "SecurityIncident" | head -20

#!/bin/bash
# Check what values are used in the test filters
rg -n '"CRITICAL"|"RESOLVED"|"HIGH"' website/tests/test_security_incident_views.py

#!/bin/bash
# Check if there are any other test files that might give us hints
ls -la website/tests/ | grep security

#!/bin/bash
# Check the form to see if it does any case normalization
cat website/security_incident_form.py 2>/dev/null || rg -n "class SecurityIncidentForm" website/ -A 30

#!/bin/bash
# Get more details from the CI run
gh run view 20244535220 --log 2>&1 | grep -B 5 -A 15 "test_dashboard_filter" | head -100

#!/bin/bash
# Check the actual severity and status choice values in the model
rg -n "LOW =|MEDIUM =|HIGH =|CRITICAL =|OPEN =|INVESTIGATING =|RESOLVED =" website/models.py | grep -A 1 -B 1 "SecurityIncident"

#!/bin/bash
# Look at how the model choices work
cat website/models.py | sed -n '3577,3600p'

#!/bin/bash
# Check if there are any passing tests that use filters correctly
rg -n "severity.*:|status.*:" website/tests/test_security_incident_api.py -B 2 -A 2

#!/bin/bash
# Download and check the full CI log for actual test failures
gh run view 20244535220 --log 2>&1 | grep -E "(FAIL|ERROR|AssertionError|test_.*security)" | head -50

#!/bin/bash
# Get the full test failure output
gh run view 20244535220 --log 2>&1 | grep -A 30 "test_dashboard_filter_by_severity\|test_dashboard_filter_by_status\|FAILED.*test_security" | head -150

#!/bin/bash
# Look for the actual FAILED test names
gh run view 20244535220 --log 2>&1 | grep "FAILED.*test_" | head -30

#!/bin/bash
# Check what's in the full run logs around the security tests
gh run view 20244535220 --log 2>&1 | sed -n '/test_dashboard_accessible_by_staff/,/test_dashboard_filter_by_status/p' | head -80

#!/bin/bash
# Simple check: what are the actual values being used?
echo "Model defines:"
grep -A 2 "class Severity\|class Status" website/models.py | grep "="
echo ""
echo "Tests use:"
grep "severity.*=\|status.*=" website/tests/test_security_incident_views.py | head -20

#!/bin/bash
# Let's download the actual test output to a file and examine it
gh run view 20244535220 --log > /tmp/ci_log.txt 2>&1
grep -n "test_.*security.*\|FAIL\|AssertionError" /tmp/ci_log.txt | grep -A 5 "test_dashboard_filter\|test_create_incident" | head -100

#!/bin/bash
# Check the comparison between what's expected vs actual
echo "=== Issue Found ==="
echo "Model stores lowercase values:"
echo "  CRITICAL = 'critical'"
echo "  HIGH = 'high'"
echo "  RESOLVED = 'resolved'"
echo ""
echo "But test filters use uppercase strings:"
grep '{"severity":\|{"status":' website/tests/test_security_incident_views.py
echo ""
echo "The SecurityIncident enum values are lowercase, so filters should use lowercase or enum constants"

#!/bin/bash
# Let's check if the view actually case-normalizes the filter parameters
grep -A 10 "def apply_filters" website/views/security.py | head -20

#!/bin/bash
# Check the entire test to understand what it expects
cat website/tests/test_security_incident_views.py | sed -n '62,67p'

#!/bin/bash
# Get the full error for the failing test
grep -A 20 "test_detail_view_shows_history.*failed:" /tmp/ci_log.txt | head -30

#!/bin/bash
# Check all FAILED tests in the security incident test file
grep "FAILED\|ERROR" /tmp/ci_log.txt | grep "test_security_incident_views" | head -20

#!/bin/bash
# Get the assertion error details
grep -B 5 -A 15 "AssertionError" /tmp/ci_log.txt | grep -A 15 "test_detail_view_shows_history\|test_dashboard_filter" | head -60

#!/bin/bash
# Check the specific line that's failing
sed -n '225,235p' website/tests/test_security_incident_views.py

#!/bin/bash
# Search for the template with the syntax error
rg -n "history_entries.*slice.*first.*changed_at" website/templates/

#!/bin/bash
# Look for template files related to security incidents
fd -e html . website/templates/security/

#!/bin/bash
# Check the template that's causing the error
cat website/templates/security/incidents/incident_detail.html 2>/dev/null || echo "Template not found"

#!/bin/bash
# Get a summary of all test failures
grep -E "failed:|ERROR" /tmp/ci_log.txt | grep -i "security_incident" | head -30

#!/bin/bash
# Check if the serializers validate to lowercase
cat website/serializers.py | grep -A 10 "validate_severity\|validate_status"

#!/bin/bash
# Check the problematic line in the template
sed -n '70,72p' website/templates/security/incidents/history_list.html

#!/bin/bash
# Let's create a comprehensive summary of the issues found
cat << 'EOF'
========================================
ISSUES IDENTIFIED IN test_security_incident_views.py
========================================

1. TEMPLATE SYNTAX ERROR (Critical - Causing test_detail_view_shows_history to fail)
   Location: website/templates/security/incidents/history_list.html:71
   Error: {{ history_entries|slice:"0:1"|first.changed_at|date:"M j" }}
   Problem: Invalid Django template syntax - cannot chain .changed_at after |first
   
2. FILTER CASE MISMATCH (Likely causing test_dashboard_filter_by_* to fail locally)
   Location: website/tests/test_security_incident_views.py
   Problem: Tests use uppercase filter values (e.g., "CRITICAL", "RESOLVED")
           Model stores lowercase values (e.g., "critical", "resolved")
           View doesn't normalize GET parameters to lowercase
   
   Lines affected:
   - Line 63: {"severity": "CRITICAL"} should be {"severity": "critical"}
   - Line 71: {"status": "RESOLVED"} should be {"status": "resolved"}

3. TEST DATA SEVERITY/STATUS VALUES
   Tests create instances with enum constants (correct):
   - SecurityIncident.Severity.CRITICAL resolves to "critical"
   - SecurityIncident.Status.RESOLVED resolves to "resolved"
   But filter by uppercase strings (incorrect)

========================================
EOF

#!/bin/bash
# Check the exact template error line
cat website/templates/security/incidents/history_list.html | sed -n '65,75p'

#!/bin/bash
# Check if the template syntax error is fixed
echo "=== Checking history_list.html line 71 ==="
sed -n '68,74p' website/templates/security/incidents/history_list.html

echo -e "\n=== Checking test_security_incident_views.py filter values ==="
# Check lines around 63 and 71 for filter parameters
sed -n '60,75p' website/tests/test_security_incident_views.py

echo -e "\n=== Checking for Vulnerability model implementation ==="
rg -n "class Vulnerability" website/models.py -A 10

echo -e "\n=== Checking for Vulnerability tests ==="
fd -e py test_.*vulnerability website/tests/

echo -e "\n=== Checking for custom template filter tests ==="
rg -n "def.*humanize_field_name|@register.filter" website/ -g "*.py" | head -20

echo -e "\n=== Checking template filter implementation ==="
fd templatetags website/ -t d

echo -e "\n=== List all test files in website/tests/ ==="
ls -la website/tests/ | grep "test_security"

echo -e "\n=== Check SecurityIncidentHistory tests ==="
rg -n "SecurityIncidentHistory" website/tests/test_security_incident_models.py -C 2 | head -30

echo -e "\n=== Check if Related Security Issues section is tested ==="
rg -n "related.*issue|label.*4|security.*issue" website/tests/test_security_incident_views.py -i | head -20

#!/bin/bash
# Check for humanize_field_name filter
echo "=== Checking for humanize_field_name filter ==="
rg -n "def humanize_field_name" website/templatetags/ -A 5

echo -e "\n=== Checking dashboard template for Related Security Issues section ==="
rg -n "related.*issue|label.*security|security.*label" website/templates/security/ -i | head -30

echo -e "\n=== Check security dashboard view for related issues query ==="
rg -n "label.*4|related.*issue" website/views/security.py -i -C 3

echo -e "\n=== Check if Issue model has label field ==="
rg -n "class Issue" website/models.py -A 20 | grep -i "label" | head -10

echo -e "\n=== Verify Vulnerability model was mentioned in #5113 but not implemented ==="
rg -n "Vulnerability" website/models.py | head -5

echo -e "\n=== Check all custom filters in custom_filters.py ==="
cat website/templatetags/custom_filters.py | grep -A 3 "def "

echo -e "\n=== Check if dashboard context includes related issues ==="
rg -n "related_issues|security.*issue" website/views/security.py -C 2

#!/bin/bash
# Check if chart data (severity/status breakdown) is tested
echo "=== Check if tests verify severity_breakdown and status_breakdown context ==="
rg -n "severity_breakdown|status_breakdown" website/tests/test_security_incident_views.py -C 2

echo -e "\n=== Check security.py view for chart data ==="
rg -n "severity_breakdown|status_breakdown" website/views/security.py -C 3

echo -e "\n=== Check if dashboard template uses chart data ==="
rg -n "severity_breakdown|status_breakdown" website/templates/security/dashboard.html | head -10

echo -e "\n=== Verify test coverage for context variables ==="
rg -n "assertIn.*context|context\[" website/tests/test_security_incident_views.py | head -20

echo -e "\n=== Check if related security issues are in context assertions ==="
rg -n "security_issues" website/tests/test_security_incident_views.py

#!/bin/bash
# Read the current perform_update implementation in the API viewset
echo "=== Current perform_update implementation ==="
rg -n "class SecurityIncidentViewSet" website/api/views.py -A 60 | grep -A 15 "perform_update"

echo -e "\n=== Check the form-based view's form_valid method ==="
rg -n "def form_valid" website/views/security_incidents.py -A 30

echo -e "\n=== Check SecurityIncidentHistory model structure ==="
rg -n "class SecurityIncidentHistory" website/models.py -A 20

echo -e "\n=== Check how history entries are created ==="
rg -n "SecurityIncidentHistory.objects.create" website/views/ -B 2 -A 5