The Volume Pricing extension is now available in github. It uses predefined ranges of quantities to determine the price for a particular product variant. If no volume price is defined for a variant, then the standard price is used.

Each VolumePrice contains the following values:

1. Variant: Each VolumePrice is associated with a Variant, which is used to link products to particular prices.
2. Display: The human readable reprentation of the quantity range (Ex. 10-100). (Optional)
3. Range: The quantity range for which the price is valid (See Below for Examples of Valid Ranges.)
4. Amount: The price of the product if the line item quantity falls within the specified range.
5. Position: Integer value for acts_as_list (Helps keep the volume prices in a defined order.)

Ranges

Ranges are expressed as Strings and are similar to the format of a Range object in Ruby. The lower number of the range is always inclusive. If the range is defined with ‘..’ then it also includes the upper end of the range. If the range is defined with ‘…’ then the upper end of the range is not inclusive.

Ranges can also be defined as “open ended.” Open ended ranges are defined with an integer followed by a ‘+’ character. These ranges are inclusive of the integer and any value higher than the integer.

All ranges need to be expressed as Strings and must include parentheses. “(1..10)” is considered to be a valid range. “1..10” is not considered to be a valid range (missing the parens.)

Example

   Variant                Display            Range        Amount         Position
   -------------------------------------------------------------------------------
   Rails T-Shirt          1-5                (1..5)       19.99          1
   Rails T-Shirt          6-9                (6...10)     18.99          2
   Rails T-Shirt          10 or more         (10+)        17.99          3

Additional Notes

The volume price is applied based on the total quantity ordered for a particular variant. It does not apply different prices for the portion of the quantity that falls within a particular range. Only the one price is used (although this would be an interesting configurable option if someone wanted to write a patch.)

Spree now includes integrated Authorize.net support. Spree can be used with any of the major gateways supported by the excellent activemerchant plugin. Spree currently only supports a couple of these gateways “out of the box” but the rest can easily be added by writing a simple migration so that the gateway settings can be configured through Spree’s admin interface.

Ricardo S. Yasuda (shadow11) wrote just such a patch for Authorize.net so now you can just select it as your gateway and configure your login API information. Its really quite simple to add support for your gateway. If you don’t believe us, just take a look at the initial commit for used to support Authorize.net.

So once you get your preferred gateway working with Spree, please share your patch with the rest of the community.

Spree 0.5.0 has officially been released. This version requires Rails 2.1.2. This version will not work with Rails 2.2.2. There are also problems with the spree command used to generate a new application if you have both Rails 2.2.2 and Rails 2.1.2 installed. We’re working on a solution for this but in the meantime, you will need to uninstall Rails 2.2.2. (and all of the dependencies like activesupport) in order for the spree command to work properly.

Highlights of this release include:

• New and improved shipping framework.
• Migration generator for extensions
• Support for sample data in extensions
• Shipping address limited to the countries that are configured by a shipping zone
• Configuration screen for inventory settings
• Built-in mechanism for dealing with near static content
• Support for requiring/installing gems in extensions
• Rails 2.1.2 support

The shipping framework represents a major step forward. It provides the ability to customize your application’s shipping logic exactly the way you need it. It also allows for UPS and USPS shipping via the active_shipping extension. For more information see the shipping section in the user’s guide.

Spree has just added SSL support using the excellent ssl_requirement plugin written by DHH. Now the credit card payment and order summary pages are served up using HTTPS.

You will need an SSL certificate for your production site (obviously) along with a proper virtual host setup for the 443 port. Don’t forget to use the following to ensure that Mongrel is able to tell which requests are already over HTTPS:

RequestHeader set X_FORWARDED_PROTO 'https'

The default behavior of the ssl_requirement plugin is to not require SSL for any of the pages when running in development mode. If you don’t want to use SSL in production mode, just comment out the ssl_required lines in your controllers. You might also want to check out this interesting blog post by Mike Subelsky for more information on working with SSL in Rails.

Special thanks to Ricardo Shiota Yasuda (shadow11) for providing and testing the patch.

Spree now includes a complete shipping framework that allow you to configure shipping for your exact needs. Shipping is implemented through a combination of zones and calculators. The core shipping extension in Spree adds several columns to the variant table to assist in shipping. Each product variant has a weight, height, width and depth field. There is an assumption of an implicit common unit of measurment for each of these fields.

The core shipping extension also adds a shipping_category field to the Product model. Products can be assigned to zero or one shipping category. The shipping_category field is entirely optional. Shipping calculators can be designed to take advantage of this category information or ignore it entirely.

Each of the shipping methods relies on a calculator to determine the actual shipping costs. Calculators contain a calculate_shipping method to which you pass an Order object. The order contains an Address which is the shipping address as well as LineItems which contain references to the Variants and their quantities.

It is our experience that most applications require very specific logic for their shipping needs. Most open source platforms fall into the trap of trying to integrate a shipping solution that attempts to meet everyone’s needs. Spree takes a different approach. Spree comes with a simple flat rate shipping option as well as the ability to turn off shipping all together (just remove the shipping extension.) It is expected that you will either develop your own shipping extension or use an existing third party extension. Spree puts an emphasis on making it easier to customize the piece that always ends up needing to be customized anyways.

Please see the shipping chapter of the user’s guide for more details. Also, be sure to checkout the extensions listing for more information on all of the shipping and other Spree extensions.

The new openid extension for Spree is now available. The business logic included in this extension provides sensible defaults for various user authentication/creation scenarios. Feel free to fork and modify to taste.

The authorizaiton requests make user of the OpenID Simple Registration Extension 1.0 when possible. So if the OpenID provider supports this specification, then requested user information (by default only email) will be returned as sreg parameters.

User Authentication

Authentication refers to the login screen where the user is asked to supply their email and password (or OpenID.) If the user provides an openid url then they will be taken to the standard login screen for that user’s provider. Upon successful authentication, the url will be checked against existing users in the Spree database. The user is authorized if a record is found with a matching url. (See also auto creation for other scenarios.)

User Creation

If the user successfully authenticates via OpenID but there is no user with a corresponding URL, then Spree will attempt to create a new account automatically. If there is an sreq parameter for email, we first check to see if there is a user with a corresponding email.

If there is a matching email, the user will be presented with a screen and given the opportunity to associate this openid url with their account. In order to do so, the user must enter their original password in order to prevent malicious attempts to hijack another user’s account.

If no matching email is found then Spree will ask the user to “complete” the account creation process by supplying a valid email.

Installation

script/extension install git://github.com/schof/spree-open-id.git

The edge version of Spree now requires Rails 2.1.2. We just upgraded to the latest version of resource_controller which seemed to have resolved issues people were experiencing when attempting to use the earlier Rails 2.1.1 release with Spree.

Since Spree uses SEO friendly permalinks, we need to make a few minor changes to the resource_controller plugin. Those changes are being tracked in a github fork which you may be intersted in using if you require further modifications to resource_controller.