Support for views module

+1

again +1 for the functionality

I tried it now.
It does not work for me...
there is no option to sort it or to filter it

please add t()-functions

I tried it again and it does not work.
The new filter and sort-options are not available.

I tried to import your view.
it failed with the following message "You don't seem to have the following requirements: event"

And yes I use the current versions of the modules

FYI, Views caches this data, so if you ever change it, you need to be sure to invalidate the views cache. This happens automatically when submitting the module page.

the problem was the cache.
it worked after I deleted the cache

this means it works and I think it is ready to go :D

I just took a quick look at this patch, and I have some minor comments.

+         "nid" => "nid", 
+         "addlfields" => array("nid")

The two instances of that code should not be necessary; 'nid' is a required field on all nodes, and isn't necessary to display dates in any case.

+       "event_start" => array("name" => "event starts"),
+       "event_end" => array("name" => "event ends"),

Should be

+       "event_start" => array("name" => "Event: starts"),
+       "event_end" => array("name" => "Event: ends"),

With my newest code, I've added an (as yet undocumented) feature to let you directly add formsapi widgets so that you could actually add something to let you enter a date.

You probably also want to add some extra operators to the filters:

Today
Yesterday
1 week ago
1 month ago
etc

This is exactly what I need (as I'm waiting for a real date field to be added to CCK). I'll be happy to test an updated patch when its available.

Latest patch on this page works for me too on 4.7-beta 5. The imported view doesn't work however.

Also happy to keep testing.

I have taken a different approach to this. I created a patch that adds the capability to filter by year, month and/or day. I started with the the "now, 1 week ago, 1 month ago" approach suggested in this thread, but there are so many possibilities of what someone might want to see and it started getting so complicated to think what they all might be that I ended up just going back to giving the user the choice to select year, month, and day (each with a choice of >, >=, =, <, <=, or all). It felt like I could zero in on the dates I wanted fairly well with that.

I also set up three default views in the patch (a list, a table, and a teaser list), which means those default event views will show up on the views list automatically for anyone who has view enabled, with no need to import or create them. You can still make changes to them, but they should work out of the box. Just click on the "add" link, make any changes you want, and save it. I set them up so menu items will be created, but you can turn the menu off if you don't want it.

I am guessing that the reason why Patrick was not able to get the import to work is that he is using flexinode instead of basicevent -- the export was created using the basicevent module so it is only set up to work with that node type. I tried to take care of that by doing a check for all event-enabled node types in this patch to make sure all are included in all in the default views.

Anyway, I thought I'd share my work in case anyone else is interested.

Oops, looks like something cut off the end of my previous post.

I was saying I set up three default views in the patch, a bulleted list, a table, and a teaser list. They will show up as default views on the views page, no need to import or set them up. You can change them if you want, but they should work fine right out of the box.

Anyway, just sharing what I came up with building on what dado started.

Hold up until tomorrow on this. It was working fine, but one of my last additions broke something. I will investigate it further. It does create the default views, etc., but the filtering isn't working right any more. I don't think it's anything big, but I won't get to it until tomorrow. :-)

OK, here's another try. There was a problem with the results caching when they shouldn't have, and another problem with the associative arrays getting goofed up if you start making the field optional, and a couple other odds and ends. I reduced the number of default views to one just to keep from filling up the default views list (you can change the view from a table to a list or to a teaser list when you add it to your views).

The views module does caching at several levels, so once you add this patch, go back and clear all your caches or you will get odd results.

Ok, there's this undocumented feature of views that you can use here, which is that you can drop a formsapi widget right into Views and it'll use it.

At first I was elated to see that Event almost has one...but sadly, it's 'almost'. It needs to be tweaked...perhaps significantly. Here's what needs to be done:

