Raven Brooks of BuyBlue.org is sponsoring development by CivicSpace Labs to enhance the Organic Groups module in order to support local sub-chapters. All work will be placed into Drupal CVS so the rest of the community may benefit. The following is an outline of BuyBlue’s requirements, as well as identified areas of work that would be of general use to the community at large, and our plan of action on each item. Any feedback other developers have in terms of strategy would be greatly appreciated! We want this functionality to be useful to all types of organic group implementations, from BuyBlue to groups.drupal.org.

Clarification of intent -- README ;)

BuyBlue Requirements

Local Spaces

Local spaces will essentially be a homepage for each chapter within the BuyBlue site. This will allow members to coordinate economic activism at a local level within their own states, cities, and communities.

There are two levels of chapters: official and unofficial. Official chapters need to have gone through a rigorous approval process and as such are afforded additional privileges, such as the ability to submit evidence about companies in the database, and also things like the ability to add a custom logo to their group home page.

Specific requirements are:

  • Allow for front page blogging and announcements
  • Separate taxonomy terms for blog entries
  • Ability to create blocks for the locality to show various information on the homepage
  • Graphically distinct theme that shows only for the local page
  • Show events and volunteer opportunities.
  • Allow sign up and donations for chapter mailing lists.
  • User profile integration: If a user has selected a given locality then they'll have a link on all BuyBlue pages back to that homepage. (block)

Local events

Localities will be the grassroots arm of BuyBlue and as such we need to provide online event and volunteer management.

Requirements:

  • National events should be seen on all local calendars
  • Each local space should have their own calendar of upcoming events that they can update and maintain.
  • Registered users should be able to RSVP for these events.
  • Local administrators should be able to manage volunteers online and post volunteer opportunities for upcoming events
  • User profile integration: If a user has selected a locality then events and volunteer opportunities should follow them through the site (block)

Local Searching

Members should be able to narrow their search to just companies within a given locality, and local results should be highlighted when using the search engine.

Requirements:

  • Results indicate company is a local profile for locality X
  • Users can do an advanced search and limit their search to only local companies or local companies from locality X

Identified areas of enhancement

Organic Groups and Role integration

There needs to be a way to differentiate an “official” group from an “unofficial” group, and give users in each type different privileges to do different things via the access control administration panel.

Initial Assessment: The recent patch to let any node type become an organic group (http://drupal.org/node/18317) could be used in conjunction with a variation to the OG Promote contrib. module.

We would setup two different node types:

- Chapter
- Local Space

And create two different roles with respective permissions:

- Chapter member (ex: can create certain special node types as well as events)
- Local space member (ex: can only create events)

We then create an OG Roles module, which, for each og-enabled content type, will allow automatically assigning either a) group administrators, b) all group members to a given role.

Event privacy
BuyBlue wants the ability to restrict the viewing of events to group members only.

Initial Assessment: This actually now works “out of the box,” as long as OG’s settings are not “Visible within the targeted groups and on other pages” and when you associate it with a group you don’t check the “Public” checkbox! :)

Organic Groups each get their own Taxonomy terms
In order to allow each group its own list of blog terms, for example, each group needs to be allowed to create their own list of terms.

Initial Assessment: Implement the spec outlined at http://drupal.org/node/28693#comment-49384 -- this has the potential to be a huge boon, as it allows for everything from categorizing content to filtering content to establishing navigation.. all the stuff taxonomy can do, only for groups.

Additional Theming Options for OG
Raven would like official chapters to have the ability to upload a logo which is replaced in the default theme given to all groups.

Initial assessment: Create a module that defines a permission to upload a logo (can be used by the role in the OG-role discussion above) and uses hook_form_alter to add a logo upload box to the group create/edit form. We then use some funkiness at the theme layer to check for:

1. Are we within the context of a group? and
2. Does this group have a logo associated with it?

If so, show the custom logo in place of the site’s default logo.

Allow blocks to be associated with organic groups
Enhance the standard block admin interface so the site admin can create blocks that are displayed only for a certain group.

Initial assessment: Use hook_form_alter to add the “Groups” selection to the block configuration interface, so it could be an additional visibility setting in addition to page-specific visibility settings.

Group-based calendars
BuyBlue needs both national and local (group-based) calendars.

Initial Assessment: The national calendar is basically the default event calendar, which shows all (public) events across the entire site. The local calendars could then be implemented once each group is assigned its own term; taxonomy-filtering is built-in to event.module.

Location-based search
Allow searching state-wide in addition to within X radius of zip code.

Initial assessment: The gsearch module could be a) ported to 4.7, and b) enhanced to allow a “within the same state” selection. The state selection would then alter the query to check for nodes which matched where state = ‘XX’. Some 4.7 clean-up is needed on Location module as well.

