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.

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.

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!