My name is Mack Hardy, I am the technology manager for a non-profit called Post Carbon Institute.
Post Carbon Institute is running OG for its Relocalization Network (http://www.relocalize.net/grouplist). We all need communication tools to organize, only when we are organized can we be effective. We want to enhance og2list so that our users can choose to use email as the primary interface to other people in their groups. OG2List is promsing, but has a couple outstanding features which we are going to fund further development of.
The scope of the next stint of work will be:
Mail Handling
- handling of inbound mail attachments to linked files
- addition of basic virus checking to files from mail
Multisite Support
- configure more than one mail domain on a single og2list backend
- configure the mail processing engine of og2list to talk to more than one database, depending on delivery domain
As an organization, the choice is always to build or buy, but with the drupal community when you contribute to development of key features like these you are enabling the community to continue to grow and prosper. Post Carbon Institute is committed to the continued development of the og2list functionality. Estimated cost for these improvements $2500, civicspace has already offered a rate reduction on this body of work.
Post Carbon Institute is willing to contribute up to $1500 for this work.
That leaves $1000. Support development on this module by posting a pledge as a comment on this page.
Contact Kieran From Civicspacelabs for more information on making a contribution.
Thanks to all the developers and testers who have got og2list this far...
-M
Here is more information on the history of the funding of this module.
http://drupal.org/node/59785
http://www.bryght.com/tags/reverse-bounty
Comments
We'll contribute $100
If I understand you, you're talking about using a single instance of og2list to work across multiple domains, sort of like the sites directory in Drupal. If that is indeed what you're talking about, we'll kick in $100 toward that.
-Derek
http://www.enthusiastgroup.com
Thanks for your support!
Yes thats what I am talking about, we want to be able to run sets of lists, related to separate drupal databases.
Configuration will be file based to start i imagine, but I would like to extend it to be configurable through LDAP or similar.
-M
I'm interested but ONLY IF SHARED HOSTING setup becomes easier
I would be willing to make a small financial donation if the og2list setup in a SHARED hosting environment was made a bit easier.
For the average Drupal user, I believe it's too difficult to set up og2list on a SHARED host at this time as per a reference to og2list documentation and the follow-on comment found here.
I'm trying to find out What SHARED hosts can support og2list?, if any.
Walt Esquivel, MBA; MA; President, Wellness Corps; Captain, USMC (Veteran)
$50 Hosting Discount Helps Projects Needing Financing
Walt Esquivel, MBA; MA; President, Wellness Corps; Captain, USMC (Veteran)
$50 Hosting Discount Helps Projects Needing Financing
Multi-domain solutions address part of the problem
How are you proposing we solve the issue of whether or not your hosting provider allows you to change the mail configuration?
This isn't a technical problem that can be solved with code, it's a problem with your hosting provider. If they control the mail server, and won't give you access to change the configuration, how can you expect OG list manager to access it?
Kieran
To seek, to strive, to find, and not to yield
< a href="http://www.youtube.com/watch?v=COg-orloxlY">Support the Drupal installer, Install profiles, and module install forms
<a href="http://ia310107.us.archive.org/1/items/organicgroups_og2list/dru
Would this work?
Most host give you a minimum of 5 email addresses. How about if you defined a lists address that is used by this tool as it's main distribution address? Or does this module need a unique address per group?
Mail server must call Perl code when mail is recieved
Mail servers allow for configuration rules based on domain. When a mail comes into newgroup@example.com the mail server looks up the rules for dealing with domains and see that there is a rule for example.com. It executes that rule and calls the mail-in.pl Perl code. The perl code processes the mail and puts it into the Drupal database when og list manager converts it into forum topics.
So if you can't access the mail server configuration, the Perl code can't be called, and then you can not run OG list manager.
Hope that helps.
Kieran
To seek, to strive, to find, and not to yield
< a href="http://www.youtube.com/watch?v=COg-orloxlY">Support the Drupal installer, Install profiles, and module install forms
<a href="http://ia310107.us.archive.org/1/items/organicgroups_og2list/dru
Solution Description for Comment
I'm posting a solution description is to glean insight and direction from greater minds. Please review and respond to the following.
Understanding the possible limitation of not having access to master.cf as well as the necessity that all incoming mail be routed through mail-in.pl, it seems logical to do the routing in mail-in.pl.
What I conceive is to have a configuration option in mail-in.pl which directs it to consider multiple domains.
The values of the configuration option (ie: routing_type) will be directives indicating behavior (ie: NONE, LOCAL, DATABASE).
NONE will be the default and will provide the present behavior of honoring the mail.conf to do the appropriate database inserts for the incoming mail.
LOCAL indicates that the localhost has multiple drupal instances on unique domains. The LOCAL directive will use the domainname of the incoming message to determine which version of mail.conf to employ for performing the necessary inserts (ie: example.com:mail.conf).
DATABASE indicates that the domains are not co-located and the message must be forwarded 'off host'. DATABASE will instruct mail-in.pl to query to discover the appropriate receiving host details. (Table definition to be determined)
Too, there is the complexity of validating user's by consulting the og2list_groups table for each of the configured domains. Presently, this is a function of the condition = tag in the .cf file. To achieve this, the validate-recipient.pl script could be required for multi-domain configurations wherein the script is modified to support the LOCAL and NONE routing_type directives.
Multi domain configuration - Looks good
Hi
The proposed solution sounds good. I agree that routing should be done by mail-in, it already needs to be configured and the less work to do in MTA configuration, the simpler the setup for the end user. I envision a separate mail domain per site, and a separate set of database info per domain.
Mail-in would be the same code for any of the domains, so I imagine the configuration could organized similar to the drupal sites/ scheme.
Whether you add a mail.conf file for each domain, or create an array of configuration info in a single file this seems like a sane way to do things.
The DATABASE setting - would this be used to query a central db for configuration information for the given domain? Not sure when a user would need this, unless you were running a large number of mail domains and need to make changes through the web to the configuration info?
One caveat would be that the configuration should be db table prefix aware - so that users could run multiple sites in the same DB if they had to.
Keep up the great work,
Thanks
-M
Excellent points! Thanks Amazon!
Thank you for your reply, Amazon. I very much appreciate your insightful and informative replies.
I apologize because I'm ignorant as to how og2list can be set up in a shared versus non-shared hosting environment. I can only learn by searching for the answer(s) and, not finding them or not completely understanding what I find, posting further questions as necessary. Here goes.
I think there are two issues here:
Issue #1. Your question, "How are you proposing we solve the issue of whether or not your hosting provider allows you to change the mail configuration?"
Issue #2. The perception that some modules appear to be very difficult to set up for an average Drupal user such as myself.
On issue #1, I need to research DreamHost to see what they do and do not allow me to do with respect to mail config. I have posted a question to see if anyone on a shared DreamHost server is currently running og2list and am going to ask DreamHost directly as well. It might very well possibly be that og2list is a no-go on DreamHost, and so issue #1 is irrelevant.
On issue #2, it appears to me that og2list falls into the "very difficult to set up" category after having reviewed the install documents. Perhaps it's a simple install like most other modules but only if one is on one's own server, i.e., a non-shared server? (Dedicated server? VPN server? This is another can of worms for me!)
Perhaps on a non-shared server one need only FTP (or use command line, of course) to get the og2list module files up to the server and simply enable the og2list module to have it up and running? Perhaps going through the og2list install document is only necessary after first determining that one's shared host (e.g. DreamHost) allows mail config changes? In other words, is the install document ONLY necessary if using shared hosting, or is it necessary regardless on both shared AND non-shared servers?
IF the install document is ONLY necessary if using shared hosting, I may simply need to:
a) bite the bullet and go with a non-shared server at such time that I decide to go with something like og2list;
or
b) if DreamHost allows mail config changes on its shared servers, decide to pay someone with the appropriate technical skills to install og2list on my shared DreamHost server;
or
c) skip og2list altogether
By the way, keep up the great work! I sincerely appreciate the things that you've done and continue to do for the Drupal community.
Walt Esquivel, MBA; MA; President, Wellness Corps; Captain, USMC (Veteran)
$50 Hosting Discount Helps Projects Needing Financing
Walt Esquivel, MBA; MA; President, Wellness Corps; Captain, USMC (Veteran)
$50 Hosting Discount Helps Projects Needing Financing
On your question
On your question #1
On your question #2
I think OG2List was develop this way because the original developers have the environment to do so and it was easier for them to implement it this way instead of doing much more work to prepare the system to a bunch of diferent variables.
Conclusion:
If porting OG2List to D5 or D6 it would be better to prepare it to work with Procmail or POP3/IMAP reading also besides MTA mangling.
You do realize that this
You do realize that this discussion is now over a year old, do you?
WRT procmail: That might already work.
WRT IMAP/POP3: This won't be implemented. Look at mailhandler/listhandler for this.
is multisite configuration possible
by using a unique transport for each domain with it's own line in master.cf that calls a unique mail-in.pl and its associated mail.conf file? seems like that should work; i haven't tried it yet, though.
Is this new version able to
Is this new version able to process emails from:
If so, I think it could work in most SHARED hosting environments.
If the plans are to continue with the complexity that it has today won't be very useful for a lot of people.
Damien, at this page seems to have it almost ported to Drupal 5. Did you contact him too?
This is also a very
This is also a very interesting article on procmail and maillists.
I think that if OG2List worked with Procmail (and with a pre-defined .procmail recipe template) it will be a major advantage.