Events, RSVPs, and volunteer management
Local Spaces need to be able to create events and manage event subscriptions and volunteers.

Initial assessment: Event module for calendar, Signup module for handling RSVPs, and CiviCRM/volunteer module for managing volunteers. Volunteer module will need to be ported to 4.7. Need to investigate into existing OG <=> CiviCRM module.

---

Thanks in advance for any additional insight anyone of you can offer into any of these items! And just a reminder that CivicSpace Labs is hiring developers and looking for partners to collaborate and split development costs on these and other items in order to help speed delivery. If interested, please contact Kieran Lal.

Comments

venkat-rk’s picture

Sounds astounding. Thanks for sharing this with the community in such detail.

moshe weitzman’s picture

thanks for the nice writeup. the approach looks excellent to me. Here are some notes. i'm available for implementing any items which CSL wants to hand off:

Organic Groups and Role integration
- perfect. it might be worth asking the community what they want for role integration so it is widely useful as possible. i suggest conversing at http://drupal.org/node/17887

Event Privacy
- In addition, you may hide that Public checkbox from non admins via settings. One enhancement that you might need to is to let each group admin decide the visibility defaults for his group. That's http://drupal.org/node/43940

Additional Theming Options for OG
- I propose that this is just the 'group image' feature that exists in 4.6 but not 4.7. It is up to the theme layer to place the image as needed. By default, we should put it in the DIV where the Welcome message is now. For 4.7, I suggest using the upcoming imageapi module which allows any node type to have image upload capability. Bryght/walkah will be committing this this week.

Allow blocks to be associated with organic groups
- Your proposal is a fine start. Even better though would be to enable the group admins to manage their own blocks. Requires a new UI, and possibly changes to block infrastructure (in order to determine the active blocks). I haven't thought about it too much.

Group-based calendars
- Sounds good. We might need to tweak event module so it doesn't present links that break you out of the group context

Location
- probably needs a fuller spec. Would be nice to have location+group for groups.drupal.org.

Unit testing
- I have commissioned ThomasL to write unit tests for almost all existing og functionality. Mnay of those are already in HEAD/4.7 branch. It is highly recommended that we write unit tests for new functionality. I might get to the point one day where I won't accept a patch that doesn't have associated unit test. FYI to all, the Drupal unit testing framework is described at http://drupal.org/project/simpletest. There are extensive docs there and on the Simpletest web site.

rbrooks00’s picture

Allow blocks to be associated with organic groups
- Your proposal is a fine start. Even better though would be to enable the group admins to manage their own blocks. Requires a new UI, and possibly changes to block infrastructure (in order to determine the active blocks). I haven't thought about it too much.

Moshe, actually the original proposal for this was something very much like you are describing here. We opted to go with the approach above mostly because it was a lot less risky and was a huge savings in hours and basically bought us the same thing. There is a little compromise in that group admins can't fully control the blocks on their group (as your proposal would allow) but that was something we were willing to live with for this release.

Something like that would still be a great add-on project though.
============================================
BuyBlue.org

jasonwhat’s picture

This all looks great. Here are a few thoughts, and one big suggestion.

Both taxonomy and menus become very important if someone is within a chapter/group.

Taxonomomy: Admin should be able to set persistent taxonomy terms that are available in all chapters or groups of a specific node type. Every chapter will probably have some base terms that are always the same and thus, should be automatically created when the chapter node is submitted. Or, a better approach may be to have admin set one "persistent" vocab with the terms, but not create new sets of these terms for each chapter as taxonomy would get out of control. Perhaps some og_views logic can be used to create some views instead, i.e. (show all nodes with term "products" and "og/2" here).

Menus: There should probably be admin ability to set persistent menus that will show within each group as well as some group admin created menu items. These obviously would be in a block, but what about having some ability to even make primary links group aware?

Access and Promote: Group managers and/or admins should probably be automatically promoted to a new role. Group admins promoted by the "manager" should have some access logic. For example, it may be helpful if they can act as editors and have edit permissions for any content within their group. This may already exist, but group managers/editors should have some way of keeping unwanted content out of their group views.

Group themes: Can/should gropus be able to choose a theme?

Main site cloning and multi-group nodes: This may not be useful in your situation, but I think it could be for several chapters/groups. Often, a smaller group doesn't have a ton of content, but they want a look and feel of their own space on the web. In the past, I've setup chapters that are just subdomains parked on the main site, but the subdomains have their own look as long as you are within that url, so unless a user clicks a "go to national" type link, they will think all this content is on the chapter site. This is great because most chapters have a lot of content they share anyways, such as about us and faq type info, and it gives national some control about what all their chpaters are saying along these lines.

