If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/edavis10/redmine shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

AVOID — Stale and unlicensed — last commit 4y ago

• 2 active contributors
• Tests present
• ⚠ Stale — last commit 4y ago
• ⚠ Small team — 2 contributors active in recent commits
• ⚠ Concentrated ownership — top contributor handles 67% of recent commits
• ⚠ No license — legally unclear to depend on
• ⚠ No CI workflows detected

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live edavis10/redmine repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/edavis10/redmine.

What it runs against: a local clone of edavis10/redmine — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in edavis10/redmine | Confirms the artifact applies here, not a fork | | 2 | Default branch master exists | Catches branch renames | | 3 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 4 | Last commit ≤ 1520 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of edavis10/redmine. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/edavis10/redmine.git
#   cd redmine
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of edavis10/redmine and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "edavis10/redmine(\\.git)?\\b" \\
  && ok "origin remote is edavis10/redmine" \\
  || miss "origin remote is not edavis10/redmine (artifact may be from a fork)"

# 3. Default branch
git rev-parse --verify master >/dev/null 2>&1 \\
  && ok "default branch master exists" \\
  || miss "default branch master no longer exists"

# 4. Critical files exist
test -f "app/controllers/application_controller.rb" \\
  && ok "app/controllers/application_controller.rb" \\
  || miss "missing critical file: app/controllers/application_controller.rb"
test -f "app/models/user.rb" \\
  && ok "app/models/user.rb" \\
  || miss "missing critical file: app/models/user.rb"
test -f "app/models/project.rb" \\
  && ok "app/models/project.rb" \\
  || miss "missing critical file: app/models/project.rb"
test -f "app/models/issue.rb" \\
  && ok "app/models/issue.rb" \\
  || miss "missing critical file: app/models/issue.rb"
test -f "config/routes.rb" \\
  && ok "config/routes.rb" \\
  || miss "missing critical file: config/routes.rb"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 1520 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~1490d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/edavis10/redmine"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

Redmine is a flexible, self-hosted project management web application built on Ruby on Rails that enables teams to track issues, manage projects, allocate resources via Gantt charts, and collaborate through discussion boards and document repositories. It solves the problem of needing a customizable, on-premise alternative to SaaS project management tools, with deep integration of time tracking, custom fields, and role-based access control. Monolithic Rails MVC architecture: app/controllers/ contains 50+ domain-specific controllers (IssuesController, ProjectsController, TimelogController, GanttsController, etc.), each handling a distinct Redmine feature area. Models and views are organized by Rails convention under app/models/ and app/views/ (inferred). No visible separation of concerns via engines or services; everything routes through ApplicationController.

DevOps teams and system administrators who need to self-host project management infrastructure; software development teams that require fine-grained permission control and custom workflows; enterprises that cannot use cloud-based tools due to data governance requirements.

Redmine is mature and actively maintained—the codebase has existed for years with substantial Rails-era code (4.9M lines of Ruby), comprehensive feature set (calendars, gantt charts, repositories, timelog, reports), and established conventions. The presence of CI setup (GitHub PR template, rubocop/linting config), multiple controllers covering distinct domains, and ongoing commits indicates active maintenance, though it skews toward stable incremental development rather than rapid iteration.

Single-maintainer dependency risk exists (edavis10 as primary maintainer); the codebase is tightly coupled monolithic Rails (no apparent modularization visible in file structure), making large refactors risky. Rails version constraints may drift since the codebase predates modern Rails practices (evident from structure). Test coverage is not visible in the top-level file list, raising concerns about regression detection.

No specific commit recency or PR data is visible in the provided file list. However, the presence of .github/PULL_REQUEST_TEMPLATE.md and .rubocop.yml / .rubocop_todo.yml indicates active quality-control efforts and ongoing code linting work. The file structure suggests steady maintenance of existing features rather than major new feature development.

git clone https://github.com/edavis10/redmine.git
cd redmine
bundle install
rake db:create db:migrate
rails server

Then visit http://localhost:3000. (Assumes Ruby 2.4+, Bundler, and a configured database in config/database.yml.)

Daily commands:

rake db:migrate          # Set up schema
rails server             # Start development server on port 3000
rake test                # Run test suite (command inferred from Rails convention)

