Leaderboard

Additionally you could do this mysql query on your database: --------- SELECT * FROM `log_cron` WHERE `run_id` !=0 AND `end_date` IS NULL ORDER BY `start_date` DESC; ----------- In case you have result, that mean some tasks in your cron are locked/bugged, and you should remove these lines, and it's will help blesta be able to run locked tasks

Blesta does not show the subscription button for invoices that contain non-recurring items. In this case, there is no link between the invoice and any recurring services, so Blesta does not know if it's a one time invoice or if its recurring. Recurring invoices simply stamp out new invoices at a designated schedule.

Payment accounts are for merchant gateways only, and do not work with non-merchant gateways like PayPal. The PayPal gateway supports both one-time and recurring options if configured to accept both. The client can choose whether to make a one time payment or a subscription. With PayPal subscriptions, the payment schedule is set on order and controlled by PayPal. Using their IPN, they notify Blesta when a new payment has been made. The process is separate from Blesta after initially set up, aside from the notification to Blesta. As such, payment accounts are irrelevant.

He means he's using it as-is, without modification. When viewing the logs, as in your screenshot, you can click on a table row to list more information. It may say something about which services were made active from the Provision Paid Pending Services task. You mentioned there was a delay in the pending services being marked active. I suspect that may be because the cron took a few minutes before it ran the Provision Paid Pending Services task. If a pending service has been created, and the invoice for it has been paid in full, then the cron will automatically provision it by changing it from pending to active. If you're looking at the [billing] -> [services] -> (Pending) page, you will only see pending services at the time you viewed the page. The page won't automatically update the services in the list when one has been made active. Next time you go to the [billing] -> [services] -> (Pending) page, and there are pending services, try immediately refreshing the page several times to see if any services disappear. Then wait until the cron runs and check the logs to see whether the cron provisioned them automatically.

Was the renew date for the service set to March 1 initially? When did you first enable the cron, was it more than 15 days prior to March 1st? Blesta will play catch up if it misses a renewal, and the renew date won't be bumped unless/until an invoice is generated. So, if you have it set to 15 days, and the renew date is March 1st, I don't see why it wouldn't invoice those unless there is a problem with the cron running. Under Settings > Company > Automation, does "Create Invoice" say it has run today? Since client groups can have independent settings from each other and the company, check that the client groups are inheriting their settings from the company or are also set to 15 days under Settings > Company > Client Groups.

The backup uses the mysqldump binary, which must exist on your system. If you have SSH access, you can type "whereis mysqldump" to see if it exists. While Blesta may be able to make the SFTP connection successfully, it may not be able to generate the backup file if mysqldump is not available.