So how could this translate for this project? One way is to use some url logic such as that used in the "referrer theme" module so that when a user clicks on a chapter site from within the main site or an external referrer they are taken to a page with a different theme that looks like they are on a whole new site.

Another way to handle this is to have some shared group nodes. These are admin created nodes that exist for all groups, (again-thinks like about us and faq, and chapter membership requirements) but a user viewing them within one chapter/group, stay within that group to view that node. So if I click the "about us" link while vieiwng a "Nebraska" chapter/og node, I'm taken to the "about us" page that show for all chapters, but I still have the same menu and theme logo as the Nebraska chapter. It's as if the node belongs to the Nebraska chapter, but really it belongs to all of them. This is what I mean by multi-group nodes.

Newsletters: Maybe a hook into simplenews and/or civicrm to create a newsletter for each chapter/group

Maps: Maps are great. I'm still trying to figure out what happened to the projects to bring in google maps for locations of nodes. In addition to mapping users, it would be cool to map chapters and groups.

Finally, my one big request would be subgroups. There may be members of one state chapter that want to form a group within that chapter. It would be great if the state chapter could push content down to the subgroups. I know this is a whole big topic, but I thought I'd throw it in there.

drupalec-1’s picture

Does Moshe's comment on 55594 mean new og will work together with other node access modules?

http://drupal.org/node/55594
http://drupal.org/node/23193

Walt Esquivel’s picture

From my post at http://drupal.org/node/59058, I had written that although I think organic groups is an excellent module, I'm just a bit leery of using it due to the fact that I can't use OG and Taxonomy Access Module together at the same time from what Robert Douglass wrote in Chapter 4, page 131 of his excellent book, Building Online Communities with Drupal, phpBB, and WordPress: (thanks Robert!)

Organic Groups isn’t the only module in the contributions repository that implements node-level access controls. Other modules that provide access controls are Node Privacy by Role (http://drupal.org/project/node_privacy_byrole), Taxonomy Access Control (http://drupal.org/project/taxonomy_access), and Nodeperm Role (http://drupal.org/project/nodeperm_role). Unfortunately, these modules tend to interfere with each other. This is a basic weakness in the way Drupal’s permissions are handled and is a topic of hot debate in the developer community. Be warned: do not try to mix multiple node-access modules!

Is there a way around this weakness? There may be other node-access modules I want to use concurrently in the future so if Moshe's comment on 55594 provides a solution to the issue, that's terrific!

-----
Walt Esquivel, MBA, MA, Captain - U.S. Marine Corps (Veteran)
President, Wellness Corps, LLC
-----
Drupal Users and Developers by Geographical Location
http://drupal.org/node/46659

venkat-rk’s picture

I don't know if this is feature creep, but another thing that would be terrific in this context is to have subdomains that map to specific national chapters/groups of a company or organisation. For example, if Buyblue had a chapter in Georgia, then something like georgia.buyblue.org would be incredibly useful to have.

Someone from Indymedia already requested this in the SoC2006 post.

Walt Esquivel’s picture

ramdak,

Your subdomain suggestion is EXACTLY what I was thinking and you beat me to suggesting it! :)

Here's my example:
http://www.nshmba.org/chapters.asp

From there, click on any chapter, such as Austin, and you'll see it leads to a subdomain:
http://austin.nshmba.org/

-----
Walt Esquivel, MBA, MA, Captain - U.S. Marine Corps (Veteran)
President, Wellness Corps, LLC
-----
Drupal Users and Developers by Geographical Location
http://drupal.org/node/46659

killes@www.drop.org’s picture

Should be easy enough to set up in .htaccess or httpd.conf
--
Drupal services
My Drupal services

greggles’s picture

Killes,

I'm not sure how to do this. Can you enlighten us on this one?

Can I drag this thread back to life 6 months after the fact?

--
Knaddison Family | mmm Beta Burritos

adrian’s picture

url() doesn't break when you use external url's anymore.

So you could alias all the nodes to http://domain.site.com/post-goes-here

This would require some changes to pathauto (basically a way for it to get tokens from other modules) and ressurecting the single sign on module.

--
The future is so Bryght, I have to wear shades.

olav’s picture

