[SOLVED] CBSubs: Negative promotion on free subscriptions?

I'd appreciate even more, of course, if it got "fixed" within the next few days or a week. Please don't take it as a "threat" or so, but it could be a deal breaker if this essential function (or a fully equivalent alternative way or workaround) weren't working, eventually forcing me to make use of the money-back offer.

It depends entirely on what the bug review finds. Something that's as simple as couple lines of code, sure, but if it takes a large rewrite to fix it then it's unlikely. I've let Beat know your urgency and given the bug ticket higher priority.

Hmmm... right now the plans on offer are sitting at the beginning of the registration form, which is where they should be, but as far as I understand this wouldn't be the case anymore if I had to follow your suggestion.

You can have static and dynamic conditions on your plans. The dynamic conditions will allow them to conditionally show/hide during registration. So if you're conditioning off a field value for example then either/or plan will show correctly based off that field value.

I don't know exactly how you have things setup, but this could be a good alternative. It comes with the added benefit that they're 2 completely separate plans so they can give access to content individually.

krileon wrote: It depends entirely on what the bug review finds. Something that's as simple as couple lines of code, sure, but if it takes a large rewrite to fix it then it's unlikely. I've let Beat know your urgency and given the bug ticket higher priority.

Thank you for responding again, and for understanding the importance and time constraints and giving it higher priority.
If more complex, and hence, more time consuming, it'd be good to know an "ETA", especially if it were outside my 30 days money-back period... with more then depending on how far outside of this period it'd be.

Needless to say, I'll happily help with testing the updated code!

I don't know exactly how you have things setup, but this could be a good alternative. It comes with the added benefit that they're 2 completely separate plans so they can give access to content individually.

I see what you mean and agree that it's generally a viable alternative. Unfortunately, with pricing to depend on both geo zone and the value of a CB field, it'll turn the registration process upside down - while the client is for a number of reasons insisting to show and let users select plans as the first step on the registration page.

Then there are other implications due to more plans being needed. We'd need 3 instead of a single one (due to 3 price variations per plan), and that for 3 different plans, resulting in 9 instead of just 3. It'll cause complications with frequent import/export for working externally with the subscriber/subscription data... not to mention that we'd carry that along for at least a year (= minimum plan duration) and for close to 17,000 subscriptions from day #1. Also unfortunately, this use case isn't about content restriction or similar, but about web-based subscription/subscriber management, and multiple "same purpose" plans would complicate things greatly.

So, neither can I expect the client to easily nod off such workaround, nor would I fancy needing to put in a whole lot of extra hours, effort and risk for dealing with the ramifications of it.

CB and CBSubs ticking almost all of our boxes thanks to on-board tools, I was glad I found it, and I consider the time on getting my head around it and dollars well invested. You can tell, it'd be sad if I had to bail out again to go back to my other "Plan B" solution, but the glitch we're talking turns out to be quite essential at least in this case.

Long story short:
1.) It'd help hugely if you or Beat could indicate that "ETA" of the fix.
2.) If you want me to test your mods (instead of you yourself spending time on it), fine - I'd need to do so anyway, haha.
3.) If you could give me pointers where to look for the code, I'd go try modding myself and report back to you. I just want this to work...


Thanks again, also for keeping me posted.

1.) It'd help hugely if you or Beat could indicate that "ETA" of the fix.

If it's simple then hopefully sometime this week. Otherwise I don't know. Can't say anything for now as we've yet to review the bug further beyond making the bug ticket. We'll have to duplicate the scenario, test, then debug the source to find the cause. We've a relatively decent idea of what's causing it though. The funny thing is the reverse scenario works flawlessly. By that I mean if you have a paid plan made free it acts like a free plan perfectly fine. So it's likely a bad IF check somewhere.

2.) If you want me to test your mods (instead of you yourself spending time on it), fine - I'd need to do so anyway, haha.

Once fixed we'll be able to push a new nightly release immediately.

3.) If you could give me pointers where to look for the code, I'd go try modding myself and report back to you. I just want this to work...

We don't know yet, but it's likely a hard check against the plan price instead of the totalizer price (totalizer is with integration calculations like promotions and tax).

Try creating a negative promotion that's always applied to every plan and has no conditions. Next see if it still bypasses the basket. It's possible the conditions are what are causing it to bypass as if the promotion was never applied. If still not working then I suspect as explained above it's checking against the wrong price value, but still doesn't make sense why the reverse works.

krileon wrote: Try creating a negative promotion that's always applied to every plan and has no conditions. Next see if it still bypasses the basket. It's possible the conditions are what are causing it to bypass as if the promotion was never applied. If still not working then I suspect as explained above it's checking against the wrong price value, but still doesn't make sense why the reverse works.

Created a new, very simple and straight-forward test plan (price = 0) and a very simple promotion with negative fixed value and no conditions or limitations.

Yes, it still bypasses the basket. So, I guess as you said the issue is not caused by the conditions but some "inconsistent" IF...

P.S.: Sure, I also unpublished all other promotions, so only the one for test purposes was published.

Ok, then it looks like it's basing its condition off the wrong price. Still weird that it works in the reverse. At any rate this is all valuable information for Beat to track down the issue as quickly as possible.

Hi Kyle & Beat,

A week has passed, and I'm left with appr a week within my first 30 days... so, please allow me checking: any news on this?

I see there's a CBSubs nightly build dated 03/03, but haven't installed it, yet. Or should I because it contains the fix for the issue?

Anyway, thanks for a brief update on the subject!