event_form_date() needs to return a $form widget, and not take arguments that are dependent upon the data.
You can pass this to Views in the 'filters' section like this:

    'filters' => array(
      'event_start1' => array(
        'field' => 'event_start',
        'name' => t('Event: Start Year'),
        'operator' => array(
          '' => t('<All>'),
          '>' => t('>'),
          '>=' => t('>='),
          '=' => t('='),
          '<=' => t('<='),
          '<' => t('<'),
        ),
        'value' => event_forms_date(),
        'type' => 'year',
      ),

event_forms_date() needs to return an array. It currently does that. I'll name the array it returns $form_date so I can refer to it more easily.

It needs to use one of the formsapi hooks, #process is the most likely one, to pull the $form_date['#default_value'] from the array event_forms_date() returned (which Views will set) to populate the other fields.

It can then use the #after_build hook (I think) to extract the information and construct a complete date, and stick this on $form_date['#value'].

This is pretty intense forms api stuff but I've managed to do something similar to it with the ACL module (part of na_arbitrator).

It's very interesting looking into what you can do with the formsapi, I was wondering how you could ask for date parts and put them back together as a date and now I think I see how to do it. However, that's not what I was trying to do. Here's what my test case looks like:

There is a database with lots of events going back to 2003. I want the view to start by showing me events with the current year and month, but allow me to select a specific year, month, and/or date to view. I can't ask for a year, month, and day and then show everything based on that complete date because it won't give me the time period I am trying for. Selecting and querying for the specific date parts works better, and adapts well no matter how many events are in the database. (If there are just a few, I can look at a whole year at a time, if there are lots, I can look at an individual day).

However, in looking through what your suggestion entailed, I realized I had made my view more confusing than it needed to be. I really don't need any <> operators, I just need an = operator that can be applied to a list of all possible years, months, and days, plus the value '' for times when I don't want some part of the date to do any filtering.

The '' value is my way of being able to get the view to start with the current year and month, whatever it may be, by hard-coding that value into the view as the default value and checking at runtime what the current year and month are to adjust the query accordingly.

The view as I have it set up now does exactly what I intended it to do -- you can input any combination of a year, month, and day and see the events for that period (i.e. all events for 2003, all events in June of 2004, all events on April 14 of any year, all events on July 4, 2005, etc.)

Based on comments by merlinofchaos on the work I did creating the patch to views-enable the location module, I have now re-created this as a separate module that checks to be sure both event and views are enabled. Fortunately, we don't need any LIKE queries here (only numeric data), so the utf-8 problem I had with the location module won't be an issue and I don't have to test for that.

Attached is the event_views.module that I created. I should also provide a patch for the events module to clear the cache anytime there are changes in the earliest or latest event or the nodes that are events-enabled, but I'll make sure this module is going to be acceptable before I do the work to create that. (That's just housekeeping stuff, the view will work fine without it, just won't adapt to later changes.)

I see something got cut out of the previous comment.

The '' value is my way of being able to get the view to start with the current year and month, whatever it may be, 

should have said

The '<current>' value is my way of being able to get the view to start with the current year and month, whatever it may be, 

I just got done making a patch that adds the pop-up jscalendar as an input option when creating an event, if jscalendar is enabled. I could also add this capability to the event_views module. I would create two fields, a from date and a to date, each would be a pop-up js calendar. Then I can create a handler to interpret that input to query for dates between those input dates. Any interest in this? If so, should it be the default if jscalendar is installed?

I decided it would be really nice to have the event view module set up to allow the use of a javascript pop-up calendar for selecting the from and to dates for the view, so I went ahead and figured out how to get it working. The attached module will check for the existance of the jscalendar module (from the jstools module at http://drupal.org/node/57285). If it is enabled, the default view shows two exposed filters -- a from date and a to date that each use the pop-up jscalendar widget as a date selector (all put together using the non-documented formsapi that merlinofchaos referred to).

If jscalendar is not installed, you get the previously-described behavior -- a year, month, and day drop-down selector.

I also added in the dependency-checker that merlinofchaos suggested I add to the location views module I created -- it will automatically disable the event views module if either the event module or the views module is disabled.

I adore the popup jscalendar idea. I'll have to look at this when I've got some time away from work, but I support it 100000000% and if it works nicely, I'd support patching Views to allow the calendar popup as a standard on all dates views supports, with some documentation on what you did so I can get JonBob to put it as a option in CCK's date field as well.

I've tried both the event_views_0.module and the older event_views.module and both of them give me this error at the top when I go to the page for the view:

user warning: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'DISTINCT(node.nid) = event.nid WHERE (node.status = '1') AND (node.type IN ('fl' at line 1 query: SELECT count(*) FROM drp_node node LEFT JOIN drp_event event ON DISTINCT(node.nid) = event.nid WHERE (node.status = '1') AND (node.type IN ('flexinode-1','flexinode-5')) AND (YEAR(FROM_UNIXTIME(event.event_start)) = 2006) AND (MONTH(FROM_UNIXTIME(event.event_start)) = 4) in //includes/database.mysql.inc on line 120.

Any ideas?

Thanks,

Michelle

Yes, I think I know what the problem is, but need to be sure and get it fixed. It seems to be related to coming up with no results because the wrong node type is in the view or there are no results. There is someting in the way the code is written that needs to be adjusted. I only get that error if there are no results. I will work on this and report back.

OK, I did see that message, too, when I had not set up any node as an event-enabled node and had tried to fix it, and now I cannot replicate it. I have tried all kinds of scenarios and the view works fine in all of them.

So I need some more info.

1) Are there actually any events that should meet the selected criteria, or will it be returning an empty set?
2) Is it picking up the right flexinodes (are those the ones you event-enabled?)