I have set up an experimental site for hosting organic groups. The idea is exactly as you suggest, i.e. each group gets its own subdomain. I have followed these steps to achieve this effect

  1. In my name server, I have defined a wildcard entry * IN A 85.10.199.38
  2. I have told Apache to accept wildcard requests:
    ServerName tribe.de
    ServerAlias *.tribe.de
    
  3. in my sites/default/settings.php, I have included the following code
    ini_set('session.cookie_domain', '.tribe.de');
    $subsite = 'www';
    if (preg_match('/^([^\.]+)\.tribe\.de$/', $_SERVER['HTTP_HOST'], $matches)) {
      $subsite = $matches[1];
    }
    if ($subsite != 'www') {
      $conf = array(
        'site_name' => $subsite . '.tribe.de',
        'site_slogan' => '',
        'site_frontpage' => $subsite,
      );
    }
    

    This already gives me an individual front page for each subdomain. The first line takes care of authentication cookies to work across subdomains.

  4. In og.module (the organic groups module), in the list of my groups, I have hacked the group URLs to read http://GROUP.tribe.de instead of http://tribe.de/GROUP.

The last step is not yet the complete solution. I have experimented with the path_auto.module (which I use to generate http://tribe.de/GROUP URLs) to automatically generate the http://GROUP.tribe.de URLs, but my current problem there that base_path() seems to be prepended to any URL unconditionally. I haven't found a way yet to avoid this.

--
Olav Schettler contAire

--
Olav Schettler

drupalina’s picture

I've been trying to get this working for more than a month now. I want each new user to have his own new blog on username.example.com , and each new Groups to have it's homepage on groupname.example.com . I have noticed that you have managed to achieve something like this (and a lot more) on www.drupalsite.org and www.tribe.de

I have e-mailed you via your contact form on your profile on drupal.org, but I'm still waiting for a reply. Please help me, I have been searching and searching for answers on how to generate automatic subdomains throughout the drupal.org , but I can't get it to work.

For a start I need to get it to work on my localhost. But my apache httpd.conf doesn't have anything that is called ServerAlias, and the moment that I insert it, localhost stops working. Also I'm confused as to where to insert the wildcard (*) on my localhost.

Then, I need to make some changes to my site/default/settings.php (I use 5.1 now and will launch my site in 5.2). The changes that you wrote seem to be the thing that I need, but I can't get it to work -- I don't know what to change in the code that you provide above. What I need is: when the new registrant enters a username during registration, Drupal will take that username and automatically create username.example.com (which is where user's blog, profile, and files will appear).

I don't want each user to have his own database, because it is a social networking site and there will be a lot of shared information (in it's structure it will be quite similar to LiveJournal), but the most important aspect is Networking rather than blogging. But because the spead is my main concern, I still don't know whether all those thousands of blogs and hundreads of groups should be all on the same database, or should I create automatic databases for each one of them (like on tribe.de)??? The problem is that it is that I'm designing it for people who are not very technical.

Automatic subdomain generation is my number 1 priority. I cannot launch my site without it.

Would you please help me???

Many-many thanks is advance!

Torenware’s picture

Angie,

The BuyBlue work dovetails nicely with work we're doing for the Bioneers. I recommend looking at my design notes up at http://www.torenware.com/handbooks/civinode_design.

The key reason you'll want to look at this: CiviCRM has a very sophisticated notion of group membership; rather than simply an "opt-in" model, groups are logical objects, and can be defined by arbitrary queries. These are called "smart groups".

Since the Bioneers work determines membership in an organic group by membership in a CiviCRM group, we've effectively made membership in a group defined by anything you'd want -- payment of membership, living in a city or state, or a registered voter in a precinct or riding -- very easy to set up or to code for. I also suspect it would scale better than some of the other things you might consider.

Because the Bioneers' scheme leaves control of Drupal objects to the rest of the og machinery, the rest of what you are doing will work automagically with the Bioneers stuff. And if you adopt our auth scheme, what we're doing will automagically work for BuyBlue.

Rob

Rob Thorne
Torenware Networks
http://www.torenware.com

Rob Thorne
Torenware Networks

Neil Adair’s picture

+1 for this idea!
Especially in light of this announcement of CiviMember module for CiviCRM 1.5
http://civicspacelabs.org/home/node/16734

and the new search capabilities

Neil

rbrooks00’s picture

That looks like a good area to explore for the future, especially with respect to those that want to charge for membership in a certain chapter. I haven't explored the OG integration with the ecommerce module enough to know if that would be better (or already there). One of the main problems currently is that CiviCRM doesn't work on 4.7. It seems like that would have to be a big work effort for them, I haven't seen any kind of posting on when that is planned.

============================================
BuyBlue.org

Walt Esquivel’s picture

One of the main problems currently is that CiviCRM doesn't work on 4.7.

I believe you meant CiviCRM 1.5 doesn't work on 4.7, correct?

http://www.openngo.org states:

...and v1.4 is compatible with Drupal 4.7 and MySQL 5.0.

-----
Walt Esquivel, MBA, MA, Captain - U.S. Marine Corps (Veteran)
President, Wellness Corps, LLC
-----
Drupal Users and Developers by Geographical Location
http://drupal.org/node/46659

rbrooks00’s picture

Oh have they updated? Excellent, that was news to me.

============================================
BuyBlue.org

Walt Esquivel’s picture

I believe CiviCRM is something a lot of folks can use for their organic groups, so please take a look at this link to look things over.

Now is a great time for folks to take a look at whats coming in v1.5 and make sure that we have not missed any important things / issues. If so, please do start a discussion on our mailing list

Walt Esquivel, MBA, MA, Captain - U.S. Marine Corps (Veteran)
President, Wellness Corps, LLC
DreamHost Rewards Affiliate Program

webchick’s picture

First of all, I want to say thanks so much for the interest in this post. It's really cool to see all the excitement being driven around these enhancements, and people coming up with other really cool ideas, too. I need to clarify though that this thread is not, however, intended to be a "Name your pet feature for OG and make Raven pay for it" thread. ;)

Instead, what I would suggest to the people who've outlined features that seem to have popular support, is get together with others with similar interest and actually sit down and spec out the functionality -- what it entails, what existing solutions exist we could work from, what benefits it would have for the community, and some sort of "plan of attack." You could even go all out and formulate these into an actual Drupal Enhancement Proposal (DEP).

This would give us several options; we could talk about sponsoring it ourselves, we could seek sponsorship dollars elsewhere, or one of the volunteers from the community could pick it up and implement it, etc.

Burying suggestions in a thread though is not going to be the best way to get these features implemented.

jasonwhat’s picture

Thanks webchick, and I agree. However, aren't we discussing how "chapters" functionlaity should be implemented in Drupal. I know lots of feature suggestions start coming up, but I think we can have a useful discussion here about what people would like to see as the basics of "chapters," and from there discover if these will be implemented for buy blue or not. I could be off, but it seems that any "chapters" functionality should have terms for the og and og based menus to navigate through the chapter. I think the goal of this thread is to define what is going into the buyblue implementation, if these plans can be generic enough to be useful elsewhere, then comparing with what others think should be included in any base chapters function.

It is much better to discuss in terms of what is being done already and how that can be enhanced, rather than developing something completely different. I'm not trying to disagree, just trying to help focus the thread and the process.

rbrooks00’s picture

I don't see anything wrong with mapping out what a "chapter" should be in ideal terms and then mapping that to a) what already exists b) what we are creating and then c) what is left. I think that'd be a good exercise to come out of this.

I'm certainly happy to share my ideas on the subject, just don't have time to do it right now.
============================================
BuyBlue.org

Walt Esquivel’s picture

I completely agree with webchick's comment that OG postings should not become:

a "Name your pet feature for OG and make Raven pay for it" thread. ;)

