Hi, my name is Felipe and I'd like to apply for GSoC this year.
I'm a free software enthusiast. First because of the freedom philosophy itself and also because I believe in the technological progress based on collaborative work.
I'm a GNU/Linux user, running KDE and currently I use Emacs for coding.
So, last year I started working with Drupal and got really impressed with its power!
Specifically, I worked on a few projects using Ubercart.
The time passed by, Drupal 7 was released and I got to know this great project: Drupal Commerce.
I watched DrupalCon videos, read lots of stuff on drupalcommerce.org and read some pieces of code too.
So, both because of the "giving back" motivation and the "collaboratively working on something awesome" motivation, I'm really excited to work on Drupal Commerce as a GSoC project.
So, some weeks ago I talked to rszrama and he told me there was a conversation at DrupalCon Chicago about GSoC 2011 ideas.
He said there was some Commerce proposed ideas and sumitk was about to post the notes here on g.d.o.
Today sumitk did it (http://groups.drupal.org/node/138009) and.. well, here I am to discuss the Commerce ideas.
I'd like to understand it well and grow up the proposes to write the application.
Here are the ideas:
- Simplify the relationship between nodes and products
- Unified identity access control / revision support / view API
- Comments on any entity
Please, give some feedback on the following thoughts...
-
So far I know, Commerce makes use of D7 Fields API to define products as Entities.
Product types are bundles and custom fields can be added to each of them.
Thus when talking about "relationship between nodes and products" seems something like a site with products somehow related to blog posts, or thread discussions.
Then, if the above idea is correct, why relating products to nodes rather than with any entities?
Someone can think on other uses of this relationship? -
Well, I got specially interested on this one.
As developer, I like the "strict development standards" principle (first paragraph).
However, today I have no enough Commerce knowledge to think about this API definition. Bu I'd love to discuss it..
What code/doc should I read? -
Sincerely, I don't have much experience with comments on D7.
Anyway, as "any entity" there are:- Product
- Customer profile
- Line item
- Order
- Payment transaction
When I think on comments, I think on people commenting (really?) /discussing about some subject.
So I can't think a good example on using comments on Customer profile for instance. Maybe the profile's owner would like to say something about some specific profile, but that's it.
What am I missing on this point?
Comments
Thus when talking about
Drupal Commerce separates the product and it's display.
So you create a product for each SKU (shirt M blue, shirt XS blue, shirt M black, etc..), and then create a node that has a product reference field, referencing the products you created.
I think what Ryan meant is improving the process so that it's not two step (for example, have a checkbox on product add saying "create a matching node").
I actually wouldn't recommend this idea to students. Extending Entity API requires a lot of existing experience in building modules that rely on it, and co-operation with the maintainers.
I think it's too heavy for a GSoC project.
In any case, glad to hear you're interested in Drupal Commerce, please join us at #drupalcommerce (freenode) and let's discuss your involvement :)
I've fleshed the ideas out a
I've fleshed the ideas out a little further on sumitk's post: http://groups.drupal.org/node/138009
Ping me again in IRC and let's see what sort of proposal we can come up with. : )
Well, just to let everybody
Well, just to let everybody know about our conversation at #drupalcommerce...
After rszrama clarified the ideas, we discussed some particular ones:
Unified entity access control / revision support / view API.
Enhacements on usability of discounts definition (or "sweet discounts definition UI")
So, at the moment is possible to define price discounts directly on Rules UI only. The idea is to make possible to store administrators (non developers nor Rules skilled) to super easily define discounts. This UI will be Commerce specific, but the data will be translated to Rules on the backend. Some points that came out:
a) Roles based discounts
b) Per product discounts
c) Per product type discounts
d) Date intervals (e.g Christmas discounts)
e) Field selected (e.g certain brand)
a) Not necessarily all conditions of a Rule will be mapped to this simplified UI. So, when updating UI settings, do not wipe other conditions.