Tyson

If you are cancelling orders, you will need to cancel the pending service, cancel the order, unapply any transactions from the invoice, and void the invoice. You could use the invoices.date_closed to determine whether the invoice is closed.

You should check the records with a NULL end_date in the log_cron table of the database for more information. The 6-hour limit on ending and restarting a cron task applies to all tasks, so as long as the task is enabled in Blesta, it should operate under the same constraints.

See the documentation here.

I think you may be experiencing this issue if you're using the cPanel/DirectAdmin/Interworx module. You can resolve it by updating the package to not use a module group, or update the module rows in that group to have a high account limit: Edit the package you were ordering. Under "Module Options", change the "Server Group" to "Any". -or- Update the module row and change it's "Account Limit" to a large number.

It is a priority for us to include it in the version 4 release, so we can't drop it. It requires several core changes that need to be made anyway, which lets us factor out some code to be deprecated, and simplify the code base. These changes have to be made at some point, and there is a larger benefit to them happening now.

Just to clarify, the highlighted date in the screenshot is November 30, as shown in the date text field.

I see. It looks like the new line is added into the value, so the value is "\ntest3" rather than just "test3". I'd be curious if you placed the new line before the pipe delimiter, would it work correctly then? Areturn statement apart of the label, I imagine, should be irrelevant. e.g. test:Test |test2:Test2 |test3:Test3 |test4:Test4 In any case, the options should be set inline. No extra white space (new lines, spaces, etc.). I imagine it could be desirable for some to have a value start with a space, end with a space, or consist of only a space. e.g. test:Test| :Space|test2:Test2 However, I'd be fine with ignoring white space before and after values and labels, so e.g. test:Test| test2 :Test2 | test3 : Test3 | te st4 : Test4 would be equivalent to: test:Test|test2:Test2|test3:Test3|te st4:Test4 That behavioral improvement would have to be added. I'm curious what others think.

I was not able to duplicate the issue. When I go to manage the pending service, the correct drop-down options are selected for me. Can anyone else duplicate this behavior? The "Secret" field is only used for notifications as mentioned in the documentation. If you want the field to be displayed to just admins, you should use "Hidden".

Some code needs to be refactored to support the remaining features we're including for v4, so it's taking longer than expected to update the design and integrate those changes. Good news is that it will be a better integration in the long run. When these two tasks, CORE-1686 and CORE-1763, are complete it should be ready for beta.

I just noticed that naja7host's example of attaching the target to Form::fieldImage is not where you would want to place it. As you've mentioned, a POST request occurs, and any target attributes on links will not have the desired effect. You want to set the target on the form itself: $this->Form->create($post_to, array('target' => '_blank'));

There's no need to get upset about what happened. It sounds like the moderator over there has just misinterpreted donations to equate to financial compensation that categorize our relationship as a partner, client, employer, or friend, per his statement: > Sorry but my Blesta Signature dosent have to do anything with compensations. Does it not clearly state that you've received monies from Blesta (and others)? That creates a financially-influenced relationship between you and your donors, which puts them into the category of your "partners, clients, employers or friends.". We don't belong to any of those categories, so the statement's conclusion is false. I would also argue that the statement's premise is false as well, since contributions do not always imply financial influence between parties. He seems to have acknowledged that that argument was falling apart, so he came up with another to reaffirm his stance: > this warning is not breaking any rules I beg to differ. Aside from the principle one that brought this discussion about, you included in your post: "you will see many developpers like me sharing Plugins, Modules, Extension for free, helping blesta to grow." Beside being self-promotional, another rule applies to that which I'll quote below for you for future reference: "You may only discuss details about your company and/or product offerings when the thread starter or poster has made direct reference to your company and stated something untrue or misleading, or something which clearly needs clarifying. The response must be in direct reference to the point discussed only and contain no added promotional information and/or fluff. It is advisable when in the above scenario to contact us first." The last statement is vague and open-ended, which gives them leeway to do whatever they want. I guess you'll have to sit in the penalty box for a little while.

