Closed (fixed)
Project:
Storm
Version:
6.x-2.x-dev
Component:
Miscellaneous
Priority:
Major
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
1 Jun 2011 at 03:34 UTC
Updated:
31 Aug 2011 at 08:41 UTC
Jump to comment: Most recent file
Comments
Comment #1
juliangb commentedJust to clarify - this was working in a previous version that you had?
Which was the last version of Storm that you know does not have this bug?
Please open a separate issue for any bugs on the assigned to drop-down.
Comment #2
neubreed commentedHi,
Yes it was working on the previous dev. release.
I was thinking the assigned drop-down had something to do with it but I can create a new issue if it's not.
If you need me to provide more info I'm happy to if you can point me in the right direction.
Thanks,
Ryan
Comment #3
juliangb commentedDo you know the date of the previous -dev release that you were using? (If you have a backup - it should be in the .info file). Also, I'm assuming you were on the previous 2.x-dev not 1.x-dev or anything like that?
Yes, the assigned drop-down may have broken at the same time, but it is a different area of the code.
If you're interested in having a look at this, the code that generates these filters is in stormproject/stormproject.admin.inc and stormtask/stormtask.admin.inc. I assume that recent changes have set some default values here incorrectly.
Comment #4
neubreed commentedAccording to my backup the last version I had was:
; Information added by drupal.org packaging script on 2011-02-25
version = "6.x-2.x-dev"
I've looked into the code and discover the query generated is as follows:
EDIT: 'All' Organizations is selected in the form but this in not returning a result. Should this part of the query be removed? spr.organization_nid=0
The query also seems to contain a LEFT JOIN form the support module which is not part of storm.
Comment #5
neubreed commentedI've temporarily changed line 54 of stormproject.admin.inc from:
to
Comment #6
juliangb commentedThanks for the update. This is a patch that makes the change you've suggested.
I'm just about to test this myself.
Comment #7
juliangb commentedI've just tried testing this, but it seems to work for me. Would you be able to post detailed instructions for reproducing the bug please?
Comment #8
neubreed commentedThis fix works at my end ..
Comment #9
juliangb commentedApologies, I realised that I left a crucial word out of my previous comment - it should have been "I've just tried testing this, but it doesn't seem to work for me."
What I did to test this, was to provision a clean site on Drupal 6.22, and install Storm 2.x-1.x-dev.
I then created a project, and went to the project list to check the bug. (No patch applied). I was expecting the list not to show, but it did seem to work correctly.
It may be that I didn't do enough to trigger the bug, but that's why it would be helpful to have some detailed instructions so that i can reproduce the bug and test the patch.
Comment #10
kfritscheI can confirm this bug and the patch from comment 6 is working.
How you can reproduce it, is easy for me. I go to any list (ticket, task, project) and submit an empty filter (i select in every box "all"), then i get a blank list and in the filter fieldset description stand that it filters for organization, project and tasks (on ticket list)
Sometimes i must first search for something "valid" and when i search then for all, this happens. I think this happens the first time, when the session is empty, so isset($_SESSION['stormproject_list_filter']['organization_nid']) will return false.
I created a patch, which fix this issue for me for ticket, task and project list. It only extend the patch from 6 to the other lists.
Comment #11
juliangb commentedThanks for the report and the patch. I've had another go and can reproduce the problem now - I think previously I was using a project without an organisation set, which meant it didn't show the bug.
I haven't been able to test the patch right now, but have read through and am sure it would solve the problem.
One question though, I think it would also solve the problem if we changed the zero to NULL, for example in line 211 of stormproject.admin.inc . I think both ways would solve it but this might be a little neater. Again, I haven't been able to test that right now. Any thoughts?
Comment #12
kfritscheYour suggested changed wouldn't work. Because if i send submit the form, the organization_id is set to 0. so we also have to change the "all" option to NULL, but this wouldn't work so far i know. (stormproject.admin.inc:254 -> NULL=>t('All'))
Another option would be, to use !empty instead of isset, like it was in an earlier version of storm.
Comment #13
neubreed commentedThe solution in post #6 works for me but I've looked in stormtimetracking.admin.inc and there is no isset() in the if statement. It just tests for true or false with :
Whereas in stormtasks.admin.inc and stormproject.admin.inc it's
and
So the removal of this isset() should fix it as per the other working modules.
Comment #14
juliangb commentedSounds like there is consensus on #10.
I don't have access to commit at the moment, so will do so when I next have a chance (unless someone else commits first).
Comment #15
kfritschePushed this patch into 6.x-2.x.
No need to push this back to 6.x-1.x, because this bug appeared because of changes made in 6.x-2.x.