Tyson

You can write a plugin that adds elements to the main navigation using the nav_primary_staff plugin action.

You could try to see if Max's Omnipay integration is suitable for GoCardless. You will need to be running php 5.3+

Which link/page are you visiting for the service when you say 'looking at it' causes the pending service to be made active? Are you familiar with browser developer tools? If so, you can check the network requests to see if an additional POST request is made unexpectedly, which might activate the service. But Blesta does not do this automatically when simplying viewing a service.

Thanks for listing the steps to duplicate. It should be noted that you also need to ensure you have your WHM account configured to require a password strength (e.g. 60) when attempting to duplicate this behavior. It looks like the API response from changing the account password is not in the same format as the other API responses that the module expects, so it was not handling that error. I've updated the module to handle that error for the next release. See CORE-1580. It's entirely up to the module to determine what an error is with respect to the API it makes use of, and to then let Blesta know what it is, if any. While cPanel generally displays friendly error messages, likely because the same message is shown in their account interfaces, error responses from the API can't always be parsed and sent to the view in Blesta. Some APIs don't return friendly messages (maybe just an error code #), or may contain sensitive information that should not be displayed in the public interface. The module should determine what the best error message response would be considering the information it has at hand and the fact that it will be displayed in the interface. This is why several extensions sometimes defer to generic error messages. The cPanel error message for this particular password request can be confusing: Sorry, the password you selected cannot be used because it is too weak and would be too easy to guess. Please select a password with strength rating of 60 or higher. The second sentence tells the user to select a password with a strength of 60+. What is 60 and how is it determined? The module doesn't know, the user won't know, and even I don't know what would pass that requirement. It might make more sense in cPanel because they display a password strength indicator while you type in your password, but that strength indicator is not available over the API. It would likely be better for the module to translate this message into something more useful/generic because of this, such as "The password you selected was rejected. Please enter a longer password containing numbers, letters, and symbols." But I'll leave that as a feature for another day.

As I mentioned, the cron will handle activating the service automatically based on whether the service has been paid. You could also activate it manually (whether paid or not) by managing the pending service and clicking the "Activate" button.

It would be great if you could include more information as described in How to Report a Bug. Steps to duplicate the issue would be most useful, describing how and where you changed the password, and preferably the password you used that led to the error. The module doesn't need to return the API response, and modules don't (usually) make calls to update the database directly. That is usually handled by the caller after evaluating any errors set. Please provide steps for us to duplicate the issue. From what I can tell the module does not update any fields (e.g. password) when there is a module error.

I responded to your tickets a few minutes ago.

Accepting an order means that you approve the order as valid so it can continue to the next step. The next step is to verify payment has been made. The cron takes care of that, and will activate the service once it has been paid.

Steps 1 and 2 are a little vague. I'm not sure where in the order process you are experiencing this and where the browser's back button takes you to in this case. If you'd like, you can send me a private message with more information. I'd like to have a better idea of what you're experiencing to duplicate that behavior.

I'm going to close this thread as a duplicate of an identical feature request.

I take it that creating the invoice (with no delivery option checked), and then delivering it manually from the client profile is not suitable to work around this case? If this feature were implemented, would checking the delivery option for Email then cause the email to be delivered immediately rather than queuing it for delivery? CORE-1561 exists to re-queue a paid proforma invoice to be sent via email if it was queued for email to begin with. If your feature were created to deliver the invoice immediately rather than queue it for delivery, then CORE-1561 would (likely) incur undesirable behavior where the manual creation of a proforma invoice would not later queue the invoice for delivery via email after it has been paid.

Cron tasks in Blesta are locked down already to disallow them to be run again when they are currently running. There is no need to write a temp file to perform this check. You may want to look into better implementations of semaphores for your other projects. The 5 minute interval only means that it will take at most 5 minutes for the action to take place (assuming the cron is running normally). You could change this to 1 minute, and then have your cron run every minute, but as you mentioned, that could bring up other issues.

Your example translates the gateway name into a credit card payment description for PayPal, which it is not designed to support. Gateway names aren't shown in other language translations throughout the system since they're proper names. I think this would be better as a feature request to allow for a separate, translatable, name/description to be used rather than the gateway name, or to store and use the language definition of the name instead.

I'm not sure what the issue is either. I would need to know more info about the problem to help you figure it out. But the way emails are sent, the client receives the email, and any of their contacts that have replied to the ticket are also CC'd.

I'm curious to know how you were able to reach that error. Did you go to the cart page directly, or did you navigate to that error page through the interface?

Nice catch. That's actually a separate issue I described in CORE-1574. It will also be fixed for the next version.

I blame myself. Failure to consider all special cases.

Well, you updated that quickly. It's not PHP's fault, though.

This problem has to do with how php calculates "+1 month" as 30 days, and since February only has 28 days in it, it calculates one month from Jan 30 and Jan 31 into March. So only January 30-31 would be affected by this issue. The fix for this will be included in the next version of Blesta as apart of CORE-1572. Being that today is January 30, you will likely want to fix this yourself in the meantime. To do so, update the file /app/models/packages.php Find this line: $today = $Date->cast($start_date, "j"); Below that line, add: $start_date = $Date->format("Y-m-01 H:i:sP", $start_date);

Certainly doesn't look right. I'll see if I can find out what is going on with that.

That's pretty good. You did all that with the CMS plugin? I see the Support Departments don't work yet, but I guess that's apart of the remaining 10%.

This bug will be fixed for the next version of Blesta as apart of CORE-1571. If you'd like to apply the fix yourself, then update /app/models/staff_groups.php Find: 'permission' => array() And replace it with: 'permission' => array(), 'session_lock' => $staff_group->session_lock

I noticed this as well. Haven't had a chance to debug it yet, but will shortly.

If you update Blesta, then yes, the change you made would be overridden. You would have to maintain the custom changes yourself. Alternatively, you could use vQmod to make the change instead, so it will persist. Also, I think you can use: $this->invoice->line_items[$i]->subtotal ..instead of calculating the subtotal yourself.

Try setting an override price and override currency each to null.