Having said that, I would like a better understanding of how all these terrific enhancements will work and I agree with the comments jasonwhat made and would enjoy:

discussing how "chapters" functionality should be implemented in Drupal. I know lots of feature suggestions start coming up, but I think we can have a useful discussion here about what people would like to see as the basics of "chapters," and from there discover if these will be implemented for buy blue or not.

I also agree with the comments rbrooks made and would enjoy:

mapping out what a "chapter" should be in ideal terms and then mapping that to a) what already exists b) what we are creating and then c) what is left. I think that'd be a good exercise to come out of this.

So, is this thread a good place to get started mapping things out? If not, please suggest an appropriate thread. If one doesn't exist, I'll be happy to create a new thread or follow your lead in posting to one that you create.

In terms of mapping things out, it would be nice to see something similar to the Task, Status, and Priority columns developed for the CCK module as it provides an easy to look at and understand visual of the overall project. If someone can explain to me how to create a table such as the CCK one, I'll be happy to get the OG one started. However, don't these types of tables need some sort of admin authorization or at least someone with the proper permissions here at drupal.org? I could be wrong, but that was my understanding.

Finally, I need some OG clarification. If I start using OG as it exists today, 5/9/06, and folks start joining/creating specific groups (e.g., the Austin group, the New York City group, etc.) via my OG-enabled web site, what will my options be in the future once all the wonderful enhancements described by webchick at the top of this page are coded in? For example, if folks join the Austin group today and then, in the future, the sub-chapter capability becomes available and I add an Austin sub-chapter, will I be able to transfer folks over from, say, the Austin group to its sub-chapter, or to another group for that matter if they were to move from, say, Austin to New York City? Or would this all be a manual process of "Unsubscribe" and "Subscribe" at the user level? If someone "Unsubscribes", would their forum postings, event postings, etc., still exist, or would they disappear? Also, if I need to move an event from the Austin group to one of its new sub-chapters, will that be possible?

Back on 4/18, rbrooks wrote:

I'm certainly happy to share my ideas on the subject, just don't have time to do it right now.