• app/controllers/application_controller.rb — Base controller for all request handlers; contains authentication, authorization, and core request lifecycle hooks every contributor must understand.
• app/models/user.rb — Core user model managing authentication, roles, and permissions; foundation for access control throughout the application.
• app/models/project.rb — Central domain model representing projects; manages memberships, issues, and the primary organizational unit of Redmine.
• app/models/issue.rb — Issue tracking model; the primary business entity with complex state management, relations, and workflow logic.
• config/routes.rb — Rails router configuration defining all URL endpoints and RESTful resource mappings for the web application.
• Gemfile — Bundler dependency manifest declaring all gem dependencies; critical for understanding framework version and external library constraints.
• README.rdoc — Project overview and getting-started guide; provides context on Redmine's purpose as a flexible project management web application.

Add a New RESTful Resource (e.g., Issue Status)

1. Create the Active Record model at app/models/issue_status.rb with validations and associations (app/models/issue_status.rb)
2. Generate or write a controller at app/controllers/issue_statuses_controller.rb inheriting from ApplicationController with CRUD actions (app/controllers/issue_statuses_controller.rb)
3. Add RESTful route to config/routes.rb: resources :issue_statuses (config/routes.rb)
4. Create view templates in app/views/issue_statuses/ (index, show, edit, new, etc.) (app/views/issue_statuses/index.html.erb)
5. Create or update helper at app/helpers/issue_statuses_helper.rb for view-specific formatting logic (app/helpers/issue_statuses_helper.rb)

Add Permission-Controlled Admin Feature

1. Create controller action in app/controllers/admin_controller.rb and add before_filter :require_admin (app/controllers/admin_controller.rb)
2. Define the permission string in app/models/role.rb or add_permission method if managing roles dynamically (app/models/role.rb)
3. Create view template in app/views/admin/ directory (app/views/admin/settings.html.erb)
4. Update app/controllers/application_controller.rb if custom authorization logic beyond :require_admin is needed (app/controllers/application_controller.rb)

Add Custom Field to Issue

1. Create or modify CustomField model in app/models/custom_field.rb to associate with Issue (app/models/custom_field.rb)
2. Update Issue model at app/models/issue.rb to add has_many :custom_field_values or similar association (app/models/issue.rb)
3. Add form inputs in issue edit view app/views/issues/_form.html.erb using custom_field_helpers (app/views/issues/_form.html.erb)
4. Update app/helpers/custom_fields_helper.rb to provide rendering helpers for the new field type (app/helpers/custom_fields_helper.rb)

Add Time Tracking Activity Type

1. Create Enumeration model record or add to app/models/enumeration.rb for activity type (app/models/enumeration.rb)
2. Update TimeEntry model at app/models/time_entry.rb to validate against valid enumerations (app/models/time_entry.rb)
3. Update timelog form view app/views/timelog/_form.html.erb to include the new activity in dropdown (app/views/timelog/_form.html.erb)
4. Add helper display logic in app/helpers/timelog_helper.rb if custom formatting is needed (app/helpers/timelog_helper.rb)

• Ruby on Rails — Rapid development of web applications with built-in ORM, routing, and convention-over-configuration reducing boilerplate for a feature-rich project management tool.
• Active Record — Simplifies database interaction and model definition, allowing focus on business logic rather than SQL; natural fit for Redmine's complex domain entities (Projects, Issues, Users).
• ERB Templates — Server-side HTML rendering with embedded Ruby for dynamic content; appropriate for traditional web app without complex frontend state management.
• RuboCop & Stylelint — Enforce code quality and consistency across contributors; essential for maintaining legibility in a large open-source codebase with distributed maintainers.

• Monolithic Rails app rather than microservices

  • Why: Simplicity and coherent data model; all features share single database and authentication context.
  • Consequence: Easier to understand and deploy initially, but scaling horizontally becomes harder; entire app must be deployed together.

• Server-side rendering (ERB) over JavaScript SPA

  • Why: Reduces complexity and client-side debugging; server controls all rendering and state.
  • Consequence: Full page loads for navigation; less responsive UI compared to SPA; easier for server-side integration testing.

• Role-based Access Control (RBAC) with project-level permissions

  • Why: Matches Redmine's multi-project architecture where users have different roles per project.
  • Consequence: Permission checks on every request; more complex than simple admin/user binary; enables fine-grained control but slower to evaluate.

• Real-time collaboration (no WebSocket/CRDT synchronization for simultaneous document editing)
• Mobile-first responsive design (primarily desktop web application)
• GraphQL API (uses REST/form-based interaction model only)
• Cloud-native deployment (requires persistent file storage and database; not containerized by default)

Database config required: config/database.yml must exist and point to a running MySQL/PostgreSQL instance before migrations run. Rails secrets: config/secrets.yml or environment variables may be needed for production deploys (check initializers). Plugin directory: Redmine supports plugins via plugins/ directory (not visible in top 60 but critical); ensure it exists or plugin system fails. Locale files: i18n is heavily used; missing locale files for non-English setups may cause views to render blank. SVN legacy: project originated in SVN (note .hgignore file); some Git workflows may be non-standard. Perforce-style controllers: some controllers (e.g., context_menus_controller.rb) handle AJAX responses with non-standard content negotiation; easy to break when refactoring.