The sql text 'DISTINCT(node.nid) = event.nid ' is not coming from the default view, so you added something (or flexinode added something) to the view. Can you export the view and paste it here so I can see how it is set up? I think that is where the problem lies.

DISTINCT showing up in odd places is almost always a node_access issue, because node_access decides to rewrite the query and gets it wrong. So a good variable to check is: What node access modules are enabled?

I've only got a minute while my son plays upstairs, but I wanted to reply quick so you didn't think I was ignoring you. I'll do some detective work as soon as I can get him down for a nap and get back to you. Should be in the next few hours.

Thanks,

Michelle

It's hitting the right flexinodes and there are plenty of them there to display. Here's the view. Preview is still broken, so hopefully this shows up right...

Thanks,

Michelle

  $view = new stdClass();
  $view->name = 'copy of event list';
  $view->description = 'User selectable table of events.';
  $view->access = array (
);
  $view->view_args_php = '';
  $view->page = TRUE;
  $view->page_title = 'event list';
  $view->page_header = '';
  $view->page_header_format = '1';
  $view->page_footer = '';
  $view->page_footer_format = '1';
  $view->page_empty = '';
  $view->page_empty_format = '1';
  $view->page_type = 'list';
  $view->url = 'event/views';
  $view->use_pager = TRUE;
  $view->nodes_per_page = '10';
  $view->menu = TRUE;
  $view->menu_title = 'event list';
  $view->menu_tab = FALSE;
  $view->menu_tab_default = FALSE;
  $view->menu_weight = '';
  $view->sort = array (
  );
  $view->argument = array (
  );
  $view->field = array (
    array (
      'tablename' => 'node',
      'field' => 'title',
      'label' => '',
      'handler' => 'views_handler_field_nodelink',
      'sortable' => '1',
    ),
    array (
      'tablename' => 'event',
      'field' => 'event_start',
      'label' => 'Start Time:',
      'handler' => 'views_handler_field_date_small',
      'sortable' => '1',
      'defaultsort' => 'ASC',
    ),
    array (
      'tablename' => 'event',
      'field' => 'event_end',
      'label' => 'End Time:',
      'handler' => 'views_handler_field_date_small',
      'sortable' => '1',
      'defaultsort' => 'ASC',
    ),
  );
  $view->filter = array (
    array (
      'tablename' => 'node',
      'field' => 'status',
      'operator' => '=',
      'options' => '',
      'value' => '1',
    ),
    array (
      'tablename' => 'node',
      'field' => 'type',
      'operator' => 'OR',
      'options' => '',
      'value' => array (
  0 => 'flexinode-1',
  1 => 'flexinode-5',
),
    ),
    array (
      'tablename' => 'event',
      'field' => 'year',
      'operator' => '=',
      'options' => '',
      'value' => 'current',
    ),
    array (
      'tablename' => 'event',
      'field' => 'month',
      'operator' => '=',
      'options' => '',
      'value' => 'current',
    ),
    array (
      'tablename' => 'event',
      'field' => 'day',
      'operator' => '=',
      'options' => '',
      'value' => 'all',
    ),
  );
  $view->requires = array(node, event);
  $views[$view->name] = $view;