Well, I'm all ears! :) Any insight would be helpful in allowing me to get a better grasp of how the BuyBlue.org implementation will work.

Thanks.

-----
Walt Esquivel, MBA, MA, Captain - U.S. Marine Corps (Veteran)
President, Wellness Corps, LLC
-----
Drupal Users and Developers by Geographical Location
http://drupal.org/node/46659

rbrooks00’s picture

So, is this thread a good place to get started mapping things out? If not, please suggest an appropriate thread. If one doesn't exist, I'll be happy to create a new thread or follow your lead in posting to one that you create.

I'd say this is as appropriate a place as any :)

Finally, I need some OG clarification. If I start using OG as it exists today, 5/9/06, and folks start joining/creating specific groups (e.g., the Austin group, the New York City group, etc.) via my OG-enabled web site, what will my options be in the future once all the wonderful enhancements described by webchick at the top of this page are coded in? For example, if folks join the Austin group today and then, in the future, the sub-chapter capability becomes available and I add an Austin sub-chapter, will I be able to transfer folks over from, say, the Austin group to its sub-chapter, or to another group for that matter if they were to move from, say, Austin to New York City? Or would this all be a manual process of "Unsubscribe" and "Subscribe" at the user level? If someone "Unsubscribes", would their forum postings, event postings, etc., still exist, or would they disappear? Also, if I need to move an event from the Austin group to one of its new sub-chapters, will that be possible?

The stuff we are doing doesn't really affect that part of it. We are using the word group and chapter interchangeably. So I'd say that whatever is built now would be available in the future.

These changes center around expanding OG's scope for your site as a whole. For example, being able to create blocks specifically for a certain group. Right now you can't do things like that, OG does what it does and other than that decisions like the blocks you use are global.

============================================
BuyBlue.org

Walt Esquivel’s picture

You wrote:

The stuff we are doing doesn't really affect that part of it. We are using the word group and chapter interchangeably.

I guess the part that confuses me is the "sub-chapter" description as mentioned at the top of this page.

...to enhance the Organic Groups module in order to support local sub-chapters.

Can we take your comment one step further and say we're using the word group, chapter, and subchapter interchageably?

Thank you.

-----
Walt Esquivel, MBA, MA, Captain - U.S. Marine Corps (Veteran)
President, Wellness Corps, LLC
-----
Drupal Users and Developers by Geographical Location
http://drupal.org/node/46659

rbrooks00’s picture

Yes, sorry I think that may have been a bit confusing. This project isn't going to introduce another tier to the groups heirarchy. The project is designed to extend groups into other parts of the web site allowing a chapter, group, whatever you want to call it to enjoy more of the functionality without the necessity of having a separate installation.

============================================
BuyBlue.org

venkat-rk’s picture

You are quite right and that's why I apologised for adding something that sounded like feature creep. My intention at least was not "Name your pet feature for OG and make Raven pay for it" ;-)

I am wondering if a good way to tap into all this interest is to explore the possibility of putting the extra stuff into a DEP, as you propose, but, instead of stopping there, offer a mechanism for interested people to actually donate to the project much as they did during the drupal server outages last year. This would not have any legitimacy outside of drupal.org, but I also don't know if something like this is possible or will be considered.

jasonwhat’s picture

been done before with other projects, http://donorge.org

Walt Esquivel’s picture

Gee, I hope I wasn't the one that crossed the line. If so, my bad!

:(

I completely respect webchick's comments and truly appreciate what Raven, BuyBlue.org, CivicSpace Labs and others are doing/contributing to enhance the OG module.

Keep up the great work!

:)

-----
Walt Esquivel, MBA, MA, Captain - U.S. Marine Corps (Veteran)
President, Wellness Corps, LLC
-----
Drupal Users and Developers by Geographical Location
http://drupal.org/node/46659

Crell’s picture

This sounds way cool, and similar to some og-based work I have on the horizon. Thanks. :-) I sadly don't have much time for Drupal coding lately and I've not worked with og extensively, but since I see myself benefiting from some of these improvements I'd be happy to help if I can.

The OP mentioned beefing up location.module's search functionality a la gsearch. I haven't worked with gsearch, but Ankur (location module maven) suggested I look at it for inspiration for adding search-keyword-near-zip functionality to the location module, something that it is currently lacking. Is that something that would be useful here? I need to add that for a project I'm working on. If we can help each other in that regard, so much the better.

It seems there's already an outstanding issue for it, which I will probably usurp... :-)

--
Larry Garfield
http://www.garfieldtech.com/blog

--
Larry Garfield
http://www.garfieldtech.com/
Thinking Functionally in PHP: https://leanpub.com/thinking-functionally-in-php