Your syntax is invalid. You have extra parentheses after $button_url and before 'target'. Try removing those.

In order to debug better, we would need to see what the original IPN type was, and where PayPal was sending it. When you make a payment, PayPal will respond to the callback URL at, e.g., domain.com/blesta/callback/gw/1/paypal_payments_standard/?client_id=12345, with a POST request. The same is expected of other IPNs. If Blesta received an IPN request from PayPal, even if Blesta doesn't take action on it, will still log that it was received. If it doesn't appear in the logs, then Blesta didn't receive it, so it may not have been sent to the correct URL. If Blesta receives a payment_status from PayPal that is not "approved" for a txn_id that already exists in Blesta, then the payments on the transaction would be unapplied.

Check the documentation for the merchant gateway you're using to see if it supports ACH or just CC. It probably doesn't support ACH.

Did you update the .htaccess to force SSL over HTTPS? Do you have any 302 temporariy redirects setup?

So, the customer made a payment and a transaction was created in Blesta, closing the invoice as paid. Then, Does this mean the payment was refunded, or that the subscription was canceled? I'm not sure exactly what action occurred here. A subscription cancellation can occur at any time, but previous payments wouldn't be refunded by PayPal. The gateway doesn't implement all IPN actions. Most are irrelevant as Blesta wouldn't perform any action anyway. What response did you receive from PayPal, as shown in Blesta's gateway logs?

As I mentioned above, the framework core generates the stack trace. This is evaluated before any code for the application (i.e. Blesta) gets executed, and often as a result of the application throwing an exception or a misconfiguration raising an error. Setting a configuration value in the core for whether to display errors to admins would require the core to be dependent on the application when the application is dependent on the core. This is a circular dependency design anti-pattern that wouldn't make sense to introduce. If you're concerned about some users seeing a stack trace, then I would recommend disabling them as I described above. If you happen upon such an error, check the php error logs for more information.

What is your expectation? A blank white page? The setting refers to the directory name within /app/views/ that contains the error templates. It's currently using /app/views/errors/*. Any documentation would be apart of the framework's documentation for minPHP. I'm not sure where Cody has placed that or if it is available.

The stack trace comes from the framework. Change /app/config/core.php Configure::set("System.debug", true); to Configure::set("System.debug", false); to remove the stack trace. The error page ("Something went wrong") will still be displayed, and is configured with Configure::set("System.error_view", "errors");

You could do something like that for your installation. I imagine you could update /app/client_controller.php to add the same logic as /app/controllers/client_accounts.php for determining autodebit and displaying a message.

"Blesta is built from the ground up to meet the billing needs of small and medium-sized businesses, like ourselves, by automating every-day actions so that we can focus more on expanding our business to meet the needs and expectations of our customers." - Tyson Phillips, Phillips Data, Inc.

For a custom report, you'll need to calculate the cost estimate of every service in the SELECT clause for a column in your query. Below is pseudo-code for the algorithm to calculate annual cost for a service. You can implement it as SQL in your query. // Annual income is price * period / term in days annual_service_income := (service_price) * ( if service_period is 'day' return 365.24 elseif service_period is 'week' return 52 elseif service_period is 'month' return 12 else return 1 ) / (service_term)

Custom emails are not intended to support modules. plugin_dir is the relative path to the plugin from Blesta's plugin directory. Since modules are not defined within that context, the email group would not be loaded, such as the language, as you've noticed. It may not be possible to receive BCC notices to the email either. It may be better to either create a plugin to handle emails instead, or update the module to send a custom email without saving it as an email template.

That would be possible. There would have to be an option to assign the service as an addon to another service. It would be possible for you to update the database to perform this action manually if you wanted to, but you should know that the addon service should never be a parent to another addon service (i.e. no nesting addon services).

We could use more information as described in How to Report a Bug. I'm not sure where you're deleting an event (URL). If you're referring to the events on the calendar, then I'm not able to duplicate the issue as adding/editing/deleting events is working correctly without any JS errors.