Redmine

That's a big patch that is supposed to fix several defects and no tests are included.
I think it should be split into smaller ones that fix a specific issue, with each of them including test(s) for the fix.

I tried the new .patch but there is a conflict with query.rb

Since my redmine is in production, I couldn't try to understand the issue and reverted
I'll let you know if I find the cause

I have a question though, don't you think it would be best to display only projects that have tickets displayed in them ? For example, if I select an Assignee, all my projects are listed even if the assignee is not part of it.

Regards

Alcnedlor Nuratar wrote:

I tried the new .patch but there is a conflict with query.rb

Since my redmine is in production, I couldn't try to understand the issue and reverted
I'll let you know if I find the cause

I just tried on trunk and had no conflict ; since query.rb hasn't been modified since 1.1.1 was released, it should work with stable too.

I have a question though, don't you think it would be best to display only projects that have tickets displayed in them ? For example, if I select an Assignee, all my projects are listed even if the assignee is not part of it.

Well, the patch actually change this behavior : only projects and versions with issues not filtered out are displayed.

Thank you for the quick answer and I must apologize, I should have looked more deeply

I have a conflict, that's the truth... but I don't really know why
The line
(filters_clauses << project_statement(Issue.table_name)).join(' AND ')
was not updated correctly

Except for this little trick, the patch works great

Thank you

Alcnedlor Nuratar wrote:

Thank you for the quick answer and I must apologize, I should have looked more deeply

I have a conflict, that's the truth... but I don't really know why
The line
(filters_clauses << project_statement(Issue.table_name)).join(' AND ')
was not updated correctly

What's your redMine version ? 1.1.1 ? How did you apply the patch ?

Except for this little trick, the patch works great

If you could give me some feedback, that would be great !

Thanks !

Hum,

I have currently Redmine 1.1.1 (2011-01-30)
To apply the patch, I used
patch -p0 < gantt_filters.patch

Otherwise, I don't know what to report :-)

• It is now possible to filter by projects
• Only projects that contains non-filtered tasks are displayed
• Issues are correctly sorted by started date (older first)
• also, if I clear every filters, I think that more issues are displayed (but it's just an impression, nothing scientific in the test)

My DB is MySQL also, so this seems be DB independent

That's all for now

Perfect, thanks a lot !

I now know that it works with MySQL too =)

I've just tried to run the gantt_filters.patch (v2) on v1.1.1 and it failed with the following error message:

(Stripping trailing CRs from patch.)
patching file app/models/issue.rb
(Stripping trailing CRs from patch.)
patching file app/models/query.rb
(Stripping trailing CRs from patch.)
patching file lib/redmine/helpers/gantt.rb
Hunk #3 succeeded at 99 (offset 1 line).
Hunk #4 FAILED at 115.
Hunk #5 succeeded at 301 (offset 22 lines).
Hunk #6 FAILED at 299.
Hunk #7 succeeded at 364 with fuzz 1 (offset 38 lines).
Hunk #8 succeeded at 402 (offset 41 lines).
Hunk #9 succeeded at 434 (offset 41 lines).
Hunk #10 succeeded at 466 (offset 41 lines).
Hunk #11 succeeded at 483 (offset 41 lines).
Hunk #12 succeeded at 491 (offset 41 lines).
Hunk #13 succeeded at 503 (offset 41 lines).
Hunk #14 succeeded at 521 (offset 41 lines).
Hunk #15 succeeded at 537 (offset 41 lines).
Hunk #16 succeeded at 557 (offset 41 lines).
Hunk #17 succeeded at 583 (offset 41 lines).
Hunk #18 succeeded at 600 (offset 41 lines).
Hunk #19 FAILED at 580.
Hunk #20 succeeded at 723 (offset 123 lines).
Hunk #21 succeeded at 733 (offset 123 lines).
Hunk #22 succeeded at 746 (offset 123 lines).
Hunk #23 succeeded at 754 (offset 123 lines).
Hunk #24 succeeded at 794 (offset 123 lines).
Hunk #25 succeeded at 809 with fuzz 2 (offset 123 lines).
Hunk #26 succeeded at 817 (offset 123 lines).
Hunk #27 succeeded at 892 (offset 140 lines).
3 out of 27 hunks FAILED -- saving rejects to file lib/redmine/helpers/gantt.rb.rej
(Stripping trailing CRs from patch.)
patching file test/unit/lib/redmine/helpers/gantt_test.rb

Any help would be much appreciated.

Are you using 1.1.1 stable or trunk ?

