Redmine

Eric Davis wrote:

• Upgrade to Rails 3, if it's a stable release.

I think it might sense to wait on that to give plugin developers time to migrate as well.

Good to see this. You'll not be surprised I'm in favor of an as-early-as-possible upgrade to Rails 3, and I'd like to help for that. Maybe we could have a 1.1 announced as a RC so that people have the time to upgrade plugins ? Is somebody working on the idea of a plugin directory (it could help if we had something like http://railsplugins.org) ?

• improve cross-project usage : make bulk edit work (context menus too), unify UI of global views, make redirections more predictable, etc.
• add a permission-like system for notifications : today there's no single point of passage to decide whether notification should be sent or not, it's a bit scattered in the code, and building simple plugins to tweak that is not easy at all. As a first step I'd like to rewrite it with no more user visible functionalities. I'll propose something about that to have feedbacks before integrating this. I hope I have the time before 1.1.

Of course, any though about these propositions would be welcome.

Igor Balk wrote:

I think it might sense to wait on that to give plugin developers time to migrate as well.

My schedule gives them (me) 3 months to upgrade and migrate. That should be plenty of time.

Jean-Baptiste Barth wrote:

Good to see this. You'll not be surprised I'm in favor of an as-early-as-possible upgrade to Rails 3, and I'd like to help for that. Maybe we could have a 1.1 announced as a RC so that people have the time to upgrade plugins ?

When 1.1.0 RC releases, I'd like to have most of the active plugins ready. Either new releases or a branch to support Rails 3.

Is somebody working on the idea of a plugin directory (it could help if we had something like http://railsplugins.org) ?

It's been discussed a bunch. I'm trying to slow down my business a bit so I can take some time to get something up.

About the main features, everything you say sounds great. There's a couple of things I'd like to work on :

• improve cross-project usage : make bulk edit work (context menus too), unify UI of global views, make redirections more predictable, etc.

Sounds good. I've talked with a client about moving the Admin Projects interface to become the main interface at /projects. That should help make feature development for the Projects views a lot easier.

• add a permission-like system for notifications : today there's no single point of passage to decide whether notification should be sent or not, it's a bit scattered in the code, and building simple plugins to tweak that is not easy at all. As a first step I'd like to rewrite it with no more user visible functionalities. I'll propose something about that to have feedbacks before integrating this. I hope I have the time before 1.1.

I have something similar in production already. It adds a single method on User that takes an object and returns true or false. It's only used with Issues right now but it can easily be extended to support any object in Redmine. A plugin API for adding new notifications sources would be pretty nice too.

Example of how Issue#recipients uses it (with some custom code) http://gist.github.com/574541

If only I had time to port all of my "existing code" into the core. ;)

Eric Davis

Jean-Baptiste Barth wrote:

• improve cross-project usage : make bulk edit work (context menus too), unify UI of global views, make redirections more predictable, etc.

Hi Jean-Baptiste,
While you're on the topic, please merge the cross-projects wiki patch #4052 as well. It really improves cross-project usage.

Whole PDF export rewriting. Current implementation have serious bugs (including famous bug #61) in generating for non-ASCII locales (Cyrillic, CJK).

Please, fix #61

• Rails 3
• REST, REST and REST
• Extract LDAP and OpenID to plugins

Sounds awesome :-)

Gantt chart rewrite

Maybe segregate this to a plugin so it can be maintained separately from the main project? Just an idea..

PDF export rewriting

If anyone starts rewriting PDF, I have a patch that adds dynamic column width based on contents of columns (and headers). It adds a good amount of extra capacity to PDF tables.

Implementing API for time entries will be really great! One of the main reasons to use external API is to track time (redmine client app, for example) and adding API for that will be very useful. Maybe someone will create something like JiraClient for Redmine.