TOPIC: two bugs

Howdy,

There's been a couple bugs in DT Register (perhaps DT Register's Cart more specifically) for a long time now (since 2.6.x) that I'd just been living with because it's not been the highest of priorities on my list to worry about, however now it's happening more often. I'd hoped that perhaps they'd have been addressed in previous upgrades, but no luck thus far.

Bug #1:
Scenario: One user, two class signups via the Cart.
Class #1 has spots available.
Class #2 is wait-listed. (full)
User doesn't know, and signs up for both sessions. User puts CC (or paypal) info in and payments are registered/accepted for both sessions, even though the user is actually wait-listed for the Class #2. I have to manually email each person telling them actually, no, they're not in.. they're waitlisted and "sorry about that". It wasn't happening too much previously, but now that we're selling out on our little classes, it's more common.

Bug #2:
Scenario: Two items attempting to be procured via Cart.
Item #1 has one set of payment options (e.g. one saved payment config in the DT backend)
Item #2 has a slightly different set of payment options (basically a "pay in person" option has been removed).
User gets to checkout and is then presented with all options for payment (a combination of both saved payment profiles on the backend). So I have some folks presented with a "pay in person" option for Item #1 which is not allowed.

If these bugs are confirmed by you dthadmin, would it be possible to get a copy of the 'fixed' version of DT Register even though my subscription is expired?

(I'm using Joomla 2.5.6 / DT Register 2.8.x (latest version from Oct) / DT Cart 2.5.2)

*bump*

No response expected over the long weekend, but wanted to ensure this gets seen.

Thanks!
C.

Hi, Just wanted to let you know this has been seen. I will check into it. Give me a little bit of time since I will need to do some testing here. I'll post a reply when I get a bit further. Thanks for the post.

Jen

We've been discussing your issues and here's what we've come up with.
The first item is a design flaw rather than a technical bug, and we're addressing that with a priority. We agree you shouldn't have to pay to be put on the waiting list, so our developer is working on a fix where payment will be delayed and a notification will be visible that let's the registrant know they were put on a waiting list, but not charged. Now, if you are needing some further automation here, we'd be happy to offer a custom quote for adding further waiting list functionality. Otherwise, you will have to manually adjust the list as has been the case. Open a support ticket to discuss further, please.

The second item is not a bug, but rather a conflict in setup. The shopping cart by it's nature combines processes in order to facilitate multiplicity. Your setup - by offering differing pay options per event - negates the functionality of the shopping cart, because essentially you require different checkouts. In order to address your "bug" we would have to go in and somehow "separate" event checkouts in a system that has just worked to combine checkouts. It isn't logical. Unfortunately, you have a somewhat rare setup need, so the multiple event cart isn't your best choice. It may be possible that we can brainstorm to think of a work-around using the current functionality. However, I'm going to have to say this isn't a bug or a design flaw in this case though I can see how you could feel this was a limitation for you.

Jen

Hi Jen,

Thanks for the posts.

Regarding issue #2, I'd like to make a couple suggestions for workarounds:

1) Prevent items with different payments methods from being lumped together in the cart. On the backend, it would seem to be a simple check for payment method on any given item. If all items pay using same method, continue. If items have more than a single payment method, throw a message up and disable routing payment via Cart.

2) Allow items with different payment methods to be utilized in the Cart, but utilizing the more restrictive of the two payment methods.

3) Allow items with different payment methods to be utilized in the Cart, but default to 'Default' (rather than combine).

Also, was wondering if there was an answer to my last question regarding getting a copy of DT Register with an update. I acknowledge DTH's point of view on issue #2, but issue #1 appears to have been validated by you folks so it would be nice to get a copy with this resolved as a courtesy for bringing it to your attention.

Regarding custom orders and quotes, what email address should I address those to? (You can respond via PM if you desire.)

Thanks kindly,
C.