I guess you are trying to patch an already patched lib/redmine/helpers/gantt.rb with #2024.

That is a bit touchy as this patch (gantt_filters) is quite a bit destructive, you'll have to patch some part by hand.

Yes, sorry I forgot to mention that I had applied the patch under #2024 beforehand.

Ideally I would like to use both patches as they seem to offer the perfect combination of what I need to achieve using the gantt chart. I guess it isn't that easy at the moment?

I'm fairly new to Redmine and even more so to patches, so I'm not sure how comfortable I would be to do some of the patching by hand. Any help or advise would be greatly received.

I'm currently setting up a separate instance of Redmine to try your patch on it's own, without the gantt chart editing in issue #2024. I'll let you know how that goes.

I've just tried this patch on a fresh install of Redmine 1.1.1 (taken from the svn repository) and it seems to work fine now. Looks like the conflict was indeed with another gantt chart patch #2024.

My only question now is that the gantt chart doesn't seem to appear any different from how it looked pre-patch. I have only run the 'gantt_filters.patch' (v2), as I'm not sure if the 'gantt_filters_render.patch' and 'gantt_filters_issue_compare.patch' are still relevant.

I'm just wondering if most of the issues fixed with this patch are now in the core system, which I why I'm not seeing any difference.

Can anyone highlight the main issues this patch is intended to resolve and if it's still necessary with 1.1.1. Should I also be applying the other 2 patches as listed above?

Thanks.

I just removed remaining irrelevant patches.

As for what it does, I thought that the list in the description was pretty clear :(

Mostly, projects and versions which have no issue related are not displayed anymore, query filters are all taken into account and issue sorting is a bit more precise.

And no, it has not been incorporated to core.

Thanks Etienne, I appreciate your quick response.

The list is pretty clear, but it just made me wonder as I didn't see any difference on my system. It's probably because I was only viewing one test project and didn't look at it across all projects. Now I look at all projects and issues I can see the improvements. Sorry, this was my fault.

Thanks for removing the redundant files, this will be a big help for anyone new to this thread.

I tried to patch 1.1.1.stable.5000 but to no avail.

patch -p0 < gantt_filters.patch

Failed with on all points, what am I doing wrong?

You may have already applied another patch on your gantt ?

If not, try with -p1.

Etienne Massip wrote:

You may have already applied another patch on your gantt ?

If not, try with -p1.

No but tried it anyway and it didn't work, any chance on this being fixed soon in a release? Because this breaks the gantt charting :(

Just done it on r5000 without any problem, and this patch is still applicable on trunk.

What failures were you talking about, exactly ?

Please revert your changes on lib/redmine/helpers/gantt.rb, app/models/issue.rb and app/models/query.rb before patching.

Etienne Massip wrote:

Just done it on r5000 without any problem, and this patch is still applicable on trunk.

What failures were you talking about, exactly ?

Please revert your changes on lib/redmine/helpers/gantt.rb, app/models/issue.rb and app/models/query.rb before patching.

I'm at revision 5022 btw. Really don't know what i am doing wrong.

patch -p0 < gantt_filters.patch
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|Index: app/models/issue.rb
|===================================================================
|--- app/models/issue.rb        (revision 4761)
|+++ app/models/issue.rb        (working copy)
--------------------------
Patching file app/models/issue.rb using Plan A...
Hunk #1 failed at 17.
Hunk #2 failed at 68.
Hunk #3 failed at 75.
3 out of 3 hunks failed--saving rejects to app/models/issue.rb.rej
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|Index: app/models/query.rb
|===================================================================
|--- app/models/query.rb        (revision 4761)
|+++ app/models/query.rb        (working copy)
--------------------------
Patching file app/models/query.rb using Plan A...
Hunk #1 failed at 388.
Hunk #2 failed at 434.
Hunk #3 failed at 443.
Hunk #4 failed at 496.
Hunk #5 failed at 508.
Hunk #6 failed at 537.
Hunk #7 failed at 569.
7 out of 7 hunks failed--saving rejects to app/models/query.rb.rej
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|Index: lib/redmine/helpers/gantt.rb
|===================================================================
|--- lib/redmine/helpers/gantt.rb       (revision 4761)
|+++ lib/redmine/helpers/gantt.rb       (working copy)
--------------------------
Patching file lib/redmine/helpers/gantt.rb using Plan A...
Hunk #1 failed at 38.
Hunk #2 failed at 53.
Hunk #3 failed at 98.
Hunk #4 failed at 115.
Hunk #5 failed at 429.
Hunk #6 failed at 449.
Hunk #7 failed at 471.
Hunk #8 failed at 506.
Hunk #9 failed at 538.
Hunk #10 failed at 570.
Hunk #11 failed at 587.
Hunk #12 failed at 595.
Hunk #13 failed at 607.
Hunk #14 failed at 625.
Hunk #15 failed at 641.
Hunk #16 failed at 661.
Hunk #17 failed at 687.
Hunk #18 failed at 704.
Hunk #19 failed at 725.
Hunk #20 failed at 745.
Hunk #21 failed at 755.
Hunk #22 failed at 768.
Hunk #23 failed at 776.
Hunk #24 failed at 816.
Hunk #25 failed at 831.
Hunk #26 failed at 839.
Hunk #27 failed at 897.
27 out of 27 hunks failed--saving rejects to lib/redmine/helpers/gantt.rb.rej
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|Index: test/unit/lib/redmine/helpers/gantt_test.rb
|===================================================================
|--- test/unit/lib/redmine/helpers/gantt_test.rb        (revision 4761)
|+++ test/unit/lib/redmine/helpers/gantt_test.rb        (working copy)
--------------------------
Patching file test/unit/lib/redmine/helpers/gantt_test.rb using Plan A...
Hunk #1 failed at 91.
1 out of 1 hunks failed--saving rejects to test/unit/lib/redmine/helpers/gantt_test.rb.rej

Etienne Massip wrote:

Here's my patch -p0 --verbose < gantt_filters.patch results on r5021 (windows).

Sorry, I've no clue why yours just fail. I suppose that your cwd is redmine ?

Yes it's the current working directory, /home/www/redmine-1.1/

I'm running FreeBSD by the way.

I've just committed some changes to the gantt chart rendering in r5077.
It should basically implements the changes proposed in the patch, except the issue sort change.

You're a damn good coder, nice clean code !

I think you've fixed #6605 too, didn't you ?

I'll run some tests tomorrow, the few ones I wrote til now all passe =)

Guess you can remove the Issue#for_gantt scope too ?
And maybe the GanttHelper#number_of_issues_on_versions, I can't find any use of it in the project ?

Thanks :-)

