Chris van der Westhuizen

Using apache2, php 7.0.16 on blesta 4.1.2 on Ubuntu.
I also run the cron job with no results or error results although it gets executed each 5min blesta says the cron job run on the time I last ran it manually. Even when running from ssh as: /usr/bin/php -q /var/www/html/billing/index.php cron > /dev/null 2>&1
I then run it again in ssh but without the > /dev/null 2>&1 and receiving the  "error: the ionCube PHP Loader needs to be installed..." although I know it is installed because blesta is working then.
I remember then there is different versions of php, thus running php -i | grep -i 'php.ini' with result:Configuration File (php.ini) Path => /etc/php/7.0/cli  Loaded Configuration File => /etc/php/7.0/cli/php.ini
the ioncube modules is not loaded for php cli, I then added the following at the top of the php.ini file zend_extension = /usr/lib/php/20151012/ioncube_loader_lin_7.0.so
Then when I ran the cron job, it actually gives me the same results as when I run it manually.  I then included the > /dev/null 2>&1  at the end, and since then my cron job problem was sorted.
:-)
 

Ahhh! I clicked on Make Payment on the left panel below the client details, Instead of "Record Payment"! 

Login to the client area at https://account.blesta.com/client/login and click Manage next to your Owned license, then Addons on the left, and select it from the drop down menu. There are only 2 options, Support & Updates and the License Manager. Select the License Manager and continue to checkout. Once purchased, you can also use it on any dev licenses you have for non-production use.

you have to have a owned blesta license for buying the license manager.
to quote paul:
 

Just to add, the License Manager consists of a plugin (License server) and module (License generator).
https://docs.blesta.com/display/user/License+Manager
https://docs.blesta.com/display/user/License+Module

You can do the Blesta license manager but you have to pay for it to be added to your license then you can add it via: https://blesta.store/plugin/support_manager/knowledgebase/view/7/how-to-use-the-license-manager-plugin/

Hi @Chris van der Westhuizen,
it would be {contact.id_code} for a paid invoice, please see the below
https://docs.blesta.com/pages/viewpage.action?pageId=4161645
You can see the other email templates at the link below:
https://docs.blesta.com/display/user/Email+Templates

The plugin can inject a item menu to blesta, see download manager,  order an support manager to see a example .

Hi All
We managed to pull magician on ourselves in regards to the dates having them disappeared for a short time.
There's the trick... someone in our department removed the Date Format and Date Time format under settings's Localization.
After changing it back to Date Format: d M Y  and Date Time Format: d M Y G:i:s  we had the dates in the invoices and everywhere again ?

Not sure you could do that if you wanted to keep the client and simply make them inactive.  A client without a contact seems problematic.
If you are looking for relations on the client_id then there are some others.
module_client_meta - Blesta Core client_notes - Blesta Core client_packages - Blesta Core client_settings - Blesta Core client_values - Blesta Core reseller_pricing_clients - Reseller Pricing support_tickets - Support Manager You should also be concerned with tables related on the contact_id
accounts_cc, accounts_ach - Blesta Core contact_numbers - Blesta Core contact_permissions - Blesta Core log_contacts - Blesta Core support_replies - Support Manager download_logs - Download Manager mass_mailer_tasks - Mass Mailer I think that covers everything you missed.

Thank you Tyson. I'll go with the docs option. thus will use admin/settings/company/plugins/manage/PLUGIN_ID/?action=refreshmappings or addmappings etc.