Sorry for the delay in responding, I've been out of town with no internet access. The view looks OK at first glance, so let's go down the node-access route that merlin mentioned. What node access modules do you have enabled?

No problem. I've got irons in a lot of fires with this site. I just moved on to other ones. :)

The only access thing I've got going is taxonomy_access but events are anon viewable, so that shouldn't hurt it.

Thanks,

Michelle

I set up a test platform with a flexinode event and taxonomy access and confirmed that taxonomy access is creating the problem. When I activate taxonomy access, the view query gets garbled. When I deactivate it, the view works fine. Taxonomy access is rewriting the views query and creating the problem, so I don't think there is anything that can be done in the view itself to correct this, or at least I don't know how to fix it. If merlin is following this thread maybe he has an idea. I will cross post this to the views issues page to see if there are any ideas on a fix.

Here is where I posted the issue on the views issue page http://drupal.org/node/60280.

I did some more experimenting. If you remove the node:distinct filter from the view (which was not in the default view anyway), you will get a list of events but still see an error message.

If you delete the view, enable jscalendar, then add a new default view it will use the jscalendar start date and end date fields for filters (which uses a different sql query format). If you do that the view will work fine with taxonomy access, so that would at least be a workaround for you.

I'm not sure what you mean by "which was not in the default view anyway"? I didn't make any changes to the view.

I'll give your work around a try, thanks.

Michelle

Sorry for the confusion. The node:distinct filter was in there because I was trying to see if it would fix the problem. It is not in your view, nor in the default view. When I wrote my comment I forgot that I was the one that had added it.

+1
This worked for me, but it is confusing. I applied the patch and downloaded the module.
Are they both needed?
I tried the module first, but nothing worked until I patched event.module.

They are two separate approaches. The patch was one proposal for a way to handle event views and the separate module is another. Neither should require the other to work. It looks like making it a separate module will be consistent with the way that views is being integrated into other modules, so I do think the final solution should be a separate module, but it may or may not end up being the one that I proposed.

I couldn't tell what kind of problem you ran into. There is a known problem with some node_access modules like taxonomy access and node privacy by role because certain sql text that we need for event handlers gets garbled by node_access. Specifically, any sql that uses FROM_UNIXTIME gets butchered by node_access. Merlin is going to talk to moshe about this and hopefully we will find a way to make it all work, since many of the fancy filters and handlers we need for events will have to use that kind of sql. The events patch at the top of this thread is less comprehensive and is structured differently. Since it doesn't use any FROM_UNIXTIME sqls it may work for some people when the separate module will not.

Hi dado,

You have added some things I didn't have, like the timezone conversion, but your version is going to have the same problem mine did -- you have FROM_UNIXTIME in your sql which gets garbled if you have any kind of node access enabled. In addition, I've since realized that FROM_UNIXTIME won't work on postgres either, so it's going to be problematic. I've been trying to think of a way to configure queries that don't use that syntax, but haven't come up with anything yet. Do you have any ideas?

The jscalendar widget, at least, will work without using FROM_UNIXTIME, but we need it to work for other selectors.

