Hello Folks,

I'm using all stock\core modules from the Drupal HEAD and no other stuph installed yet.

Server environment is something like this: MySQL - 4.1.14 + PHP - 4.4.xx + Apache 2.0.xx

Here is how to reproduce this small node filter "Bug":

Point your Browser to URL: http://www.your_drupal_site.com/admin/node

And we are getting to the page what's called "content" with some intro text at the top: "Below is a list of all of the posts on your site. Other forms of content are listed......"

Now, there is a Fieldset, called: "Show only items where" and it contains some filtering rules options, some radio buttons [Status, Type, Category], currently I'm [and probably you are as well] able to set filter to accept only [status] or [type] but no way to specify [category] although there is a list of categories, I can pick one and clikc on button [Filter] but it's not storing the specified value.

So far I'm happy with everything else and probably I can live without this functionality but I do believe that this will come out as a "Bug" one day..

Kindly yours,
T.

Comments

oadaeh’s picture

oadaeh commented
Status: Active » Closed (works as designed)

The category item is empty because you have not defined any categories in admin/taxonomy.

In order to use the filtering, you specify one of either status, type or category and an item from the corresponding combobox, then click on Filter. If that is not enough, you select a different one of the radio options and one of the items from its combobox, then click on Refine.

tomsys’s picture

tomsys commented

Hi Oadae,

Thanks for your post,

No you aren't right. I have defined categories in admin/taxonomy and I can see them in dropdown after [category] radio button, this is not the case.. did you tried it out this filtering on your web ?? is it working all right as it should work?

Kind regards,
T.

chx’s picture

chx commented
Status: Closed (works as designed) » Active

this is a known bug. i'd be surprised if this would not be a duplicate. however, node admin form is a very complex form, the form API upgrade was needed to be done by Adrian himself and it's still not an easy case. What I want to say, this is not an easy one and by being far from critical those who could are not dealing with it.

tomsys’s picture

tomsys commented

thanks chx,

Now it's clear to me that it's known "Bug", I'm was searching through the Drupal website for a quite a long time, but I wasn't able to find a single post about this issue here.

Ok, then let's wait and see what will happen :) may be someone will come out with a fresh .patch

Best regards,
T.

oadaeh’s picture

oadaeh commented

Hello tomsys.

Yes I tried it out exactly as you stated it, and it worked fine for me, otherwise I would not have re-marked it as I did. Well, I must not have done it exactly as you described it, because I went back and did it again, and this time it behaved as you described. I did try it two or three times to make sure of my results, but I must have done something wrong the first time I tested it. Sorry about that.

tomsys’s picture

tomsys commented

Good evening everyone,

Could someone please confirm, that this "Current" bug is not going to be on any near future priority list and nobody is trying to solve this issue, I didn't want to go too deep in learning that node.module complex form handling stuff.. it seams to be quite unique

If someone has any suggestions - digg yourself \ wait one more week \ forget about it.. anything from respectable authorities will do.. Otherwise it will take me feew days to find\solve this problem on my own.. and I'm sort of short on spare time

Regards,
T.

chx’s picture

chx commented
Status: Active » Closed (duplicate)

Zen has a patch for this. http://drupal.org/node/35073