rbrooks00’s picture

There are now several new project pages based on this stuff.

OG Block Visibility - This module allows you to specify that a block should be visible only within a selected group. This can be used for many purposes, from providing each organic group with its own navigation menu, to allowing a group to highlight its own featured content, etc.

OG Calendar - This module provides each group with a calendar showing only the group's events.

OG Roles - This module allows you to, for each group type, specify a list of roles that group administrators are allowed to assign. For example, if you created a "trusted user" role, and a new node type called "official group," you could allow administrators of only official groups to add selected other group members of to the "trusted user" role.

More to come, I'd say we are a little more than halfway through.

============================================
BuyBlue.org

Walt Esquivel’s picture

...and am interested in seeing some of the new OG enhancements worked into the BuyBlue.org web site to see how they are implemented, publicized, and eventually used by the BuyBlue.org community. It would be great to see demos. Perhaps a "Try out a demonstration" link as that listed under Organic groups (and which leads to groups.drupal.org) could be added to each new OG enhancement module (e.g. OG Calendar) thus leading to BuyBlue.org and/or groups.drupal.org?

Also, will http://groups.drupal.org/ be using the new OG enhancements anytime soon? Perhaps this is a question better suited for Moshe, the g.d.o webmaster? I believe g.d.o. is a perfect place to utilize some, if not all, of them.

Overall, the OG enhancements sound very impressive!

Walt Esquivel, MBA, MA, Captain - U.S. Marine Corps (Veteran)
President, Wellness Corps, LLC
DreamHost Rewards Affiliate Program

P.S. for Raven. I think the whole concept of BuyBlue.org is very valid and I support it. I joined even after reading you're a Texas A&M Aggie! I'm a University of Texas Longhorn. Hook 'em Horns!!

rbrooks00’s picture

Great!

We are trying to get everything together right now. The development that CivicSpace was working on is basically done (maybe a few things outstanding) but mostly we have to work out how we are going to implement everything on the site. But... before we do that we have to get the site upgraded to 4.7 since we are currently running a pre-forms api version of 4.7. All of the development is done on that and we are just waiting on some minor theme things before making that live - hopefully next week after we get back from YearlyKos.

So I'm thinking, maybe July-ish for our launch of the groups stuff? /me crosses fingers

============================================
BuyBlue.org

Walt Esquivel’s picture

FINANCIAL CONTRIBUTIONS NEEDED?
At the top of this page in the original post, it states:

And just a reminder that CivicSpace Labs is hiring developers and looking for partners to collaborate and split development costs on these and other items in order to help speed delivery. If interested, please contact Kieran Lal.

Is there a budget for the OG enhancements that BuyBlue.org is sponsoring as described above? How much further funding, if any, is needed? Here's a Reverse Bounty: og2list example from CivicSpace.

I'll definitely be using some of the OG enhancements listed above and am willing to make a small financial contribution. If others read about your funding needs and likewise pitched in a few dollars, it could further help move the enhancements along. If you agree, please let the public know what is needed in terms of funding, if any, because I believe every little bit helps.

IF SO, TO WHICH ORGANIZATION?
For the OG enhancements sponsored by BuyBlue.org, should I donate to BuyBlue.org (donor link) or CivicSpace? I'm also planning to give small financial contributions to CivicSpace (donor link) for other OG work (e.g. og2list) and Drupal (donor link) (Moshe asked I simply donate to the drupal.org project in his name).

Walt Esquivel, MBA, MA, Captain - U.S. Marine Corps (Veteran)
President, Wellness Corps, LLC
DreamHost Rewards Affiliate Program

dgeilhufe@yahoo.com’s picture

Walt,

CivicSpace is managing the OG2List development effort and accepting contributions. The money contributed is used exclusively to pay developers working on OG2List. We have had great support from CompuMentor, Development Seed, two other organizations and a couple other individuals, we have raised $3.5k for the project.

We have $4k to go.

You can donate to the project using the contribute link or send me an email:
http://www.civicspacelabs.com/opensource

David Geilhufe
Managing Partner, CivicSpace
dgeilhufe AT civicspacelabs.org

rbrooks00’s picture

Sorry for the delayed response here but David covered it, if you want to help out with this it would be best to donate directly to CivicSpace as David outlined. I think they'll continue working on other things whereas we're just working on these specific group enhancements.

I think I owe you an email too, but I'll have to respond when I get done with this convention in Vegas :)

============================================
BuyBlue.org

Walt Esquivel’s picture

Hey Raven - thanks but no need for an email reply. I made my donation directly to CivicSpace per your comment. I also made a small contribution in Moshe's name directly to http://drupal.org/donate per his request when I asked him how I could contribute. Moshe is doing an incredible job on the OG module and groups.drupal.org!