Ok I think I have this working, After looking at the database and how the cron works: note that run ID 19 is "download tickets" as below: mysql> SELECT * FROM cron_tasks WHERE `id` = 19; +----+--------------+-----------------+------------------+------------------------------------------------------------------------------------+---------+----------+ | id | key | plugin_dir | name | description | is_lang | type | +----+--------------+-----------------+------------------+------------------------------------------------------------------------------------+---------+----------+ | 19 | poll_tickets | support_manager | Download Tickets | Connects to the POP3/IMAP server to download emails and convert them into tickets. | 0 | interval | +----+--------------+-----------------+------------------+------------------------------------------------------------------------------------+---------+----------+ 1 row in set (0.00 sec) mysql> Then I found in another thread to look for cron_logs without a finish time: mysql> SELECT * FROM `log_cron` WHERE `run_id` !=0 AND `end_date` IS NULL ORDER BY `start_date` DESC; +--------+-------+----------------------------------+----------------------------------------------------------+---------------------+----------+ | run_id | event | group | output | start_date | end_date | +--------+-------+----------------------------------+----------------------------------------------------------+---------------------+----------+ | 19 | | bfcafb10b07f574e429303fd1b4f46a8 | Attempting plugin cron for support_manager poll_tickets. | 2015-02-23 09:20:02 | NULL | | 19 | | 5706097d22923690b0d0eed4effd07dd | Attempting plugin cron for support_manager poll_tickets. | 2015-02-23 03:20:01 | NULL | | 19 | | d9ac43b45eee404ef29fe0a03478f484 | Attempting plugin cron for support_manager poll_tickets. | 2015-02-22 20:55:01 | NULL | | 19 | | 2aa266c0262becd70a1ea157fd6c8368 | Attempting plugin cron for support_manager poll_tickets. | 2015-02-22 10:35:02 | NULL | | 19 | | a303667c33f8715ec85957819c00f42a | Attempting plugin cron for support_manager poll_tickets. | 2015-02-22 04:30:02 | NULL | +--------+-------+----------------------------------+----------------------------------------------------------+---------------------+----------+ 5 rows in set (0.01 sec) mysql> Then deleting them: mysql> DELETE FROM `log_cron` WHERE `run_id` !=0 AND `end_date` IS NULL ORDER BY `start_date` DESC; Query OK, 5 rows affected (0.04 sec) mysql> SELECT * FROM `log_cron` WHERE `run_id` !=0 AND `end_date` IS NULL ORDER BY `start_date` DESC; Empty set (0.01 sec) Now when the cron runs I can see the connection to google imap root@blesta:~# tcpdump -npi eth0 port 993 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes 15:35:01.840128 IP 192.168.10.114.42386 > 74.125.136.109.993: Flags [S], seq 2150746609, win 29200, options [mss 1460,sackOK,TS val 2057746 ecr 0,nop,wscale 7], length 0 15:35:01.846315 IP 74.125.136.109.993 > 192.168.10.114.42386: Flags [S.], seq 2080383863, ack 2150746610, win 42540, options [mss 1380,sackOK,TS val 1611920504 ecr 2057746,nop,wscale 7], length 0 15:35:01.846361 IP 192.168.10.114.42386 > 74.125.136.109.993: Flags [.], ack 1, win 229, options [nop,nop,TS val 2057747 ecr 1611920504], length 0 15:35:01.846801 IP 192.168.10.114.42386 > 74.125.136.109.993: Flags [P.], seq 1:306, ack 1, win 229, options [nop,nop,TS val 2057748 ecr 1611920504], length 305 15:35:01.852916 IP 74.125.136.109.993 > 192.168.10.114.42386: Flags [.], ack 306, win 341, options [nop,nop,TS val 1611920511 ecr 2057748], length 0 15:35:01.854500 IP 74.125.136.109.993 > 192.168.10.114.42386: Flags [.], seq 1:2737, ack 306, win 341, options [nop,nop,TS val 1611920512 ecr 2057748], length 2736 15:35:01.854549 IP 192.168.10.114.42386 > 74.125.136.109.993: Flags [.], ack 2737, win 271, options [nop,nop,TS val 2057750 ecr 1611920512], length 0 ........ output cut 77 packets captured 77 packets received by filter 0 packets dropped by kernel root@blesta:~# I can also see the email import is now working :-) Please see attached / below the final working settings for google apps hosted domain IMAP, don't forget to enable IMAP support under your google account also. Regards, Daniel

I think this idea would be a good thing to add into Blesta... A server management page where we can keep an eye on all our servers... not full on monitoring but load, disk etc That way Blesta turns into an all in one Does that make sense?

Thank you Michael, Paul and everybody else that helped me I now have a licensed installation through licensecart

i recommand Licensecart , as is a active user here and can help also from outside the forum .

Could very well be. But I have been told that tax inspectors exist outside the EU as well. Not all countries may have exact rules about what needs to be on an invoice, and what administration you must keep, but they generally do appreciate it if the information you do have is accurate, and do require that you have sufficient information for your turnover to be calculated and taxed properly. Things like back dated invoices, and dynamic address information -that suddenly may show a different state/country than originally, not matching the sales tax charged- are not going to earn you kudos anywhere.