Here is a function for postgres support for FROM_UNIXTIME
http://www.raveica.com/blog/?p=5

The SQL calls could be in the .install file for a postgres specific update.

I've been tracking the developments in Events re Views and Jscalendar.

As regards Views, I've used the module here:

#39 submitted by dado on May 9, 2006 - 00:59
Attachment: event_views_2.module (9.53 KB)

It seems to do the trick.
Could it be ammended to allow showing events for the next X days, or X months, something like that.
The Filters on Start time [all my events only have a start time being sporting events], only allow comparison based just on current time.

If I could filter something like:
Start Time is greater than current time
AND
Start time, is less than, [current time + 30 days]

That would be great, always showing upcoming events for 30 days.

Regards
Alan
I'm using the combination of Event, Gmap, location and Views to create some cool stuff, without any programming . Drupal is getting VERY powerful.

KarenS;

I just committed an update to Views that I think will reduce the amount of code in your patch.

Look at the date filtering and date display changes (look in views_node.inc and the end of views.module) -- I added support for from_unixtime just for event.module =)

I also added support to use the option field to create a custom date display format. Need to document that.

Would some of these date issues be solved by converting the date storage from int to timestamp in the database?

As near as we can tell, the date issues have disappeared again.

I'm going to try to incorporate all the latest changes into a re-rolled module and then we can test to be sure everything is working. I no longer get the error we were discussing in this thread, so hopefully we can move forward now :-)

I was just testing the event_view_2.module.

It seems that the default event/views does not work. I can get it to work if I click the add link and the save the form without changing anything.

That's actually the way you're supposed to do it. The default views are basically templates and you should add and save the one(s) you want to use. Some of them work without that step, but I've noticed a number of cases where you need to take the step of adding the view to get it completely set up.

Dado,

I didn't mean to step on your toes on your module when I talked about re-rolling, I just thought I could add back in the javascript calendar selector and some of the other options to select a specific year, month, and day for more flexibility.

That's actually the way you're supposed to do it. The default views are basically templates and you should add and save the one(s) you want to use. Some of them work without that step, but I've noticed a number of cases where you need to take the step of adding the view to get it completely set up.

Hmm. That's not really the way I intended it. Well, it tends to depend on the module, but the default views should at least provide some functionality, even if they really should be tweaked somewhat. If the default view actually doesn't work that may be a bug somewhere.

This module appears to be getting stuck in an inifinite loop. I'm getting maximum execution time exceeded errors (shouldn't take 30 seconds to submit a view) with event_views_2.module and latest views.module from head.

Just want to voice my support for this.

+1 - I tried event_views_2.module
It works for me on two different sites. I have taxonomy_access installed and no problems.

This still is working for me, but I did find a problem with the event list:
http://www.example..com/event/views

user warning: You have an error in your SQL syntax. Check the manual that corresponds to your MySQL server version for the right syntax to use near 'DISTINCT(node.nid) = event.nid WHERE (node.status = '1') AND (n query: SELECT count(*) FROM node node LEFT JOIN event event ON DISTINCT(node.nid) = event.nid WHERE (node.status = '1') AND (node.type IN ('flexinode-1','flexinode-2')) AND (YEAR(FROM_UNIXTIME(event.event_start)) = 2006) AND (MONTH(FROM_UNIXTIME(event.event_start)) = 5) in /big/dom/****/www/includes/database.mysql.inc on line 120.

I'm trying to use the views to list the terms of a vocab. its working great except that the terms are duplicated because of duplicate nodes associated with them. Any ideas on how to make a single list? I've tried using the distinct filter but it seems that its just for the node - not for the term.

kickn - Your question doesn't have anything to do with events as far as I can tell. You'd have more luck posting a support request on the views module.

Michelle

I'm getting the error in #54 as well.

And that wouldn't be too horrible except that you can't disable that menu item. ;)

Duh. Yes you can, just under administer >> views. Sorry, it's late. ;)

