Redmine

Your observations about Redmine's performance degradation due to extensive history entries, especially with subissues, are very insightful and highlight a common challenge for users with large-scale Redmine instances. You're absolutely right that loading thousands of history entries unnecessarily can significantly impact server load and overall system stability.

Let's break down your proposed functionalities and my thoughts on them: https://www.mycard-statement.com

Your Proposed Functionalities:
a) Enable history: This is the default and fundamental function.

b) Limit to x entries: This is a highly valuable and practical solution.

c) Load only on demand: This is an excellent idea for optimizing performance.

d) Disable history: While drastic, it provides an ultimate control for specific scenarios.

My Thoughts on Your Proposals and the Problem:
Your suggestions are excellent and address the core issue directly. Here's why I think they are so relevant and what Redmine's current state is regarding these features:

Current Redmine State:

No Native "Limit to x entries" or "Load on Demand" for History: As of my last knowledge update (and a quick search confirms this remains largely true), Redmine does not natively offer granular control over the number of history entries displayed per issue or the ability to load them "on demand" (e.g., via an "expand history" button). The entire history associated with an issue is typically loaded when you view that issue.

No "Disable History" Option: There isn't a global or per-project option to completely disable the history tracking for issues. History is a core auditing and tracking feature in Redmine.

Why Your Suggestions Are Crucial:

Performance Optimization (b & c): Limiting entries and loading on demand are standard patterns for handling large datasets in web applications. They directly tackle the "unnecessary data loading" problem you described. This would drastically reduce the initial page load time for issues with long histories and lessen the burden on the database and server.

User Experience (b & c): Beyond performance, a massive history log can be overwhelming for users. Showing a concise summary with an option to view more provides a cleaner, more efficient user interface.

Scalability (b & c): For organizations with many projects, users, and issues over time, these features become critical for maintaining a usable and performant Redmine instance.

Control (d): While "disable history" is a strong measure, it offers flexibility for very specific edge cases where history is genuinely not needed and performance is paramount, or perhaps for archival projects.

How This Could Be Implemented (From a Redmine Development Perspective):
Configuration Options:

Global Setting: A new setting in Administration -> Settings -> Issues (or a dedicated "History" tab) to define a default x for "Limit to x entries."

Project-Specific Override: The ability to override the global setting at the project level, allowing project managers to fine-tune this for their specific needs.

UI/UX Changes:

When the history exceeds x entries, display a message like "Showing X most recent entries. [View Full History]" or "[Load More History]".

The "View Full History" could either load all remaining entries dynamically on the same page or link to a dedicated history page for that issue.

Database Queries: The underlying SQL queries for fetching issue journals (history) would need to be modified to include LIMIT clauses.

What You Can Do Now (Workarounds & Potential Solutions):
Given that these features aren't native, here are some paths you could explore:

Redmine Plugins: Search the Redmine plugin directory (https://www.redmine.org/plugins). It's possible a community-developed plugin already exists that offers some form of history management or performance optimization. Be sure to check plugin compatibility with your Redmine version.

Custom Development: If a plugin doesn't exist, and this is a critical issue for your organization, you might consider engaging a Redmine developer to create a custom plugin that implements these functionalities. This would involve modifying the view files and potentially the issue model to add the desired logic.

Redmine Feature Request/Patch:

Feature Request: The most direct way to get this into Redmine core is to propose it as a new feature. Redmine uses a bug tracking system (itself!) for this. You can create an issue on their tracker: https://www.redmine.org/projects/redmine/issues. Clearly articulate the problem and your proposed solutions, similar to what you've written here.

Provide a Patch: If you or someone in your team has Ruby on Rails development experience, you could develop a patch that implements these features and submit it for consideration by the Redmine core team. This greatly increases the chances of it being included in a future release.

Database Optimization (General): While not directly limiting history display, ensure your Redmine database is well-optimized (proper indexing, regular maintenance). This can help with overall performance, even when loading large datasets.

Server Resources: Ensure your server has adequate RAM, CPU, and fast I/O (SSD storage) to handle the database load. This is a general performance tip, but it becomes more critical with large datasets.