• Role-Based Access Control (RBAC) — Redmine's permission model is entirely RBAC-driven (visible in Roles and Permission models); understanding how roles are assigned to members and evaluated in controllers is critical to adding features without breaking security.
• Polymorphic Associations — Redmine heavily uses polymorphic associations (e.g., Comments belong to Issues or News; Attachments belong to multiple resource types); this pattern enables flexible custom fields and reuse but is non-obvious in Rails.
• Activity/Audit Logging via Journals — Redmine tracks all changes to issues via the Journals model (visible in journals_controller.rb); understanding how updates are logged and displayed is essential for preserving history in new features.
• Custom Fields Framework — Redmine's killer feature is dynamic custom fields (visible in custom_fields_controller.rb and custom_field_enumerations_controller.rb); understanding how they're attached to Issues, Projects, and Users enables most user-facing customizations.
• Rails Engines & Plugin Architecture — Redmine supports third-party plugins via Rails Engines; understanding how to hook into controllers and models without modifying core code is essential for extending without forking.
• Eager Loading & N+1 Query Prevention — A monolithic Rails app with 50+ controllers and deep model associations (Issues → Projects → Members → Roles) is vulnerable to N+1 queries; optimizing controller queries via includes() and joins() is critical for scaling.
• Internationalization (i18n) in Rails — Redmine supports multiple languages via Rails i18n (evident from the large codebase size and view files); adding new UI strings requires understanding YAML locale files and the t() helper.

• opensourcecms/opencart — Another mature, self-hosted project management alternative (though CMS-focused); shares similar architecture challenges of monolithic Rails apps.
• jlord/git-it — Educational Rails project with similar structure; good reference for understanding Rails conventions used in Redmine.
• diaspora/diaspora — Large self-hosted Rails application with similar privacy/on-premise focus; demonstrates patterns for scaling Rails monoliths.
• activeadmin/activeadmin — Rails admin framework that Redmine-like tools use for internal admin interfaces; relevant for understanding Redmine's admin panel design.
• ruby-on-rails/rails — The foundation framework; understanding Rails internals (routing, middleware, ORM) is essential to modifying Redmine.

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add comprehensive unit tests for twofa_controller.rb and twofa_backup_codes_controller.rb

The two-factor authentication controllers (twofa_controller.rb and twofa_backup_codes_controller.rb) are security-critical components but likely lack comprehensive test coverage. As a mature project managing authentication, adding thorough tests for edge cases (invalid codes, rate limiting, backup code consumption, session handling) would improve security posture and reduce regressions during refactoring.

• [ ] Create test/functional/twofa_controller_test.rb with tests for code generation, validation, activation/deactivation flows
• [ ] Create test/functional/twofa_backup_codes_controller_test.rb with tests for backup code generation, consumption, and edge cases
• [ ] Add integration tests in test/integration/ for complete 2FA workflows (enable → authenticate → disable)
• [ ] Verify test coverage reaches >90% for both controllers using SimpleCov

Add GitHub Actions workflow for Ruby linting and style checks

The repo contains .rubocop.yml and .rubocop_todo.yml configuration files, indicating RuboCop is used for style enforcement, but there is no CI workflow file in .github/workflows/. Adding automated linting checks on PRs would catch style violations early and reduce manual review burden, especially given the large number of controllers and helpers that need consistent styling.

• [ ] Create .github/workflows/rubocop.yml that runs 'bundle exec rubocop' on pull requests
• [ ] Configure the workflow to fail on violations and report results inline on PR diffs
• [ ] Add a separate job to check .stylelintrc compliance for any frontend assets
• [ ] Document the new workflow in CONTRIBUTING.md with instructions for running RuboCop locally

Refactor mail_handler_controller.rb into a service object and add missing unit tests

The mail_handler_controller.rb is likely a large controller that processes incoming emails to create issues/updates. This is complex business logic that's better suited to a service object (following Rails conventions visible in the codebase). Extracting it and adding comprehensive tests would improve maintainability, reusability, and testability of a critical feature that integrates with external email systems.

• [ ] Create app/services/mail_handler_service.rb to extract email parsing and issue creation logic from mail_handler_controller.rb
• [ ] Create test/unit/mail_handler_service_test.rb with tests for: valid email parsing, attachment handling, custom field mapping, user/project detection, error cases
• [ ] Update mail_handler_controller.rb to delegate to MailHandlerService and add controller-level tests
• [ ] Document the service's public API in a code comment or add to doc/ directory for extension developers

