Paul

Check to make sure you have Mailparse - http://pecl.php.net/package/mailparse Also, don't use the pipe.php option, pipe to index.php instead as described here - http://docs.blesta.com/display/user/Support+Manager#SupportManager-EmailPiping

It's actually simpler than that. Edit your Universal Module Product. Under "Service Options" scroll down to the form with "Notice" in it. For the "Add" option, add your email address in Post URL/Email. Expand the "Email Notification" section, and set the From Email, Subject and message. Use the {% debug %} tag in the message and run a test. It will spit out all the fields available to that template, which you can use to customize it.

They should update their site to mention OpenVZ.. but I get the feeling they don't really care. http://memegenerator.net/instance/31615631

The module supports both KVM and OpenVZ. You select the virtualization type when creating a package using the Proxmox module.

It's possible yes, but probably not likely for your bootstrap conversion. We're planning to do this ourselves for 3.2 and it's likely we'll go a slightly different direction than you have.

I remember talking to Cody about SolusVM mapping and it sounded challenging due to the differences in how they do things so we skipped over it initially. We'll be taking another look at this

CORE-494 - Add client ability to reset password for cPanel, DirectAdmin, Interworx services.

Curious if you're still seeing any issues with ticket assignments.

We have to make a lot of assumptions if we start voiding invoices and cancelling services. To start, cancelling a service would be immediate and permanent. If you accidentally mark the client as inactive, you've done something potentially disastrous. If we void an invoice that had a partial payment, that difference is then returned as a credit. If we do none of this, but simply stop billing people with active services whos accounts are marked inactive or fraud, and the account becomes active again later -- those services will be back billed from the time the account was made inactive. So, the simplest, most straight forward way to handle it is to manually void and cancel. Marking the client inactive or fraud prevents them from logging in, and designates the account as such in the system. We want to leave you with control over how to handle any open invoices and active services.

Any preference to where this would appear on an invoice? Toward the bottom, below all line items?

I have assigned this to CORE-852 Add support for vault to quantum gateway.

This is something we'll be looking at pretty soon. If there are no configurable options, we would like to skip that step entirely. It's a little bit complicated because the order system isn't aware whether the module has these options or not which is why it works as it does at the moment.

Physical products that need to be shipped out are likely better suited for a shopping cart like Magento. There are a few things that would need to be added to Blesta to give better support for physical items. Ability to sell "one time" items that don't stay listed as active services. The ability to check out without having an account. Ability to request separate shipping information, and management interface changes to track this Tie ins with shippers like UPS/Fedex/USPS And probably some more stuff You could fudge it and make it work, but if you're doing any kind of volume I'd suggest a shopping cart like Magento.

I haven't heard of Naxis before, but curious where this goes. Will you be publishing a recommended rule set?

We've talked about a package clone ability, drop you into the create a new package form with all the details copied in. It's a good idea, any more +1's?!

If they are anything like some of the USB barcode readers you can buy, they just scan and convert it into numbers and input the value into a form field. I'm sure the proprietary ones like the paypal card reader only works with their app.. but maybe there's a generic card swiper out there,.. someplace?

I suggest looking at tickets specifically immediately before and after this one. If something shifted, it's likely that one and everything after it would be wrong.

Doesn't APF/BFD have issues with virtual servers? We use to use it and switched to CSF/LFD because of it if I recall. Maybe we can nudge Interworx towards CSF/LFD.

The importer should install the support plugin automatically.

I'm pretty sure the card readers could just input the card number into the appropriate field in Blesta on swipe, through the browser on your device (iPad or whatever). There's a lot that can be done to support this more fully, like a mobile interface, and some tweaks with card present in mind.. but yeah, not high priority at the moment.

Why not cancel any active services, and void any open invoices?

I think people are starting to realize that it's time to move on, and we're grateful for everyone that decides to make Blesta their billing application of choice.

We submitted a responsible disclosure document to them today, all issues we found were confirmed to still be issues in their latest release. We'll see how they handle it.

Very nice! I'm a fan of getting things to work optimally with few resources. Then, just scale it up as you need. For a HA setup, heartbeat with 2 dedicated servers is a good way to go. I have set up a couple applications similarly in the past and it works pretty well.. The only issue I've had besides the pain in resyncing MySQL from slave back to master after a failover is failover flapping with heartbeat when there is an issue with the switch or router on the public network. With 2 servers I usually just use a crossover cable for the private network for heartbeat.

Good idea Also, it sounds like we're going to be adding some reporting to the importer to try to identify how long different operations are taking. We might be able to optimize some things and speed the importer up.. but it is doing a lot of stuff, including decrypting and encrypting credit card and other data. Some tasks are just going to take a while, but I can understand the frustration of waiting and then getting an error. I appreciate all the feedback everyone is giving us, and your patience. When we first released this, it worked perfectly with our tiny little test data set. More people, and more data expose little issues that we can better accommodate, so thanks!