This error is appearing on every view that has at least one active saved search, and nowhere else... So I'm assuming it's being cause by save searches, because saved searches isn't properly integrated with a module I'm using.... Possibly heirarchial select...
Awesome Module btw... Loving the integration with notifications, a feature weve been trying to develop for years... Brilliant

Daryl

Comments

Aron Novak’s picture

Aron Novak
Primary language Hungarian
Location Hungary, Budapest
CreditAttribution: Aron Novak commented
Status: Active » Postponed (maintainer needs more info)

Can you try to determine which is the conflicting module? This is really easy, just try to turn off the candidate modules (one by one) and check if the error disappears or not. After there is a definite conflicting module, i'm happy to debug the exact problem and fix it.

beres.mate’s picture

beres.mate CreditAttribution: beres.mate commented

This message also appears for me, while using exposed date filters. After saving the date filter settings, the date filter returns an empty array.

Aron Novak’s picture

Aron Novak
Primary language Hungarian
Location Hungary, Budapest
CreditAttribution: Aron Novak commented

beres.mate: which version do you use? beta2? Give -dev a try.

langrock’s picture

langrock CreditAttribution: langrock commented

I am having similar troubles. In my case, I don't receive an error message when logged into the system, but get the above stated message when using exposed filters, both date and text, when being an anonymous user. The weird thing is that the filter does execute correctly, i.e. the table displays the correct values. I am using the latest 6.x-3.x-dev version of views, but this didn't make any difference. It was hinted at that this problem has nothing to do with the views module, but I cannot seem to find any other problems. There are no access restriction on either the view or any of its components, as far as I can tell. I am stumped and would appreciate helpful hints. I made sure that the permissions setting for both logged-in as well as anonymous users are exactly the same, and yet there's a different behavior visible.

Thanks,
Carsten

p.s.: The address of the problematic view is http://nlo.stanford.edu/publications/all

UPDATE 4/12/2011: I switched to private file transfer to eliminate another problem I had with respect to accessing files and is somehow seemed to have resolved the above problem as well. I no longer get the error message, logged in or not. I must admit that this is a mystery to me.