Redmine customization and plugin development

Most Redmine customization is configuration, not code. An administrator can shape how work is recorded and moved through a project by using the built-in screens for trackers, custom fields, workflows and roles. This approach should be the first option for any request, because settings made in the administration area survive ordinary Redmine upgrades without a rebuild, while plugin code has to be reviewed and retested against each new release. Before a team asks for a plugin, it should confirm that the requirement cannot be met through these screens. Trackers are the starting point. A tracker defines a type of issue, such as defect, feature or support request, and it decides which custom fields appear on those issues. Custom fields can be attached to trackers, to projects, or to both, and each field can be set as required, visible to certain users, or editable only by certain roles. A custom field that is enabled for a tracker but not for a project will not appear in that project, so teams should check both sides of the link when a field seems to be missing. Workflows control which status changes are allowed. In Redmine, a workflow is defined for each combination of role and tracker, and it lists the transitions a user holding that role may make from one status to another on that tracker. Field permissions in the same screen decide which fields are read-only, editable or required at each stage. Roles also control visibility through the permissions set for each role, including which projects a user can see and which actions they can take. A reader should review the workflow matrix for every role and tracker in scope, since a gap there is the most common reason users report that they cannot close an issue. A simple decision approach helps keep requests in configuration. If the change uses existing trackers, statuses, fields and roles, it belongs in configuration. If it needs new data behavior, such as a calculation, an external lookup, a new screen, or a notification rule that the core cannot express, it may need a plugin. Ask the team to write the request as a rule, then test whether each rule can be expressed with the built-in settings or a configured existing plugin. Any request that needs a plugin should get a written note on who will maintain it after each upgrade. Whatever the approach, the client should record every configuration change, including the tracker names, custom field definitions, workflow matrix, role permissions and the project links. A simple change log with the date, the person, the reason and the exported setting is usually enough. Redmine stores these settings in its database, so a new installation built from the same record can be brought to the same state without relying on memory. Confirm with your Redmine version which settings can be exported, and keep the export with the backups for the database and uploaded files.

The most important property of a Redmine plugin is that it keeps working after the core moves forward. A plugin survives upgrades when it uses the extension points Redmine exposes and avoids changing core code. Redmine plugins live in the plugins directory, each with its own init.rb that registers the plugin with the application, declares its version and requirements, and attaches behavior. Typical hooks include view hooks that inject content into existing pages, the menu and permission declarations that add navigation and roles, and callbacks on models that let the plugin react to saved issues or time entries. Each of these is a deliberate contract with the core. Plugins that instead patch core controllers, edit files under app or lib, or call private methods are relying on implementation details that Redmine is free to change, so they tend to break without warning when a new minor or major line arrives.

The upgrade path makes this risk concrete. The Redmine upgrade guide has administrators back up the database and uploaded files, copy configuration, uploads and third-party plugins into the new installation, then run the database migrations and the plugin migration task before clearing the cache and restarting. Copying a plugin is not the same as confirming it works. Each plugin must be exercised against each target Redmine release, and the Ruby and Rails versions that release requires. For Redmine 7.0, which runs on Rails 8.1, the supported Ruby versions are 3.2, 3.3, 3.4 and 4.0, and JRuby is not supported. Confirm the exact Ruby build your installation uses before you plan a test matrix, because a plugin that works on one Ruby version may fail on another if it depends on a gem with native extensions.

Version testing is where most upgrade failures are caught. Build a staging copy from a recent production backup, install the candidate Redmine release and each plugin at the version you intend to run, run the plugin migration task, and then test the workflows your users depend on: creating and editing issues with custom fields, running reports, triggering plugin hooks and reviewing permission behavior for each role. Automated tests in the plugin's test directory help, but they rarely cover the views and permissions of a real installation, so include manual checks for them. Record which Redmine, Rails and Ruby versions each plugin release was tested against. Ask any plugin author, internal or external, to pin dependencies and state compatibility in the plugin's README or changelog, and treat an unpinned gem or an undocumented version range as a risk to be planned for rather than assumed away.

Ownership after handover decides whether the plugin will still work two upgrades from now. Settle, in writing, who maintains the source repository, who holds the release process, who runs compatibility testing for each new Redmine line, and who fixes a breakage found in production. A plugin built for one organization is usually owned by that organization's platform team after handover, which means the team needs the source, the test suite, the staging procedure and the compatibility record, not only a deployed copy. Confirm whether the plugin carries a license that permits your internal changes, and whether any third-party code it bundles needs to be tracked. If the original builder will not maintain it, schedule the first upgrade test before the next Redmine release is announced, so the team learns the plugin's failure modes while the old version still runs.

Practical decisions follow from these points. Before building, list every core behavior the customization needs and check whether an extension point already provides it. Where none exists, weigh a small, isolated override against a feature request to the upstream project or a different design, and document the trade-off. Keep the plugin's version constraints visible, record the Redmine line it was tested against, and make the upgrade test a standing step in your change process rather than a one-time event. Scope the upgrade work and any retainer for later Redmine releases in the written scope, so the cost of keeping plugins compatible is visible before the first upgrade.

Customization work on Redmine moves at the pace of the inputs your team delivers. Before any custom field, tracker, workflow or plugin is designed, your side needs to provide eight items, and each one has a named owner. Missing items do not usually stop the work outright. They push design decisions into later phases, force rework once real data shows up, and extend the timeline in ways that are hard to predict at the start. The sections below describe what each item is, who should own it on your side, and what goes wrong when it is absent.

The first two items protect the work. The first is a staging or test Redmine that mirrors production: same Redmine line, same database engine and version, same installed plugins and a copy of production data, sanitized where personal data requires it. Owner: the platform or IT operations lead. Without it, customizations are tested against an empty or unlike system, and plugin conflicts appear only after go-live. The second is a database and file backup to restore from, covering both the database and the uploaded attachments. Owner: the backup or infrastructure team. Redmine's own upgrade guide treats these two backups as the starting point of any change, so ask your team to confirm that a restore has been tested, not just that backups run.

The next three items control access and scope. Administrator access must be granted to the people doing the work, under an agreed change process that states who approves a change to production, how it is scheduled and how it is rolled back. Owner: the Redmine application owner, with the change manager signing off. Each tracker and workflow also needs a named business owner who decides field meaning, status transitions and role permissions. Owner: the department lead for each project area. Requirements should be written as process steps with the roles involved, for example who creates an issue, who triages it, who may move it to closed. Owner: the business analyst or project lead. Vague requirements such as "better approval handling" are the most common reason design cycles repeat.

The remaining three items define what is being changed. Provide a list of current plugins with versions and sources, including whether each one was downloaded from the Redmine plugin directory, a vendor or an internal team. Owner: the Redmine administrator. This list determines which plugins must be reviewed for compatibility with the target line and which ones must be replaced. Provide a Git or equivalent repository for plugin code, with branch rules and access for the development team. Owner: the source control administrator. Without it, code moves through email or shared folders and history is lost. Finally, decide which Redmine line the work targets. The current supported line is 7.0.x, which receives new features, fixes and security updates, while 6.1.x and 6.0.x receive narrower support. Owner: the CIO or application owner. Deciding this early determines Ruby and Rails versions and which plugin APIs can be relied on. Confirm the exact versions and support windows against the Redmine download page when you make this decision.