Closed (outdated)
Project:
Event
Version:
5.x-2.x-dev
Component:
Code
Priority:
Normal
Category:
Feature request
Assigned:
Reporter:
Created:
16 Apr 2005 at 19:33 UTC
Updated:
13 Apr 2018 at 20:57 UTC
Jump to comment: Most recent
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
Comment #1
crunchywelch commentedThe 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?
Comment #2
boris mann commentedYes, 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.
Comment #3
jhriggs commentedIf 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.
Comment #4
crunchywelch commentedI 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?
Comment #5
crunchywelch commentedAssigning this to me and shifting down the priority since it does not break things already implemented.
Comment #6
boris mann commentedThe 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.
Comment #7
bomarmonk commentedI 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!
Comment #8
bomarmonk commentedI 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!
Comment #9
bomarmonk commentedI 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!
Comment #10
sethcohn commentedBump. 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"
Comment #11
Cvbge commentedHello.
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).
Comment #12
robertdouglass commentedFor 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.
Comment #13
munga commentedRobert, where can I find this patch ?
p
Comment #14
matt westgate commentedI 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.
Comment #15
jose reyero commentedPosted a patch adding this feature and also addressing some other related problems
http://drupal.org/node/24215
Comment #16
robertdouglass commentedThis is the patch I referred to on June 6th but forgot to post the link:
http://drupal.org/node/23793
Comment #17
Dave Cohen commentedIn 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.
Comment #18
Rainy Day commentedJust 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.
Comment #19
japerryEvent 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.