I'm using event_views_2.module btw, and also organic groups which may have something to do with the issue (I noticed issues around taxonomy_access earlier).

A small feature request: don't hard-code the labels on the table header.

The UNIXTIME error is probably the same one reported at http://drupal.org/node/60280. I am no longer able to reproduce that error for some reason, so I had hoped it was fixed, but maybe not. Someone who is getting the error should post to that thread so maybe merlin can figure out how to fix it. It seems to be a problem for any query that uses UNIXTIME on a system that has some kind of access control on it.

I finally got a chance to adapt this module for all the changes merlin was talking about. He has added lots of built-in date handling to the views module and I removed all the customized date handlers in favor of the views built-in ones. I also added in argument handling so you can create a view that filters dates using YYYY or YYYY/MM or YYYY/MM/DD in the url. I also added a little bit of info in the admin/help section to explain the options. There will almost certainly be other things people want to add once they have used it a while, but I think this provides a nice collection of views options to get started with.

To get this working completely correctly, you need to apply a patch to views that I posted at http://drupal.org/node/66928. This also does not address the FROM_UNIXTIME error mentioned already since that can only be fixed by changes to either views or node_access.

If you're not sure how to get the arguments working, here's how:

Delete all the filters and exposed filters from the default view since the arguments will handle the filtering. Add three arguments to the view, in this order, Event: Start Year, Event: Start Month, Event: Start Day. Set each one to display summary sorted. Save the view (and make sure your cache is cleared if you have used this before), the go to the url event/views. You will see a list of all the years that have events. Select the year you want and you will see a list of all the months that have events in that year. Select the month you want and you will see the final view filtered by year, month, and day. Or just go straight to the date, i.e. event/views/2006/5/31.

The other question is whether the view set up for arguments should be the default instead of the view that provides a date selector. Doesn't matter to me, so I figured I'd let people try it out both ways and decide. Everyone can change it, it's just a question of what is set up to work 'out of the box'.

Suggestion: Provide the default views each way you think will be interesting. Set them to disabled.

If I remember right, it's '$view->disabled = true'; in the view definition.

Then, in the docs, describe what each view does. That'll make it easy for an administrator to pick and choose which one(s) they want to use.

