Jonathan

Even more worrisome, it would appear that "use module" is sent when this is executed. Totally unnecessary.

This is new. Why is this necessary? It's causing unexpected behavior in plugins that use Services.edit.

You'd be much better off using IP-based blocking instead of htpasswd.

+10000000

Bump. Still causing issues almost daily

My intention was to make it public, but it turned into something very specialized to our use-case which simply wouldn't be useful for someone else.

Cool! Might have to give this a shot.

After an invoice is voided, if a one time payment link has been emailed out, it's still possible to "pay" this invoice which is voided using the one time payment link. This results in confusion if this happens after an order has been placed, no paid for some time, canceled out by admins, the customer then pays and wonders why their service wasn't setup. If a one time payment link is tied to what should be an unpayable invoice, an error should be displayed instead of allowing payment. It's allowed even if the account is marked fraud which can pose an issue as well.

http://www.blesta.com/forums/index.php?/topic/2938-clean-payment-buttons-for-paypal-paypal-subscriptions-etc/?p=35478 is definitely the most widely used generic PP button right now. It's a no-brainer. PayPal doesn't appear to have published an equivalent subscription button....there's always the classic one:

IMO a generic solution is the best way (assuming the button will still mention the name of the non-merchant somewhere) but an interim "quick-fix" to make everyone happy is fix the existing image. A generic button is more of a feature request; swapping this image is more of a "bug" fix and the two items should be treated independently as such.

But there's no reason a 5-minute task that causes so much grief can't get into 4.0. I don't understand the point of delaying something so simple as an image replacement that would curb so many complaints.

I've chalked this up to a custom modification to core that may be causing it. The only thing making me doubt that is @cyandark's claim that this happens to him too.

Blesta allows the entry of an address longer than that which is acceptable by Authorize.net. The API returns a descriptive error if you are editing account, but not creating. Blesta should either disallow entries that are too long, or return a descriptive error in the interface. Mexican addresses tend to be very long, and that's where this bug showed itself in production.

+1

This sounds like a great start. I agree with the due date reflecting what the actual due date would normally be for that invoice cycle.

Excellent!

LDAP support (for staff logins) would be very handy for enterprise-level customers that use systems such as OpenLDAP/AD.

Friendly bump before 4.0 comes out

What's new

Pretty weird one. Using the solus module, add say 20 IPs to a service. It doesn't matter if you pro-rate the addition or not (that works fine). Through the service view that lets you specifically delete certain IPs, remove one. The first one gives a pro-rata credit as it should. The second-* removals will generate credits equal to double what it should (consistently). This can be recreated over and over. As you can see in the SS, after the first, it doubled.

Knowing quite a bit about the internals and history of cPanel and their very early beginnings this statement is quite correct. A lot of these changes are because Nick is finally letting go of some power to an extent whereas in the past he's pretty much single-handedly reviewed each piece of code, rewritten lots of it, etc. In recent years cPanel finally started getting structured like you'd expect a software development company to be. I can't say I'm perfectly happy with it. While yes changes are coming much quicker these days, so are bugs. Some of that is due to how inherently large cPanel has become as a software package but some is because they're pumping out features like crazy and can't do as much QA. The "stable" tier of these days is like the "release" tier of 5 years ago stability-wise, and what was the stable tier then no longer exists due to the rate at which they're pumping stuff out.

I think the plugin should at least be able to do some pro-rata pricing adjustments. At that point it's nearly as good as a "clean" upgrade/downgrade to a different product so long as the underlying module then support some form of "set plan" button to perform the module action to upgrade/downgrade it.

This is important, for example, when a customer is in the military and has his APO address tied to his CC. Naturally the address entered needs to match said CC hence the problem with the current lack of capability to select APO addresses.

Would love to see support for US military APO addresses.

+1