Thanks to you and BuyBlue.org for sponsoring exciting OG enhancements! And of course thanks to David and CivicSpace for providing outstanding modules to the Drupal community! I hope others will step up and help contribute to CivicSpace so that we can all continue taking advantage of the excellent benefits from all the OG, events, and ecommerce enhancements CivicSpace is working on.

Walt Esquivel, MBA, MA, Captain - U.S. Marine Corps (Veteran)
President, Wellness Corps, LLC
DreamHost Rewards Affiliate Program

Walt Esquivel’s picture

Hi,

How are the OG enhancements coming along and could we have a status update? Thank you in advance!

Is more funding needed? Please see http://drupal.org/node/74396 and Projects Needing Financing.

Walt Esquivel
Help Fund Drupal Projects with a Web Hosting $50 Discount
Projects Needing Financing

rbrooks00’s picture

From the CivicSpace side of things I believe they are done (or pretty close to it) with the things we originally scoped out. Ball is now in our court for the most part. We might have to go back for a few tweaks, bug fixes, etc. This past weekend we finally got our site upgraded to 4.7.2 (it was at a pre-forms api version of 4.7) which is obviously a necessary step in enabling this stuff. That was significantly delaying the whole effort and getting it done is a big thing for us.

Our designer and local chapter president now have to figure out exactly how we are going to assemble all of these pieces on the site. We've had some preliminary discussions but we need to do screen comps, and then do the work. That is scheduled to start in August since both of them are on vacation through the end of July.

If things go well we might have this stuff live by sometime in September.

============================================
BuyBlue.org

Walt Esquivel’s picture

Raven,

Thanks for the detailed reply. Also, a hearty congratulations on getting the BuyBlue.org web site upgraded to 4.7.2!

I'm looking forward to seeing the location-based search as well as event, RSVP, and volunteer management. :-) Please post back here once these have been submitted as contributed modules. (If already submitted, my apologies because I didn't see them.)

And if you ever need more funding, please be sure to visit Projects Needing Financing

Thank you!

Walt Esquivel, MBA; MA; President, Wellness Corps; Captain, USMC (Veteran)
$50 Hosting Discount Helps Projects Needing Financing

drurian’s picture

Can anyone tell me what's the modules that implements the group description & picture block for each group on groups.drupal.org?

Walt Esquivel’s picture

Take a look at the "Code" section on the "About" page of groups.drupal.org.

Walt Esquivel, MBA; MA; President, Wellness Corps; Captain, USMC (Veteran)
$50 Hosting Discount Helps Projects Needing Financing

markwagner’s picture

Can someone tell me where the OG Enhancements have got to. Are they available as part of OG yet?

Walt Esquivel’s picture

Yes, I would enjoy reading how BuyBlue.org eventually decided to resolve its need, as mentioned at the top of the page, for the "location-based search" as well as "event, RSVP, and volunteer management".

Location-based search
Allow searching state-wide in addition to within X radius of zip code.

Events, RSVPs, and volunteer management
Local Spaces need to be able to create events and manage event subscriptions and volunteers.

Also, it would be nice to read about any additional OG Enhancements that are being worked on in addition to everything mentioned above. Does anyone know of additional OG Enhancements being worked on and, if so, can you kindly provide links to them or post the info here?

As to Mark's question "Are they available as part of OG yet?", Several new project pages shows us some of the "OG enhancements" mentioned above have been available for months. You won't necessarily find "OG Enhancements" as "part of OG". Most of the enhancements are in the form of their own module which you can download from Drupal's contributed modules page.

You should avoid trying to find OG-related modules via the browse by category page because, for some reason, all of the OG-related contributed modules are NOT listed there. For example, OG Calendar, OG promote, and OG Roles are not listed. Instead, go to the browse by name page. (Does anyone know why all the OG-related modules are NOT showing up on the category page?)

Finally, for both developers and users reading this, please note that reverse-bounties for projects that will be contributed back to the Drupal community can be posted and described in detail at Projects Needing Financing. If you benefit from the wonderful OG Enhancements thus far, please consider donating on future OG modules where a reverse bounty request is made. A small donation from a user goes a long way and will help the developer get the project out to the community that much faster.

Walt Esquivel, MBA; MA; President, Wellness Corps; Captain, USMC (Veteran)
$50 Hosting Discount Helps Projects Needing Financing

moshe weitzman’s picture

i affiliated those 3 projects with the og category. thanks for the tip.

SocialNicheGuru’s picture

subscribing

http://SocialNicheGuru.com
Delivering inSITE(TM), we empower you to deliver the right product and the right message to the right NICHE at the right time across all product, marketing, and sales channels.