Redmine is opinionated but highly configurable: trackers, workflows, custom fields, roles, themes, plugins. The admin panel covers a lot, but the fiddly parts — workflow matrices, YAML config files, plugin installs — go faster when you describe the outcome and let the vibe-code agent edit the files, run the migrations, and restart services. Here are ten customizations worth asking for.

1. Model your data with custom fields

A bug that carries a Severity field makes triage meetings shorter because nobody has to ask how bad it is. The agent creates the list custom field, limits it to the Bug tracker so feature requests stay clean, positions it on the issue form, and makes it required before the status can move to Resolved. The same pattern covers a ‘Customer’ field on support tickets or a ‘Billable’ flag on time entries — say the rule once and the agent wires it through the forms and validations. Add a required custom field ‘Severity’ with values Low, Medium, High, and Blocker on the Bug tracker only, and block closing a bug until it is set.

2. Tune the workflow matrix per role

The default workflow lets everyone do too much: reporters can close their own tickets, and anyone can skip straight to Resolved. The agent edits the tracker-and-status transition matrix so reporters can reopen but not close, junior developers can’t close high-priority bugs, and only managers can move issues to ‘Rejected’ — then verifies the transitions with a test issue. Adjust the Bug workflow so the Reporter role can reopen issues but not close them, and walk a test issue through the new transitions to confirm.

3. Put your brand on it

Redmine ships with one plain look, but themes are just files under public/themes, which makes this an easy win. The agent installs a community theme, swaps in your logo and favicon, updates the welcome text on the home page, and restarts the app so you can see it live. If the theme conflicts with a plugin, you find out now rather than during onboarding week. Install a clean modern theme, replace the header logo with our logo, and set the welcome text to point new users at the Getting Started wiki.

4. Add issue templates with a plugin

Structured bug reports get fixed faster, and templates are the cheapest structure there is. The agent installs the open-source redmine_issue_templates plugin the standard way — clone into the plugins directory, bundle install, run the plugin migration, restart — then creates templates for your most common trackers with the sections you want filled in. Install the issue templates plugin and create a Bug template with sections for Steps to reproduce, Expected behavior, and Actual behavior.

5. Wire up LDAP authentication

Manual account management doesn’t scale past ten people. The agent configures an LDAP authentication source pointing at your directory, maps directory groups to Redmine groups with the right roles on the right projects, tests a login, and keeps a local admin account as fallback so a directory outage never locks you out. Connect Redmine to our LDAP directory, sync the dev-team group to a Redmine group with Developer access on the Webshop project, and verify a test login works.

6. Make email notifications actually send

Redmine without working SMTP is a silent black box — people miss assignments and assume the tool is broken. The agent edits configuration.yml with your mail server settings, restarts, and proves it by triggering a real notification from a test issue update. Delivery problems are the classic Redmine complaint, so insist on that end-to-end test before calling it done. Then it tunes the per-project notification defaults so assignees and authors get what they need without a flood. Configure SMTP with our mail server, send a test notification by updating issue #10, and set the default notification options so assignees and authors are informed on updates.

7. Audit permissions and API keys

Small teams accumulate risky settings: a project accidentally left public, an API key issued two laptops ago, anonymous users with more than read access. The agent reviews the anonymous and non-member roles, lists every project flagged public, enumerates active API keys, and drafts a revocation list for your approval before it disables anything. Audit all projects for anonymous or overly broad access, list every active API key, and recommend which ones to revoke.

8. Harden and tidy the server

A production Rails app needs log rotation, upload caps, and cache discipline or it slowly eats its own disk. The agent sets up logrotate for the Redmine and Rails logs, caps attachment size in Settings, schedules a job to clear tmp and cache directories, and reports disk usage before and after so you can see the effect. Rotate Redmine’s logs weekly, cap attachments at 20 MB, add a monthly cleanup job for tmp and cache files, and report disk usage before and after.

9. Archive what’s dead

Ten years of issues is a liability when half the projects are fossilized — they slow search, confuse new staff, and bloat backups. The agent identifies projects with no activity in two years, reports their attachment footprint so you know what you are keeping, then archives them read-only so history stays visible but untouched. If storage is the pressure point, it can also list the largest attachments across all projects before you decide what to prune. Find projects with no activity in 24 months, report their total attachment size, then archive them so they remain readable but nobody can add new issues.

10. Add QA statuses that match your process

‘New, In Progress, Resolved’ doesn’t describe a team with code review and a dedicated test stage. The agent creates ‘In Review’ and ‘Ready for Test’ issue statuses, wires them into the Bug workflow with the right role permissions on each transition, and sets distinct colors so they read clearly on the issue list and the Gantt chart. Add statuses ‘In Review’ and ‘Ready for Test’ with distinct colors, connect them into the Bug workflow, and show me the Gantt chart so I can check the colors.

Each change here touches real configuration, so have the agent show a summary of what it will change before applying, and let it verify after with a quick check. Your server, your rules. See Redmine on OpenSysLab.