NetworkJack

UPDATE Took a little more tweaking. I made two specific changes: It was necessary to add a fourth parameter to the UniversalModule->processService method to get the ServiceMeta into the notification POST data for Adds and Edits. I consciously delayed merging that data as long as possible. (see $NotifyVars) The old service fields data is passed along on an Edit to help the remote service know how to locate the record(s) being changed. public function addService($package, array $vars=null, $parent_package=null, $parent_service=null, $status="pending") { $ServiceMeta = array('package_id' => $package->id, 'module_id' => $package->module_id, ); $meta = $this->processService("add", $vars, $package, $ServiceMeta); public function editService($package, $service, array $vars=array(), $parent_package=null, $parent_service=null) { $ServiceMeta = array('client_id' => $service->client_id, 'service_id' => $service->id, 'package_id' => $package->id, 'module_id' => $package->module_id, 'old_service_fields' => $service->fields); $meta = $this->processService("edit", $vars, $package, $ServiceMeta); private function processService($type, array $vars, $package = null, $ServiceMeta) { if (isset($vars['use_module']) && $vars['use_module'] == "true") { $NotifyVars = array_merge($vars, $ServiceMeta); if (!$this->sendNotification("service_notice_" . $type, $meta, $module_row_id, $NotifyVars, $package->meta)) { $this->Input->setErrors(array('service_notice_' . $type => array('failed' => Language::_("UniversalModule.!error.service_notice_" . $type . ".failed", true)))); return; } }

I've been working on converting our 2.5 Blesta up to a recent version (3.6.x) and one of the things I've been dealing with is replacing a custom integration module we had that allowed us to modify usernames/passwords in a mysql table that was used for RADIUS authentication. I've decided to KISS and use the Universal Module and have it make POSTs to a server that does the actual work of modifying the records as needed for add/edit/cancel/ etc..... The only issue that the information passed in a POST for a Cancel/Suspend/Unsuspend is woefully inadequate to meet our needs of 100% properly identifying the record to modified. In Add/Edit, there is the _other variable that gets data set into it that are not being sent in the other actions. Only the Service level fields are sent. No client ID or Service ID, etc... So I did a little digging in the source code and some debugging and ended up making one simple little change to the following methods: UniversalModule->cancelService UniversalModule->suspendService UniversalModule->unsuspendService UniversalModule->renewService public function cancelService($package, $service, $parent_package=null, $parent_service=null) { $ServiceMeta = array('client_id' => $service->client_id, 'service_id' => $service->id, 'package_id' => $package->id, 'module_id' => $package->module_id, ); if (!$this->sendNotification("service_notice_cancel", $service->fields, $package->module_row, $ServiceMeta, $package->meta)) { $this->Input->setErrors(array('service_notice_cancel' => array('failed' => Language::_("UniversalModule.!error.service_notice_cancel.failed", true)))); return; } return null; } Basically it's that $ServiceMeta array that is populated and then sent in the fourth parameter ($additional_fields) to UniversalModule->sendNotification. This way the receiving endpoint will have all the information required to reference whatever is needed. BTW, this bit of code should help satisfy this Feature Request: http://dev.blesta.com/browse/CORE-1698

/admin/billing/invoices/recurring/ 1. I have very little interest in what the ID # of the recurring invoice is. 2. Show me the next renew date 3. Show me the client name (or a portion of it) 4. Show me the date of the last invoice created for each item.

If you are like us, the only supported protocol for accessing Blesta is via https. To that end, all links sent in emails should have https based links instead of the default http Here is a quick SQL call to make that happen without having to go into the interface and change each email template manually: UPDATE `emails` SET `text`=REPLACE(`text`, 'http:', 'https:'), `html`=REPLACE(`html`, 'http:', 'https:')

Just added Support Manager plug-in myself to a 3.6.1 install and during setup, I had to perform the following ALTER TABLEs: ALTER TABLE `support_replies` ADD `contact_id` INT UNSIGNED NULL DEFAULT NULL AFTER `staff_id` ALTER TABLE `support_departments` ADD `override_from_email` TINYINT NOT NULL DEFAULT '1' AFTER `clients_only` , ADD `close_ticket_interval` INT UNSIGNED NULL DEFAULT NULL AFTER `override_from_email` , ADD `response_id` INT UNSIGNED NULL DEFAULT NULL AFTER `close_ticket_interval` If I run into any other tables issue I will post my "fix".

So what happens on an import from 2.x into 3.x? Do those fields get combined into the Check/ID # field?

As I said, the Notes field is not there:

In Blesta 2.x there was a Notes field when entering in a manual payment. It is where I put the name of the bank on the check. Now in 3.x, that field is no longer there. Is it safe to expose the "reference_id" field from the "transactions" table on that form for entering that info?

I'm trying to migrate from a old home-grown FileMaker Pro system over to Blesta 3.2. I'm working on using the API to perform that migration and I would really like to keep the same client ID. From I can see, I might be able to use ::add, but not ::create to do so, unless... I made this patch to ::add in Clients model: $calc_next_id_sql = "IFNULL(GREATEST(MAX(t1.id_value),?)+?,?)"; if (!empty($vars['client_id'])) { $calc_next_id_sql = '?'; $values = array($vars['client_id']); unset($vars['client_id']); } $sub_query->select(array($calc_next_id_sql), false)-> so if I pass client_id in to the method, it will get used instead of auto-calculated.