Hi All, I hope the following can help you.
What I do in the meantime is moving the services etc over to the new client and close the old client.  In my case we don't need to move everything.  The services are important for us to be on the new client.  Thus I used the code below, although it is not a complete script moving everything you might want to move, it did it for us, and can maybe help others.  I commented the update queries with -- for me not to run it by accident ? .  find below:
--blesta move services from one client to another. (the values entered was for my testing)
/*Step 01*/
use billing;
set @var_id_value_from=1195; /*from client code, not id*/
set @var_id_value_to=1205; /*to client code, not id*/
set @var_id_from=0;
SELECT `id` into @var_id_from FROM `clients` where `id_value` = @var_id_value_from limit 1;
set @var_id_to=0;
SELECT `id` into @var_id_to FROM `clients` where `id_value` = @var_id_value_to limit 1;
select @var_id_value_from, @var_id_value_to, @var_id_from, @var_id_to;
SELECT * FROM `clients` where `id` = @var_id_from;
SELECT * FROM `clients` where `id` = @var_id_to;
SELECT * FROM `services` where `client_id` = @var_id_from;
SELECT * FROM `services` where `client_id` = @var_id_to;
--update services set `client_id` = @var_id_to where client_id = @var_id_from;
/*skip this only for testing*/
select * from service_fields where service_id in(324); /* no action needed */
select * from service_changes where service_id in(324); /* no action needed */
select * from service_options where service_id in(324); /* no action needed */
select * from log_services where service_id in(324); /* no action needed */
select * from package_pricing where pricing_id in(33); /* no action needed */
select * from packages where id in(26); /* no action needed */
select * from pricings where id in(33); /* no action needed */
/*Step 02*/
select * from client_packages where client_id = @var_id_from; /*change client_id from to */
--update client_packages set `client_id` = @var_id_to where client_id = @var_id_from;
/* assuming that the clients's currency, and tax status is the same, and you want to move all services from one client to another
then you can do the invoices and transactions as well */
/*Step 03*/
select * from support_tickets where client_id = @var_id_from; /* service_id in(324); *//*code = 9462313;*/  /* change client_id from old client id to new client id (not client_id_value) */
/* the support_tickets are linked to support_replies which are linked to contacts that are linked to the current client.
if you want to move the support tickets related to the service_id, I will suggest moving the contact first to the new client.
but the contact is linked to a lot of tables.  For my purpose I deside to leave the support_tickets at the old client and just make the support_tickets.service_id = null
*/
--update support_tickets set client_id = @var_id_to where client_id = @var_id_from; /* should I or not, in regards to the comment above? */
select * from support_replies where ticket_id in(select ticket_id from support_tickets where service_id in(324)); /* no action needed if not moving the tickets with services to new client*/
/*Step 04*/
select * from service_invoices where service_id in(324); /* no action needed */
select * from invoices where client_id = @var_id_from; /* id in (37106,38781);*/ /* change client_id from old client id to new client id (not client_id_value) */
-- update invoices set client_id = @var_id_to where client_id = @var_id_from;
select * from invoice_lines where invoice_id in(37106,38781); /* no action needed */
select * from invoices_recur where `client_id` = @var_id_from; /* change cleint_id fom old client to new client */
--update invoices_recur set client_id = @var_id_to where client_id = @var_id_from;
/*Step 05*/
select * from transaction_applied where transaction_id in(select id from transactions where client_id = @var_id_from); /* no action needed */
select * from transactions where client_id = @var_id_from; /* change old client_id to new client_id. make transactions.account_id = null if account not account will not also be moved to new client, like in my case */
--update transactions set transactions.account_id = null, client_id = @var_id_to where client_id = @var_id_from;
Then I closed the old duplicated client in Blesta.

have fun! ?

The AdminManagePlugin controller is a special controller (see docs for reference) that loads the plugin management controller from /admin/settings/company/plugins/manage/PLUGIN_ID/ in Blesta. If you want your mapping to be managed similarly, you should create methods in AdminManagePlugin to do so, and use GET arguments to request your specific AdminManagePlugin method (e.g. "AdminManagePlugin::refresh" is called when visiting admin/settings/company/plugins/manage/PLUGIN_ID/?action=refresh).
If you want to manage your plugin elsewhere, such as from its own page, you can certainly do so however you'd like, as the plugin's controllers can be requested directly at their own URI, e.g. /admin/plugin/feed_reader/my_controller/my_method/

Thanks Blesta Addons, I'll keep in touch.

