Currently, if you say that a certain node type has events "enabled", then ALL such nodes must fill out event info.

I would like to see either an enable or disable checkbox on node creation. e.g. when creating a blog/story/book/page post, I can decide whether it represents an event or not. There could be a setting to determine whether event is enabled or disabled by default.

I see this as critical, otherwise you "lose" a core node type to events, esp. if you are not running flexinode. Right now, event seems to be fundamentally tied to flexinode. I mean, you even have to run event + location.module to get back the functionality of the 4.5 events module.

Comments

crunchywelch’s picture

The change to a flexinode-type system for event is the first move in migrating towards the CCK model. Is there some reason you would not want to run flexinode? It (or it's predecessor) will be part of core in the next release or two if I remember correctly.

I'm not sure what you mean by having to run location with events to get he same functionality. What functionality did the old event have that location provides now? A location field? There was no real functionality around that afaik, so flexinode with a location field provides the same as 4.5 and then some. If you want radius searching, etc, then event + flexinode + location is a pretty powerful combination.

Can you maybe clarify this request? I'm not sure what making individual nodes able to post to the calendar solves. Do you mean maybe adding a date input checkbox to disable date collection for event-enabled types?

boris mann’s picture

Do you mean maybe adding a date input checkbox to disable date collection for event-enabled types?

Yes, exactly. That would be the main point of this feature request...sorry for rambling about the other stuff: still have to think what a "default" event-enabled flexinode would look like for migration purposes.

jhriggs’s picture

If I am understanding Boris correctly, I agree with him. ;-) I like that event is getting some much-needed attention, and it is definitely making progress.

That said, though, I don't like the current implementation of having to specify certain types that become events...and that all occurrences of that type must be events on the calendar. Although I think the goal of the implementation is to be flexible (and it is more flexible than the old version), I -- and my users -- find it confusing and difficult to use. This may partly be because of a lack of documentation at the moment, though.

What I would like to see is that rather than designating specific types that can be events and having every occurrence of that type be an event, any node could optionally become an event. This would be much like the product module in e-commerce. If you have not seen product.module in action, try it. This way, I could make an image, blog post, book page, or a flexinode type into an event when appropriate. Once the node is created, users with correct permissions have a tab displayed on the node page where they can make it into an event by specifying start/end times. There would be no event interface on the node submit/edit page.

crunchywelch’s picture

I think that it is possible to have the best of both worlds here. I like the ecommerce model, however I also know that having a specific event type that always has event fields in the creation page is less confusing for my clients, the extra step makes no sense when creating a 'house party' node or something that will always be on a calendar.

Architecturally, it would be a somewhat subtle shift to make individual nodes of types that are not specifically enabled be assigneable to the calendar in more of a 'one-off' fashion.

I understand the paradigm shift is a little hard from the admin/developer standpoint, but if you create a flexinode called 'event' it makes more sense to users who just want an 'event' calendar and could care less about assigning pages or blogs posts to the calendar. In this case it makes sense to always have date input fields on the node form, having them hidden or in a second step is counterintuitive.

To sum up I think that:
- the current model is valuable because when you have a node type that is date/event oriented you always want date values
- boris' suggestion is also valid since you may want to do 'one-offs' and assign a blog or story to the calendar as well

This suggests perhaps having two models of date input, which should be thought out carefully to not make the UI inconsistent.

Does this seem right?

crunchywelch’s picture

Assigned: Unassigned » crunchywelch
Priority: Critical » Normal

Assigning this to me and shifting down the priority since it does not break things already implemented.

boris mann’s picture

The only point I would add Aaron is that you should put a note in the project description about using flexinode.

And yes, jhriggs, you understand my ramblings exactly correctly and framed the issues better. Aaron, I'm not advocating (necessarily) the e-commerce like functionality, but I think we agree that there needs to be an opt-in/opt-out per node.

bomarmonk’s picture

I second the check-box idea! Example: I'm using filestore2 to upload files to my Drupal site and I want files to be event-enable. Why? Because some of these files are agendas for upcoming minutes! However, right now enabling filestore2 with events means that every document and form must also be sent to the calendar. This is not desireable. Implementing a checkbox upon the creation of an event-enabled node would help significantly: the agendas can be selected to go to the calendar and the other documents can just go to the file directories.