Also, assuming KarenS's newest changes seem stable, this is probably nearly ready for a commit. Perhaps the change I just suggested should go first, but I think people will really benefit from this and we should get something that people can use and continue to refine it. I'm vaguely tempted to suggest that maybe it should be its own project to make it a little easier to be maintained (ok, I admit it's because I could then subscribe to the project and get all issues against it).

But that's really up to you guys.

Hold up on using the latest patch. I'm going to incorporate merlin's suggestion of offering both options, plus I see a better way to handle the current date setup and have just a bit of miscellaneous cleanup to do. I'll be posting a revision soon, and hopefully it will be commit-ready.

OK, I think this module has all the right stuff and I have been banging it around and I think it is working reliably.

* It has 3 default views available and you can use any or all of them -- a normal drop-down date selector, a jscalendar selector, and a view that uses year/month/day arguments as a filter.

* I beefed up the help text a bit (admin/help/event_views) to explain the options

* Lots of argument options -- year, year/month, year/month/day, year/week.

* You can add content type and taxonomy arguments before or after the year/month/day arguments for more granular filtering

* the dependency checker is in there to be sure both events and views are enabled and to disable this module if either of them is disabled.

* I added in merlin's idea for outwitting the from_unixtime errors by changing FROM_UNIXTIME to from_UNIXTIME. This needs to be tested by someone who was getting the unixtime errors.

Anyway, I need a few testers to be sure all is well.

As to merlin's idea about setting this up as a separate project, I would be glad to do that if it seems like a good idea to others. That would allow us to continue to expand on it (perhaps getting to the place where we can have an option to display the results in a calendar view). I've been working on several other views modules, and I have some ideas about how to get a calendar view working.

If you want to set up the views integration as a separate module or project you are of course welcome. I wouldn't mind to integrate it through a patch as well.

If you want to go for an extra module all you need to dcide if you want to host it as a contrib project for event or entirely separate.

I think it's best as a separate module both because not everyone will use it and because it has the potential to be pretty big. I'd like to see it as a contrib module for events, since it is so closely tied to the events module.

If it's set up as a contrib module, can we give it its own issues/feature request tracker? If not, that might be a reason to keep it as a separate project instead.

Ok, that makes sense to me. event.module is already pretty big on its own. I've given you cvs commit access so you should be able to add it in /contrib. Please don't apply patches to event.module without consultation.

I think you can (and maybe should) create an extra project to create some extra awareness.

We might want to create extra directories on /contrib.

We can either add a field "views for event" to the event module tracker or you create your own project that points to /modules/event/contrib/event_views.

I'll create a separate project that points to event/contrib/event_views. That will allow for issue tracking and give me a way to let people know how things work, solicit feedback for future enhancements, etc.

Thanks!

Thanks for this important work. It would be wonderful if you could tag this for 4.7 also

I do have plans to modify this to include a calendar view plugin for Views. Should I submit patches or commit directly? 'Tis up to you guys.

I'm still getting the sql error:

* user warning: You have an error in your SQL syntax. Check the manual that corresponds to your MySQL server version for the right syntax to use near ';= MONTH(from_UNIXTIME(1149406018)))' at line 1 query: SELECT count(*) FROM node node LEFT JOIN location location ON node.nid = location.oid LEFT JOIN event event ON node.nid = event.nid WHERE (node.status = '1') AND (node.type IN ('event')) AND (location.country = 'us') AND (MONTH(from_UNIXTIME(event.event_start)) >= MONTH(from_UNIXTIME(1149406018))) in /hsphere/local/home/bgerwels/eventzip.com/includes/database.mysql.inc on line 120.
* user warning: You have an error in your SQL syntax. Check the manual that corresponds to your MySQL server version for the right syntax to use near ';= MONTH(from_UNIXTIME(1149406018))) LIMIT 0, 10' at line 1 query: SELECT node.nid, node.title AS node_title, node.changed AS node_changed, location.name AS location_name, location.street AS location_street, location.additional AS location_additional, location.city AS location_city, location.province AS location_province, location.postal_code AS location_postal_code, location.country AS location_country, location.latitude AS location_latitude, location.longitude AS location_longitude FROM node node LEFT JOIN location location ON node.nid = location.oid LEFT JOIN event event ON node.nid = event.nid WHERE (node.status = '1') AND (node.type IN ('event')) AND (location.country = 'us') AND (MONTH(from_UNIXTIME(event.event_start)) >= MONTH(from_UNIXTIME(1149406018))) LIMIT 0, 10 in /hsphere/local/home/bgerwels/eventzip.com/includes/database.mysql.inc on line 120.

I've got Drupal 4.7.2 installed. What version have you tested this module on?

That query looks perfectly valid to me; that's not node_access mucking it up.

What version of MySQL are you running?

I'm using MySQL - 4.0.24

I updated my views and event modules and now I'm getting a different mysql error:

* user warning: You have an error in your SQL syntax. Check the manual that corresponds to your MySQL server version for the right syntax to use near '; MONTH(from_UNIXTIME(1149478879)))' at line 1 query: SELECT count(*) FROM node node LEFT JOIN location location ON node.nid = location.oid LEFT JOIN event event ON node.nid = event.nid WHERE (node.status = '1') AND (node.type IN ('event')) AND (location.country = 'us') AND (MONTH(from_UNIXTIME(event.event_start)) > MONTH(from_UNIXTIME(1149478879))) in /hsphere/local/home/bgerwels/eventzip.com/includes/database.mysql.inc on line 120.
* user warning: You have an error in your SQL syntax. Check the manual that corresponds to your MySQL server version for the right syntax to use near '; MONTH(from_UNIXTIME(1149478879))) LIMIT 0, 10' at line 1 query: SELECT node.nid, node.title AS node_title, node.changed AS node_changed, location.name AS location_name, location.street AS location_street, location.additional AS location_additional, location.city AS location_city, location.province AS location_province, location.postal_code AS location_postal_code, location.country AS location_country FROM node node LEFT JOIN location location ON node.nid = location.oid LEFT JOIN event event ON node.nid = event.nid WHERE (node.status = '1') AND (node.type IN ('event')) AND (location.country = 'us') AND (MONTH(from_UNIXTIME(event.event_start)) > MONTH(from_UNIXTIME(1149478879))) LIMIT 0, 10 in /hsphere/local/home/bgerwels/eventzip.com/includes/database.mysql.inc on line 120.

The problem with this query is I think a little more clear. The problem is with this line:
(MONTH(from_UNIXTIME(event.event_start)) > MONTH(from_UNIXTIME(1149478879))) LIMIT 0, 10

the > should be a ">"

The question is where do I find this in the code?

Sorry about that last post. I forgot about the html excaping. Here's the error message I got:

• user warning: You have an error in your SQL syntax. Check the manual that corresponds to your MySQL server version for the right syntax to use near '; MONTH(from_UNIXTIME(1149481625)))' at line 1
  query: SELECT count(*) FROM node node LEFT JOIN location location ON node.nid = location.oid LEFT JOIN event event ON node.nid = event.nid WHERE (node.status = '1') AND (node.type IN ('event')) AND (location.country = 'us') AND (MONTH(from_UNIXTIME(event.event_start)) &gt; MONTH(from_UNIXTIME(1149481625))) in /hsphere/local/home/bgerwels/eventzip.com/includes/database.mysql.inc on line 120.
• user warning: You have an error in your SQL syntax. Check the manual that corresponds to your MySQL server version for the right syntax to use near '; MONTH(from_UNIXTIME(1149481625))) LIMIT 0, 10' at line 1
  query: SELECT node.nid, node.title AS node_title, node.changed AS node_changed, location.name AS location_name, location.street AS location_street, location.additional AS location_additional, location.city AS location_city, location.province AS location_province, location.postal_code AS location_postal_code, location.country AS location_country FROM node node LEFT JOIN location location ON node.nid = location.oid LEFT JOIN event event ON node.nid = event.nid WHERE (node.status = '1') AND (node.type IN ('event')) AND (location.country = 'us') AND (MONTH(from_UNIXTIME(event.event_start)) &gt; MONTH(from_UNIXTIME(1149481625))) LIMIT 0, 10 in /hsphere/local/home/bgerwels/eventzip.com/includes/database.mysql.inc on line 120.

the &gt; should be a ">"
On line 500 of the event_views module we have:

$query->add_where(strtoupper($filterinfo['type']) ."(from_UNIXTIME(event.event_start)) $filter[operator] $compare");

if I change it to:
$query->add_where(strtoupper($filterinfo['type']) ."(from_UNIXTIME(event.event_start)) > $compare");

(taking out "$filter[operator]" and replacing it with ">")

It seems to work fine, but of course I can't change the operator. Any thoughts?

It looks like this is a problems with the views module:

http://drupal.org/node/66928

I would like to further voice my support for a calendar view, thanks for all your hard work Karen. If you need feedback or ideas regarding the calendar feature please let me know, I would be happy to provide input.

There is now a project set up for this at http://drupal.org/node/67060 where you can post bug reports and feature requests. I have a calendar view mostly working, but not yet committed to cvs. I'll put a notice up on the project site when it's ready.

And to nikle and others, I welcome any and all input and ideas. There are lots of interesting things that could be done with this module.

so this is the correct place for this issue, isnt it?

thanks for your work karen!

I'm changing the status since this is no longer a patch. I'll leave it open for now in case others want to see the history behind the module.

This has been accomplished, so I'm marking this as fixed.