gsoc idea

Overview

The project aims at extending the DrupalGapps (Google Apps Framework for Drupal) module by:

1. Improving and adding more features to existing DrupalGapps API.
2. Developing wrappers and applications (as modules) for Google's service-specific APIs by using the DrupalGapps API.

State of DrupalGapps Framework (module)

DrupalGapps Framework is a project that aims at seamlessly integrating Google Apps with Drupal.

The secure code review module was a great success from SOC2010. It would be great to enhance it further for 2011.

Possible ideas:

• Extending the rules it uses to find vulnerabilities so it can catch all of the contributed module vulnerabilities announced in 2010, 2009, etc. (this isn't fully practical, but getting just 50% or so would be a great improvement!)

I am currently working on a (set of) module(s) to integrate Drupal with CollectiveAccess, an open source PHP collection management system that is focussed towards cataloguing, maintaining and managing collection data. This software is getting quite some traction with museums, archives and other institutions that require digital collections.

My idea for the GSoC 2011 is to work further on the Drupal/Ubercart/OpenERP integration such that persons (users/clients), products (descriptions, prices, availability, ...), orders (invoices, shipping, ...), and maybe other entities are synchronized between Ubercart and OpenERP.

http://drupal.org/node/682044#comment-3775812
The author of the biblio module is working on the 7.x-2.x.

In Drupal 6, biblio is a popular module for academics, libraries and publishers But it has its own data structure rather than reusing cck fields. So some related modules were made for extra functions like apachesolr_biblio.
In Drupal 7, fields are built in the core, and we all agree that "Biblio in Fields" is the best solution.

I also would like to add more standards support in the new release like:

ONIX
http://www.editeur.org/8/ONIX/

PRISM

The "parent term" property on a taxonomy term is a unique, non-field-api, non-transferrable relation that has not been upgraded to Field API. This GSoC idea does not propose to replace this in core as the short term goal, because a transitive relationship field can exist side-by-side with the current "parent term" field and the "parent term" field can be drupal_alter'ed out of existence. However, if this project succeeds, it would be developed further to include in core.

@sumitk talked to me about this at DrupalCon Chicago last week. I am not sure how I should be presenting ideas, but I will throw a few out there here. Geospatial data, mapping, GIS, etc are very big in the web and mobile worlds, and people expect data to be geolocated these days, but there is still lots of work to be done in Drupal core and in Drupal contrib in getting a more cohesive, consistent experience around these concepts.

<

ul>

Drupal core's menu module provides “strict hierarchical” information architecture with its menu system. Menu module currently provides just 3 ways to navigate that strict hierarchy:

1. Breadcrumbs output to the $breadcrumbs variable in page.tpl.php
2. Blocks containing full menu trees that can be navigated by clicking into deeper levels of the menu.
3. A list of links that represent a single level of a menu tree. Output to the $main_menu and $secondary_menu variables in page.tpl.php