Thanks for listening. Boris's initial request may have gotten lost in the density of the discussion here!

bomarmonk’s picture

I second the check-box idea! Example: I'm using filestore2 to upload files to my Drupal site and I want files to be event-enable. Why? Because some of these files are agendas for upcoming minutes! However, right now enabling filestore2 with events means that every document and form must also be sent to the calendar. This is not desireable. Implementing a checkbox upon the creation of an event-enabled node would help significantly: the agendas can be selected to go to the calendar and the other documents can just go to the file directories.

Thanks for listening. Boris's initial request may have gotten lost in the density of the discussion here!

bomarmonk’s picture

I second the check-box idea! Example: I'm using filestore2 to upload files to my Drupal site and I want files to be event-enable. Why? Because some of these files are agendas for upcoming minutes! However, right now enabling filestore2 with events means that every document and form must also be sent to the calendar. This is not desireable. Implementing a checkbox upon the creation of an event-enabled node would help significantly: the agendas can be selected to go to the calendar and the other documents can just go to the file directories.

Thanks for listening. Boris's initial request may have gotten lost in the density of the discussion here!

sethcohn’s picture

Bump. Bump.

With the new event code, adding a particular node type (for example project issues), you now have to set a date for ALL of the nodes. What if I only occasionally want an event made from a particular node?

Making this optional would be "Would you like to set a event date for this node? Click the checkbox to ungray and set the date"

Cvbge’s picture

Hello.
I +1 checkbox idea.

I'd like to be able to specify in the settings if the event is enabled/disabled by default for each node types.
Then, at node creation, there would be another checkbox (checked or not, depending on the default settings) that would make this particular node an event node or not.

This is because I have some node types created with flexinode that are made only for event, and some types ('page') that generally are not used as events, but in some cases they are.

This also creates some problems in calendar view, as the node type is displayed in the calendar, and 'page' does not say anything usefull and it'd be nice if you could disable it.

About not running flexinode: general rule should be: if you don't need it, don't run it! Less code == less bugs (for example quite recent critical security bug in flexinode).

robertdouglass’s picture

For anyone interested in seeing this happen, check out this patch which suggests a solution for making arbitrary nodes events. There are still questions about interface but I just wanted to point out that these two issues are related.

munga’s picture

For anyone interested in seeing this happen, check out this patch which suggests a solution for making arbitrary nodes events.

Robert, where can I find this patch ?

p

matt westgate’s picture

I too would like to optionally tag nodes as events. In the ecommerce package, I created a 'product' tab (visible on the node form) that one could click to optionally make any nodetype also a product. I think this may be a good model for events as well.

Currently, as soon as you flag a nodetype as an event, it can't be used for anything else but events. I only want some pages as events, not all pages.

Love the iCal support, however.

jose reyero’s picture

Posted a patch adding this feature and also addressing some other related problems

http://drupal.org/node/24215

robertdouglass’s picture

This is the patch I referred to on June 6th but forgot to post the link:
http://drupal.org/node/23793

Dave Cohen’s picture

In my case, I have event nodes which should all have dates, but sometimes the date is not known. I'd like to be able to create the node with date "To be determined". Later the node will be updated with a date, and then I'd like it to appear on my calendar.

It seems like there are two patches out there aimed at pretty much the same thing. Forgive me for suggesting another approach: add a new choice to the month pull down called "no date". If selected for the start date, the event node does not appear on the calendar. If selected for the end date only, the event has a start but no end.

Or equivalently, a simple "enabled" checkbox next to the start and end date fields.

Rainy Day’s picture

Just wanted to say i agree with Boris. In fact, i had made a similar request here.

Although i had similar feelings about losing a node type, turns out it is relatively straightforward to add a new node type without resorting to flexinode.

Even so, the ability to control events on a node-by-node basis would be very nice. And it would help to avoid calendar clutter too.

japerry’s picture

Status: Active » Closed (outdated)

Event for Drupal 8 is unrelated to older versions. If an issue similar to this one exists, please open a new issue with the 8.x branch.