Etienne Massip wrote:

Guess you can remove the Issue#for_gantt scope too ?
And maybe the GanttHelper#number_of_issues_on_versions, I can't find any use of it in the project ?

Cleanup done. There's maybe more to do.

There's still at least 1 glitch :

If a subproject issue is targeted to the parent project shared version, its path is rendered as :

parent -> subproject -> shared version -> shared version issues (including parent issues)

parent -> shared version -> subproject -> shared version issues (including parent issues)

Here, parent is what I named "top_version_project" in the patch, this is the project the version should be rendered aside.

The current implementation actually gives what I was expecting (and what is expected in #6476 note-2).
I think it makes sense to display the shared version under the subproject, not the opposite.

I disagree : Gantt is a planning tool and you're planning your issue around a version and then, or if there is no version, around a project.

What note-2 is proposing is to follow the project first and your version second which is wrong to me (you split your version in several Gantt branches).

About #6476, I think that rendering should be different in function of context project.

Version's project Gantt :

parent -> shared version -> subproject -> shared version issues (including parent issues)

Subproject Gantt :

subproject -> shared version  -> shared version issues (excluding parent issues)

Jean-Philippe Lang wrote:

I've just committed some changes to the gantt chart rendering in r5077.
It should basically implements the changes proposed in the patch, except the issue sort change.

I'm interested to find out why the issue sort change was not included in this update.

I've just tested 1.2.0 and there are a number of improvements on the Gantt chart, some or most of which I assuming originated from this patch. However, it seems there is no way to influence the sort order issues in the Gantt chart, with the default being the issue id. It would be great if the Gantt could take the sorting order from the issue list or after selecting a specific custom query from the sidebar.

Are there any plans to incorporate the missing aspects from this patch, in particular the sort issue, into Redmine core in the near future?

Thanks.

I am using redmine 2.2.0 and the sort by start_date issue is a feature I would appreciate, as reported on several issues.

Current sorting by issue_id doesn't provides usable sorting at all, since most of time the issues are not created sequentially in the same order that they should be executed.

The fix for this is very easy, I applied it quickly on 2.2.0. Is there a known reason to postpone it?

Thanks.

Here are some other patches which solves some gantt sort issues too: #8366

Is there a possibility to add sort by due_date too? It's much more needed when talking about Network planning and design

+1