• Add test coverage for app/controllers/custom_fields_controller.rb: No test file is visible in the top-level list; write Rails controller tests for CRUD actions, validation errors, and permission checks. This stabilizes the custom field system and reduces regression risk.
• Document the issue workflow in README.rdoc: The README is minimal; add a section explaining how to create, transition, and close issues (linking to relevant controllers like IssuesController). Helps new users and contributors understand the core domain model.
• Extract permission constants to a shared module: Permission logic is scattered across controllers (e.g., authorized_to? checks in application_controller.rb). Centralize permission definitions to reduce duplication and improve maintainability.

• High · Missing Dependency Information — Gemfile. The Gemfile is present but its content was not provided for analysis. Ruby on Rails applications are highly dependent on third-party gems, which may contain known vulnerabilities. Without analyzing the Gemfile and Gemfile.lock, it's impossible to verify if outdated or vulnerable gems are being used. Fix: Provide Gemfile content and run 'bundle audit' regularly to check for known vulnerabilities in dependencies. Implement automated dependency scanning in CI/CD pipeline.
• High · Potential Injection Vulnerabilities in Controllers — app/controllers/ (especially search_controller.rb, issues_controller.rb, timelog_controller.rb). Multiple controllers are present (issues_controller.rb, search_controller.rb, mail_handler_controller.rb, etc.) that typically handle user input. Without code inspection, common injection vectors like SQL injection and NoSQL injection in complex queries cannot be ruled out. Rails provides protections but misuse of raw queries is possible. Fix: Ensure all database queries use parameterized queries or Rails ORM methods. Audit any raw SQL queries with find_by_sql(), execute(), or connection.exec. Use Rails' query interfaces (ActiveRecord) exclusively.
• High · XSS Prevention in View Rendering — app/helpers/ (entire directory). The presence of many helpers (activities_helper.rb, issues_helper.rb, etc.) suggests dynamic HTML rendering. Without analyzing helper implementations, potential XSS vulnerabilities through inadequate output encoding cannot be verified. Fix: Ensure all user-controlled content rendered in views uses Rails' html_escape or the <%= %> syntax (which auto-escapes by default). Audit any use of raw(), html_safe, or with_html methods. Enable content security policy (CSP) headers.
• High · Authentication/Authorization Bypass Risks — app/controllers/application_controller.rb, app/controllers/admin_controller.rb, app/controllers/users_controller.rb. Controllers like admin_controller.rb, users_controller.rb, and twofa_controller.rb handle sensitive operations. The presence of twofa_controller.rb suggests two-factor authentication exists, but without reviewing application_controller.rb base security, authorization issues cannot be ruled out. Fix: Verify all sensitive controller actions have proper before_action filters for authentication and authorization. Use role-based access control (RBAC). Review all skip_before_action declarations. Implement principle of least privilege.
• Medium · File Upload Security Concerns — app/controllers/attachments_controller.rb, app/controllers/files_controller.rb. The presence of attachments_controller.rb and files_controller.rb indicates file upload functionality. Without code review, potential issues like unrestricted file uploads, path traversal, or execution of uploaded files cannot be verified. Fix: Implement strict file type validation (whitelist approach). Store uploads outside web root. Disable execution permissions on upload directories. Implement file size limits. Use virus scanning for uploaded files. Validate MIME types server-side.
• Medium · Email Handling and SSRF Risks — app/controllers/mail_handler_controller.rb, app/controllers/email_addresses_controller.rb. The mail_handler_controller.rb and email_addresses_controller.rb suggest email processing functionality. Potential risks include email injection, SSRF attacks through email headers, or processing of untrusted email content. Fix: Sanitize all email headers and body content. Validate email addresses strictly. Implement DKIM/SPF/DMARC verification. Avoid using user-controlled data in email headers. Be cautious with email content rendering.
• Medium · API Security for Auto-Complete Feature — app/controllers/auto_completes_controller.rb. auto_completes_controller.rb likely exposes API endpoints that could leak sensitive information or be vulnerable to enumeration attacks if not properly secured. Fix: Implement rate limiting on auto-complete endpoints. Ensure proper authorization checks before returning search results. Avoid exposing sensitive data in auto-complete results. Implement CSRF protection.
• Medium · Wiki/Content Handling XSS — undefined. wiki_controller.rb and wikis_controller.rb indicate wiki functionality which often involves rich text editing. Improper sanitization of wiki content can lead to stored Fix: undefined

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.