[D7] Webform event

Added git clone link

Fixed to 7.x-1.x as working branch.

Git clone link

I'm pretty sure it has some overlap but I think this module provides fairly solid tools for events like queue handling and adaptive administration pages. I'll check that module out and compare functionalities.

After quick test run I noticed following differences:
- Queue handling is different, seems registration wait list registrations eat up space (They're on wait list and people can sign up as wait list even there is space). Webform event does this differently. It enables queue only when the event is full and there is no queue to handle. Queue is also protected so that when working with signups and cancellations no one can signup if there is queue before them. Spots belong to those who queued first.

Note on registration:
https://www.evernote.com/shard/s61/sh/b8b44a89-4e35-4d5b-a13f-29510aa647...

- Webform event uses webform as base, it brings all webform functionality to users and can be extended with webform compatible modules and rules aswell as views integration from webform module later on. Webform 4 brings also nice token support. People can customize registrations as they wish.

- Register has slots, register other person/account which is very nice, good idea to bring into this.

- Register registration types create their own permissions per type, this can get very painful to manage and is hard to administer. Seems register is suited to sites that have only few different events while webform event provides per webform management fast out of the box. Imagine having 50 events that are customised, you would get around 1000 permissions to manage. Webform event is more generic and easier to maintain and familiar UI to anyone used webform before.

- Webform event handles waitlist and cancellations efficiently by providing automated admin tools (User cancels, admins get per event notification about cancels and other submissions that user has left for easy identification and handling.

- Webform is also easy to integrate to rules and uses date module for ending dates.

- Register has mass email, this can be achieved via webform easily by using contrib module (This I might add in actually).

- Also register types are tied to all content they're applied to. It might be good thing in certain cases and in other (Like add one field for this event only) you would need to create completely new type and set permissions etc because you can't change per event basis. This can be achieved via node clone in webform event but it maintains per event customisations.

In general, they're very different beasts with strengths and weaknesses. But hey, it's good to have options. I can easily see use cases for both modules where other module wouldn't produce desired effect.

Webform event is event system for webform that fits nicely within its workflow while registration is its own seperate environment.

Updated wording

switched wf_queue to webform_event. Had in progress module name left there.

Thanks drastik, will definately add them.

Hi leemako.
You can easily copy existing webforms with node clone. I will be adding more features as time goes (Reserving slots is on its way and almost ready at the moment) but we need to remember that this module is still very fresh and in queue (Comparing to registration that is standalone module with multiple devs and a year of development while this module has around 4 working days).

You got some nice ideas of features there. Keep them coming and I'll document them for myself. When I have time I will be adding more features to the module and having good feature suggestions available is handy.

Module is updated to include slot registrations. On side note, please keep this thread about this module.

Removed features from dependency

Hmm, that sounds more like fringe case as that kind of quality is not needed for all events thus it will not be included. One thing I might implement though is ability to reference events from other node types. But I'm not there yet. You can achieve something like that with webform conditionals like having select with:
1. Parent
2. Parent and Child
3. Child only

and conditioning other fields accordingly. Downside is that it's not real reference but I'm not exactly 100% sure that child would have an account?

Improved uninstall, added hook_disable() and made module play nicely with entity_reference. Code cleanup, readability and documentation enchancements.

Added new feature

Argh, what a timing. Just pushed some major changes was fixing pareview errors :D Well, talk of bad luck... Fixed anyways.

Changing status back.

You must have previewed after 2mins I pushed latest changes after coder code review and was just checking pareview notices :D

Seriously? Do you think this really warrants pushing module review 5 weeks further or prevents community from using the module? I recall that according to project review guidelines minor changes to documentation / styling stuff does not warrant needs work if they're only "issue". This is afterall under development and README.txt is not critical / functional or main focus.

Doesn't warrant pushing approval months away. Changing back.

No offense but it is a little bit nitpicky to delay module releases for stuff like flavor questions on stylings on non-functional stuff.

http://drupal.org/project/1914080/git-instructions Check out from there.

I tested the url and it worked for me straight copy paste.

http://pareview.sh/pareview/httpgitdrupalorgsandboxdemoshane1914080git

Fixed issues (Hopefully something doesn't change again in PAReview logic before this gets another look).

Will improve the readme when this gets accepted (and I can squeeze a little bit more of time from customer projects).

Changing status

Fixed all issues. Wrong status?. Now back in needs review state

Ok, I have to get some things clear:
1. I don't have contributor status, that might prevent me from acting as co-maintainer for the D6 version?
2. The D6 version seems to be very very simple implementation compared to this one. Also for time restrictions I would not be able to develop D6 version.
3. I'm not competiting with anyone. This is a something I built in customer project and decided to turn into contribution module because Drupal 7 lacks this kind of functionality and I though this would be useful. I fail to see how this is competing as D6 version is completely different beast and seems to be abandoned.
4. I seriously can't arrange enough time to rewrite this module in terms of the D6 webform_events nor that would make any sense (if that would be required, or is this just about getting the namespace?).

That being said: I'll contact the original creator of the module and ask what he is going to do with the project if anything.

@kschreider: Thanks, I'll check the variables.