Austin

Send in a ticket, they'll be able to get you more information on that

I do agree on the domain front, however I think there are bigger features that take some precedence. One being a mass mailing feature, which is just down the road and affiliates which again is something coming in the next few versions. You should also remember, Blesta only has a few developers and therefore things take longer than said competitor which has a whole team behind it. Additionally Blesta has proven to be more stable and an all around great product and I regret nothing in choosing it as my billing software of choice. Not to mention there is a pretty extensible API to Blesta so you could look into adding the needed requirements for the domain module yourself.

One thing I notice is if you have multiple IP's available for clients to purchase as a dedicated, the "main" IP is pooled along side these other IP's. This results in that IP being marked as in use when in theory it should pull from the other available IP's. So my suggestion would be to add some sort of "master" IP that is not marked as in use so it allows the module to process orders not adding a dedicated IP without issue, I only suggest this as it appears to create a lot of confusion between clients since they purchase a dedicated IP, however it uses the wrong one and appends an unwanted port to the service.

They are able to do the bare minimum through Blesta, such as chat, start, stop etc. Things such as FTP still need to be done via Multicraft which clients will still be able to log into. Hope that answers your question.

Sorry for the delayed response, but I'm using the latest version. It is a very odd issue because I've done similar coupons in the past with no issue.

Here are the settings: http://puu.sh/hF0c5/7229e7621d.png The service wasn't updated in any way, nor was it upgraded. It was first created in April with the coupon applied, which is fine, then it recently invoiced the service again with the coupon still applied. Additionally if this is any help, it has not been paid for only invoiced. This was renewed via cron just recently. ** It's also occurred on another service renewing soon as well, I would assume any other service using this is code will fall under the same circumstance.

Hi, A few services have had a one-time coupon applied to them when they signed up, however it applied it for the following term as well. I'm not sure on the cause since it is setup correctly to only allow when a service is added. Could this be a possible bug, and if you need logs of some form I'd be happy to provide them.

I'm not currently using it, but I hope it's an improvement over Windows 8 because it drives me nuts.

A manual invoice contains the correct link. I'm using Interworx, so what needs to be modified in the cron job to correct the issue?

Having a slight issue with invoice emails sending out the incorrect link for customers to use the "Pay now" link. I've look at previous topics and the root directory is set correctly, but no luck. It sends them to domain.com/client however the actual installation is located at domain.com/clients Any ideas?

Interesting, that folder was missing. All fixed now, thank you!

Awesome to hear, looking forward to it!

I'm not currently aware of any ability to purchase a configurable addon after a service has been created, and you need to manually provision it. I think this would be a helpful addition to Blesta if this was a possibility. Thoughts?

Hi, I have run into an issue regarding file uploads through the support manager. The directory that is should upload to is writeable, but anytime a client or myself try to upload an attachment the error "The file could not be written" is returned. Any ideas on the cause?

I'd like to also confirm this issue is happening on my instance of Blesta as well. If you need additional logs I'd be happy to provide them.

I think I solved the issue, I did have two master servers setup in Blesta. Issue resolved/avoided, thanks Paul!

Nope, I have the interface running completely separate from where any Minecraft instances are running. Currently have 2 daemons, and just encountered this issue on a recent order.

Enhancement idea: A better way to manage servers, something along the lines of how the Interworx module handles things. Currently, if a server is at capacity I can set it to load any new order onto another via the daemon id, which is fine. However when a package is created it will use the IP of the server set for that package. Therefore I have to change the server every time one becomes full, simply to have new order emails reflect the correct information. This is slightly annoying and could cause issues if large volumes of orders are being placed, as customers would be being put on the correct node but the IP set for the server would reflect the incorrect one. If I'm overlooking something please correct me!

Much like the auto suspend after X days feature, a global terminate service after X days would also be a nice addition. This way it's not a manual process, especially if there are many that need terminating. Just a thought

It's CORE-605 and planned for 3.5, as of right now

Will definitely be trying this out later!

+1

It does change the status to refunded through PayPal, I figured I'd bring this up should anyone else be having issues too.

Don't mean to bring up an old topic, however I am currently having this issue. I tried to change the status to refunded, and I got an error multiple times, eventually having to do it through PayPal manually. Here is the code I got in the logs: https://api-3t.paypal.com/nvp a:6:{s:9:"TIMESTAMP";s:20:"2014-12-09T01:30:13Z";s:13:"CORRELATIONID";s:13:"4fd928ae2fc45";s:3:"ACK";s:7:"Failure";s:12:"L_ERRORCODE0";s:5:"10001";s:15:"L_SHORTMESSAGE0";s:14:"Internal Error";s:14:"L_LONGMESSAGE0";s:26:"Timeout processing request";} When I had refunded through Blesta, it only took a few seconds before I got an error and PayPal was not having issues at the time.

Welcome to the forums