Thank you Tyson.  I completed as complete as possible the EER_Diagram on MySQL Workbench, but do have +/- 10 relationships I am not sure about.  Should I attach the wbs, sql, pdf copy of the layout with the questions here, or should I rather email these files first that we upload them here when done, or make them part of the documentation?  I think if I had something like this, I would have been on the road to success long ago.  I'm not complaining, Thank you very much for the current documentation it helped me very much, as well as this forum. ?

i did create an EER Diagram using MySQL Workbench's Reverse Engineer option, but it is not linking the table fields. Although the naming of the tables and sub tables and fields is self explanatory, I am not sure if I should link an id of id_value field to an appropriate table without investigation, because there is no primary foreign key relations on the diagram, thus not in the db.

Does someone have a blesta database diagram showing primary/foreign key relations etc.?
It will save me time composing one for quick reference while developing modules/plugings.
Kind regards
Chris

i did create an EER Diagram using MySQL Workbench's Reverse Engineer option, but it is not linking the table fields. Although the naming of the tables and sub tables and fields is self explanatory, I am not sure if I should link an id of id_value field to an appropriate table without investigation, because there is no primary foreign key relations on the diagram, thus not in the db.

I hope this can be helpful for someone else with the same problem as I had.
I noticed on our servers that mailparse was only installed for cli and fpm and not for apache2, thus I had to include it for Apache too as follows:
we are using apache2 with php7.0. on ubuntu 16.04
1. find path of file mailparse.ini:
# cd /; find / -name *mailparse.ini
/etc/php/7.0/mods-available/mailparse.ini
/etc/php/7.0/fpm/conf.d/20-mailparse.ini
/etc/php/7.0/cli/conf.d/20-mailparse.ini
2. I then copy mailparse.ini from cli to apache2 and needed to edit and include the full path:
# cp /etc/php/7.0/cli/conf.d/20-mailparse.ini /etc/php/7.0/apache2/conf.d/20-mailparse.ini
# nano /etc/php/7.0/apache2/conf.d/20-mailparse.ini
and add full path as: extension=/usr/lib/php/20151012/mailparse.so
the full path I got from running # find / -name *mailparse.so
3. Restart Apache:
# systemctl restart apache2
4. See if apache restarted without errors:
# systemctl status apache2
and now my test.php file with phpinfo(); shows mailparse support! :-)

The mail log is just a log of what was sent. If there are invoices that upon edit have the email box checked, they will be sent at the first opportunity. The solution to having these all go out, is to mark all invoices in the system as sent. I think this query will do it for you, but be sure to backup your database first!
UPDATE `invoice_delivery` SET date_sent="2018-03-12 00:00:00" WHERE date_sent=NULL AND method="email"; Query will set a sent date for all invoices that have not been sent and are queued for email delivery.

You are correct about the ">/dev/null 2>&1".  I should have my last sentence to read " at the end, and since then and after doing all of the above my cron job problem was sorted. "  I just removed momentarily the >/dev/null 2>&1 to give me visible results.  :-) thanks
Regarding the php.ini file for the cron job path.  phpinfo from the website returns:
Configuration File (php.ini) Path /etc/php/7.0/apache2 Loaded Configuration File /etc/php/7.0/apache2/php.ini whereas through ssh command: php -i | grep -i 'php.ini' returns:
Configuration File (php.ini) Path => /etc/php/7.0/cli
Loaded Configuration File => /etc/php/7.0/cli/php.ini
when using the latter path from ssh command my cron job was running correctly.

I found that my staff had more that one record with the same name in WHMCS for some reason, although in the WHMCS front end no duplicates shows. I deleted them and tried the import again, and Voila! :-) 

I found that my staff had more that one record with the same name in WHMCS for some reason, although in the WHMCS front end no duplicates shows. I deleted them and tried the import again, and Voila! :-) 

I found that my staff had more that one record with the same name in WHMCS for some reason, although in the WHMCS front end no duplicates shows. I deleted them and tried the import again, and Voila! :-)