Jonathan

If you use that MySQL query I posed it returns that data

Sounds like you need to get the plan name from the pricing ID? You're going to need to do a MySQL query or use Packages::getByPricingId Something like this should get you headed in the right direction if you go the MySQL route: select * from package_pricing left join packages on package_pricing.package_id=packages.id left join pricings on package_pricing.pricing_id=pricings.id;

Conditionals will be amazing to have!

+1

This is mimicked on the client-side as well.

When changing the hostname on an OpenVZ container, it gives a warning that the change will not take effect until after a container restart. This is not true, it takes effect immediately as OpenVZ does not require a reboot for hostname changes.

Point is, all Blesta needs to do is tidy that up a bit (maybe?) and stick it in there

Having an Enom module is great. Having domains expire because the module can't renew them isn't so great. This is a critical feature to anyone using Enom to register/manage domains.

This should only apply to invoices which have been generated, but aren't due yet for the very reason you stated. If it's past due, it should remain as obviously some form of service was rendered.

Since in OVZ to have no swap/burst, this setting must match memory we now have to have two dropdowns and hope the customer chooses right as to not confuse the system. The previous functionality where memory/swap can be passed together prevent this from being an issue but in it's current state the memory/swap additions are pretty much useless for anyone on OVZ who doesn't offer swap/burst. Looks like CORE-1681 should fix this

The client side has that nifty new price preview for a customer before generating invoices and queueing the changes. The admin side should really have this as well to save clicks, as well as add functionality that couldn't be achieved through a client-side login "workaround" such as changing them to an "inactive" or "restricted" package, etc. where they might want to know the price beforehand. This is a very common request so the ability to get it for customers is very important and given the client login workaround won't always work due to the case mentioned above, having it in admin too is a good solution. As much as well all like to think clients can self-service, this isn't the case all the time and tons of people would rather send an email and ask the company to do it.

This feature is pretty necessary for anyone using the universal module to sell dedicated servers, VPSs, or anything else where a field, such as IP, should be settable/editable by staff but not the client as obviously the client doesn't know what it is/should be. It's a very important one for me

Customer has 3 services. All are invoiced on the same day, on the same invoice. They request cancellation for one immediately, and for the other at end of term. One service should remain active, two are dead/shouldn't be paid for anymore. Those two still tied on the invoice with the one cause the remaining one to get suspended when they assume they don't need to pay the invoices for the service they've cancelled. When a service is cancelled, the corresponding line-items should be removed/voided if it leaves no line items left (if the service is not yet due/has yet to renew but has only been invoiced).

A setting allowing a client's account to always have invoices generated separately for each service would be wonderful. This is a common request of large resellers I assume for record keeping purposes and ease of management for them and I'd also imagine to keep one service from getting suspended due to someone else not paying, or all services from one not being paid, etc.

Play nice, no need to attack people

They do care about it. Check the dev tracker, they've been busy on bigger features than a mass mailer. We all want mass mailer, but ya gotta prioritize

Sounds like a good feature request to me.

+1. This would be extremely handy for manually generated invoices for things which do need to be tied to a service.

http://dev.blesta.com/browse/CORE-1661

+1

Looks like Swiftmailer supports some types of encryption: http://swiftmailer.org/docs/messages.html#signed-encrypted-message

Confirmed client side lacks extra window titles. Admin side is fine.

Looks fine to me. See attachment.

I'd not expect them to ever be able to cross modules. That'd simply be unreasonable and I can't think of a usage scenario for that since you're have to be actually changing products or something. Perhaps in the UI (admin side) there should be a separate dropdown for plans belonging to other package groups, perhaps triggered/displayed by clicking a button which turns into the dropdown which could override the main dropdown thus letting you "force" the package over to one from a different group? This would let everything else be handled inline as it should be. Compatible configurable options would move over, ajax would update page to add/remove them accordingly, etc. On the other hand, instead of a button and completely different dropdown it could just be a tickbox that'd simply update the existing dropdown with the "override" options aka plans from other package groups?

+1 for Tyson/Paul's version of implementation.