Cody

Like I said in your other thread, you just need a plugin to do this. It's pretty basic, really. Email sales or open a ticket and we can discuss.

Email sales or open a trouble ticket and we can discuss.

You'd have to hire a PHP developer. We might be interested though, contact sales or open a trouble ticket and we can discuss.

The Events object is already loaded and available to AppController, so no need to load it. public function triggerEvent() { \BlestaLogger::addDebug("plugins/yourPluginName/controllers/InvoiceTester::triggerEvent()"); $this->Events->register("Invoices.add", array("EventCallback", "triggerPluginEvent")); $event = new \EventObject("Invoices.add", array('foo' => 'bar')); $this->Events->trigger($event); \BlestaLogger::addDebug("plugins/yourPluginName/controllers/InvoiceTester::triggerEvent(-)"); } // in /components/events/default/event_callback.php unless you've loaded it prior to $this->Events->trigger() class EventCallback { public static function triggerPluginEvent(EventObject $event) { } }

Thanks for the input. We certainly encourage developers to include whatever debugging libraries they would like to use (that's why the source is there). Unfortunately, Blesta (and minPHP) has a strict PHP 5.1.3 requirement, so until 5.3+ becomes almost entirely unverisal we can't make namespaces, etc. a requirement. The good news is that things are moving in that direction. Perhaps in a year or so.

Totally. You'll just need a plugin to either automatically poll your activity stream to generate invoices, or to allow you to upload acitivity reports and invoice from those.

Do you mean you imported clients from WHMCS and they all had customer ID 15? Or do you mean after importing clients from WHMCS all new clients have ID 15?

Yes event listeners are cached in the database. Maybe it should be stated in the developer manual as well, but the getEvents() method is only called after install() and upgrade() as per the Plugin class.

Sounds to me like the Blesta cron user doesn't have mysqldump set in their environment path variable. As for locks, they're not required at all. The only time it's used is for mysqldump execution, though that's only because your default database setting is to lock tables on a dump. Perhaps a feature request is in order to allow users to choose whether or not to lock on database dump (i.e. mysqldump --single-transaction --quick)?

We're getting very close to a 3.1 beta release.

Your URL probably isn't properly formatted. You have to make sure your URL parameters are properly encoded, for example: <?php // The key from [Settings] > [Company] > [Plugins] > [Shared Login] $key = "0123456789abcdef0123456789abcde"; $t = time(); $u = "client_username"; $r = "http://mydomain.com/"; $h = hash_hmac("sha256", $t . $u . $r, $key); $params = http_build_query(compact("t", "u", "r", "h")); header("Location: " . "https://yourdomain.com/path_to_blesta/plugin/shared_login/?" . $params); exit; ?>

It's up to you whether you allow the invoice to be changed or not. We have plans to include snapshot invoice documents to preserve name/address information on invoice PDFs, for example, in a future release. There are a few issues with this. For one, invoices in Blesta can not have a total due of a negative amount. To have a negative invoice would mean that you owe the customer money. Secondly, the meaning of void is "to have no effect," so void invoices are not included in any invoice total calculations. That means that your negative void invoice would not cancel out the debt of the active invoice. That said, you could write a plugin that listens for the Invoices.edit event, and make changes to or create new invoices if an invoice is marked as void. But that event isn't available until 3.1. Not sure what you mean here. If by row you mean invoice line item, yes you can do that. Invoices don't exist until their date billed has come up. For example, if you create an invoice on 2013-11-28 set with a bill date of 2013-12-01, the invoice is not available until 2013-12-01. The customer can not see it, and it will not be delivered until that time. This is a feature of Blesta that allows you to create invoices in advance without those invoices being made available to clients.

Not sure what you mean here. Every transaction that is recorded shows when the payment was made and to which invoices. The invoice then shows all items that the invoice covers, which includes any services. Yes, Blesta allows an invoice to be paid by several transactions as well as serveral transactions to pay a single invoice. The connection between the payment gateway and the transaction is stored in the transactions table (see transactions.gateway_id, or better yet Transactions::get()).

Invoice line prices either come directly from the package pricing or are derived from the package pricing to the desired currency at the time the invoice is created. To determine the currency exchange rate at the time the invoice was created would require Blesta to store the exchange rate of the invoice currency in relation to the derived currency. To do this you would need to handle the Invoices.add event, available in Blesta 3.1, and use a plugin to create a table to store exchange rates for invoices, then use that table to display that information in your Invoice Template.

BTW, CORE-136 is scheduled for 3.2.0 and will allow users to specify the path to the mysqldump executable.

The problem here is that as far as I can tell, there is no way to prevent a user from submitting payments to your paypal account (via Blesta or what have you). So unless the option exists in your PayPal account to only allow verified users to submit payment I can't see how we can prevent those payments from being deposited. PayPal doesn't offer a way to say "oh, hey, that payment you just sent me... I don't want it." The only thing that could possibly be done is after receiving the payment, check the verified status of the account, and if not verified then issue a refund. That seems sloppy to me. I'd expect PayPal to offer an option in your PayPal account that says "only accept payments from verified accounts." Only PayPal has the capability of preventing a user from submitting payment. It's outside of our control.

You can get it here: http://www.blesta.com/forums/index.php?/topic/960-whmcs-migrator-beta-updated-2013-11-12/

Thanks for the report. Added CORE-888 to enforce that only one 'primary' contact type can be added per client_id. The default contact will remain as 'primary' per the schema as the most common use for a contact is for a client record. There should logically only be one primary contact per client, and I agree the system should enforce it through input validation. Superfluous.

Well, it's pretty simple. Clients go in the clients/users table. Staff users belong to staff/users table. Invoices go in invoices/invoice_lines/invoice_line_taxes. Everything else follows the same pattern. You certainly can, and I would recommend it. Though admittedly, we haven't made any documentation available on how the plugin works as we never really anticipated others would want to extend it. We don't release this kind of information due to typical commercial/IP reasons. That's for version 2.

Yes. Users don't always have the same username across all systems, so you will need to store the user's Blesta username in that other system in order for them to log in. If both systems use the same email address for their username this can simplify things. As long as you properly keep track of usernames across systems you should never have a problem where you let user A log into user B's account. See using the shared login plugin for details.

What was the name of your bucket? As per AmazonS3 bucket rules, a bucket can not start with, end with, or contain more than one period in a row.

The shared login plugin is now available. Get it here. Documentation here.

Paul and I recently had a discussion about quotes on the ride home. I believe the conclusion we came to is that it will not be part of the project management system (though it will be tightly integrated with it). It may be added to the core or offered as a stand-alone plugin instead. I fancy the plugin idea myself. We're still working out all the specs.

I like this idea. My thoughts are staff titles would be configured under the support staff user page (i.e. where support user day/times are configured).

Plugin coming for this soon. See this thead.