Since this latest version, filtering the project and task lists aren't working.

There are no results unless you press reset then all projects are displayed. I any of the switches are used no results appear.

Also noticed that the assigned to drop-down is empty on the form.

Ryan

Comments

juliangb’s picture

Just 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.

neubreed’s picture

Hi,

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

juliangb’s picture

Do 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.

neubreed’s picture

According 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:

SELECT DISTINCT n.*, spr.* FROM node AS n INNER JOIN stormproject AS spr ON n.vid=spr.vid LEFT JOIN support_ticket st ON n.nid = st.nid WHERE ( (st.client IN (1) OR st.client IS NULL)) AND ( (spr.organization_nid=0) AND (spr.projectstatus IN ('inserted','in progress','on hold')) AND ('storm_access'='storm_access') AND ( n.status=1 AND n.type='stormproject') ) ORDER BY spr.organization_title ASC LIMIT 0, 50

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.

neubreed’s picture

I've temporarily changed line 54 of stormproject.admin.inc from:

if (isset($_SESSION['stormproject_list_filter']['organization_nid'])) {

to

if (isset($_SESSION['stormproject_list_filter']['organization_nid']) and $_SESSION['stormproject_list_filter']['organization_nid'] !=0) {
juliangb’s picture

Status: Active » Needs review
StatusFileSize
new674 bytes

Thanks for the update. This is a patch that makes the change you've suggested.

I'm just about to test this myself.

juliangb’s picture

Status: Needs review » Postponed (maintainer needs more info)

I'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?

neubreed’s picture

This fix works at my end ..

juliangb’s picture

Apologies, 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.

kfritsche’s picture

Status: Postponed (maintainer needs more info) » Needs review
StatusFileSize
new3.95 KB

I 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.

juliangb’s picture

Thanks 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?

kfritsche’s picture

Your 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.

neubreed’s picture

The 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 :

 if ($_SESSION['stormtimetracking_list_filter']['organization_nid']) {

Whereas in stormtasks.admin.inc and stormproject.admin.inc it's

 if (isset($_SESSION['stormtasks_list_filter']['organization_nid'])) {

and

 if (isset($_SESSION['stormprojects_list_filter']['organization_nid'])) {

So the removal of this isset() should fix it as per the other working modules.

juliangb’s picture

Status: Needs review » Reviewed & tested by the community

Sounds 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).

kfritsche’s picture

Status: Reviewed & tested by the community » Fixed

Pushed 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.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.