Central NJ Drupal meetup February 10

I discussed my primary (and frist) project with subsets of people from the last two meetings. Basically, users sign onto the site, provide some personal information to convince that they are eligible to vote, I add them to a role that is allowed to submit on a webform. The webform is configured to allow only one submission per account. so far, so very good. I got this far with no manual coding. I decided at the end of the next meeting that I would tackle the next item with a customized module. So far, I have only given it a little more thought. I should have some time between now and the next meeting to consider it further. Here is the situation: In addition to being validated as eligible to vote to begin with, there are variable elements of the account holder that might make her or him ineligible for voting. Most likely situation is that two account holders own the same property. Each property is eligible for one vote. If homeowner A has submitted a vote, homeonwer B should be disallowed for also submitting a vote for the same property. Ideally, homeowner B gets this bad news before going through the steps of voting. Another scenario is that the homeowner is delinquent in the payment of dues. That seems a little more straightforward so long as there is a place prepared to indicate this information.

I have learned that it is quite trivial to add information from the user's profile to the submitted webform. I think comparing, in a running process, the identifier of the voter's property against the list of properties that have already cast a vote should do it. Would I then direct the voter to a specific page explaining their property has already voted?

I will keep plugging at this. Hopefully not too much meeting time will be needed.

try: http://acquia.com/downloads/windows-installer

We discussed this previously in regards, for example, to Views where you can make changes in the UI and then export to code. See: http://groups.drupal.org/node/26003#comment-91940

For other settings, a typical best practice is to create update functions so you can test in your development environment updating from your live DB. The easy case is calling variable_set() to change simple settings that you would enter on a settings form. You can also but creation or updates to content types in update functions.

For example, some of the functions from http://drupal.org/project/install_profile_api can be used to import content types.

People recently have been using the Features module to manage some of this, but my experience with it has been mixed.

In general, the approach is to use a (scrubbed) version of the live DB, bring that into the development environment, and then use code to make any needed updates or configuration changes and test those changes. Or, for more trivial changes, test them in the development environment and then make them manually on the live site.

http://groups.drupal.org/node/50378

As David posted above. Hopefully this will reach everyone as a reminder via email.