Spree 2.2

[sohara]

Hi @JDutil. You mentioned in your README that you plan to re-write this extension for spree 2.2.x compatibility. Do you have a timeline for that? I am upgrading our system to Spree 2.2.x presently and need to either massage the current extension into some kind of 2.2 compaitbility or use something else (while migrating our current gift card data appropriately. Please let me know any info you can share.

Thanks,
Sean

[JDutil]

@sohara if you are currently working on your 2.2.x upgrade, and are already using this extension I recommend you massage this one for your upgrade. Please submit a PR back, and I will continue to support merge etc.. as long as the community wants to contribute.

I'm currently working with a client that brought up some great insights into how gift cards should be properly be handled, and it is a drastic change from this extension. I had written this extension as a rewrite of spree_gift_cards and that led me down the wrong road. We are just starting from scratch since the new way makes way more sense, and don't want to muddy the new approach with legacy code.

If you upgrade to 2.2.x I'll do my best to work with you guys on a way to migrate legacy data, but I'm not sure that a migration of used cards would really be worth it. We can certainly at the very least migrate unused card information to the new method.

Some differences:

1. Redemption is no longer an adjustment it is a payment record where gift cards are the payment source.
2. No longer need transaction history since you can just query the payment records
3. Refunded payment records adds funds back to card
4. The infamous custom value Possible to add option for custom value? #3 will be supported.

[JDutil]

Also forgot to mention as far as the timeline goes I'm still uncertain. Work has just begun this week, but I don't anticipate it being done for a couple weeks at least. I'm also not sure if it will be released open source immediately or not, but it certainly will be. Also does have a goal of becoming the official gift voucher extension if we can't convince the core team to actually just make it part of core. The fundamentals behind it are pretty solid especially compared to the last couple attempts that have been made by this and previous extensions.

[sohara]

@JDutil Thanks for the responses. I do think the new approach you're taking will make more sense. Our ops/accounting team already questioned whether gift cards should be treated as adjustments instead of payments, so I think migrating to that kind of approach would make sense for us eventually (no idea of the the timeline though).

I don't think we'd need to migrate all historical data over to the new system, but of course we would need to be able to honour any outstanding gift cards held by customers.

I'll let you know where I get with the 2-2-stable branch in our fork. Cheers.

[paultyng]

@JDutil If you want any help / thoughts on the 2.2 reimagining we also need gift card support before upgrading so I'd be happy to chip in. We use ours more like Amazon though (as in they add credit to your account that is then applied at checkout, we don't actually have coupon / gift card inputs in the checkout process, only on cart) so it may be better for us to wait until credit is added to the 2.2 core, but I'm not sure. Stuck on 2.1 though until I get some resolution one way or the other so I'd be happy to help where I can.

[JDutil]

We have a pretty solid game plan for how we want to execute the new extension, and a client is driving the effort so they are not very open to changes in that roadmap until our initial implementation is complete. However they have already allowed us to begin open sourcing the new implementation. It is still a work in progress but open to accepting feedback, and can be found here: https://github.com/spree-contrib/spree_vouchers

Currently it only deals with the redemption of vouchers, and the purchase / delivery is expected to be finished by the end of the month.

Credit will not be added to 2.2.x core as it is a new feature, and 2.2.x is already released. It is on the roadmap for 2.3.x or 2.4.x hopefully, but that is subject to change.

The issue with doing it how Amazon does is that it requires users to have accounts. What we ultimately want to do is allow redemption as we are currently doing, but also hook into the store credit code once it's completed so that voucher remainders will be credited to an account. So basically we would have best of both worlds. The ability to use them without an account, and if you do have an account it would apply it as credit.

[paultyng]

Sounds great, I'll keep an eye on that repo then. One thing I wanted to mention for when you do get in to purchasing (not sure if this aligns with the client's needs), would be to do some sort of polymorphic voucher/gift card so you can customize delivery (for example we do email cards and physical via something like lob, so it would be nice to customize the delivery method per gift card product or something to that effect (as opposed to just a boolean gift card flag as it was previously).

[JDutil]

The plan is to implement a new shipment handler that determines whether or an item is a physical or digital delivery. How exactly that handler will make the determination is yet to be seen, but I imagine it will be some sort of digital variant flag in which case you could have a digital variant and physical variant. The idea is to make the shipment handler smart enough to work for both the voucher extension and the spree_digital extension as well as any other use case someone would have for purchasing an item that is not physically delivered.

[paultyng]

👍

[JDutil]

2.2.x support is added w/ bdec5a3 however please see #51 about the migration issue as updating spree to 2.2.x migrations before this migration may cause data to be lost.