Tyson

To force Blesta's Multicraft module to always use the port 25565, you can follow these instructions: Make a backup of /components/modules/multicraft/lib/multicraft_service.php Open /components/modules/multicraft/lib/multicraft_service.php Find (toward the bottom of the file): $data = array('name' => "", 'port' => "", 'base' => "", 'players' => $players); Change to: $data = array('name' => "", 'port' => "25565", 'base' => "", 'players' => $players); Save the file, overriding the current file at /components/modules/multicraft/lib/multicraft_service.php That should take care of it. Do note: - that the module will always try to use port 25565 when creating a server. If you try to create multiple Multicraft servers on the same IP, it will try to use port 25565 for all of them, which may cause unexpected results. - that updating Blesta in the future will overwrite this file, so you will need to maintain this file change yourself

Are there any spaces before/after the email address you entered? e.g. "me@gmail.com "

In addition to what Licensecart mentioned: There isn't currently a method to set a default value for a package option. However, if you'd like to use the drop-down type, you can update that package option to use the Drop-down type, and change the value name to "Yes". You can add another option with the name "No", and a value of "0". Because "Yes" is the first option, it will appear at the top of the drop-down list, and it will be selected by default. Blesta doesn't assign a default port. Rather, it lets Multicraft determine the port to use. Someone brought up this issue before, where the port is incremented even when assigned a different IP address. I'm not sure why Multicraft works in that manner, however, it appears the WHMCS Multicraft module (written by Multicraft themselves) sets the port to use rather than relying on Multicraft to determine it. The other person that mentioned this to me decided to always use 25565 by updating our module to always set that port for new servers. That's certainly not the best solution, though. The admin menu is cached. You can force a cache update by re-saving your staff group permissions. i.e., from [settings] -> [system] -> [staff] -> [staff Groups] -> (edit), edit the staff group you're assigned to, and simply click the "Edit Group" button to re-save the settings.

The invoice should have been re-opened if it had any amount unapplied from it. It looks like the invoice still has a Date Closed, which it should no longer have. If you're familiar with SQL and updating databases, you can simply change the `invoices`.`date_closed` value to NULL for that invoice. How did you go about unapplying the transaction from the invoice? Can you duplicate this problem, and if so, can you provide the steps you followed to do so? i.e. how much the invoice was for, how you applied the payment to the invoice, then how you unapplied the amount.

Most of the email templates don't include attachments, so you're correct that the "Include any attachments" checkbox would have no noticable effect for those email templates. However, the setting is available if any templates are added attachments in the future, or if plugins send any themselves. The task, CORE-1274, adds tags that can be used in the Ticket Updated email template to provide a way for you to determine whether the ticket, or the current ticket reply, has any attachments. "Attachments" refers to attachments to the ticket, not to the email. The support email does not include attachments because they may contain sensitive information.

If you think this is a bug, we would need to know steps to duplicate it. Otherwise, it's possible that the currency could not be removed because: An invoice exists in that currency A package (or package option) is configured for pricing in that currency A coupon is configured for that currency

Since you have a log entry for the listpkgs action, the issue wouldn't be related to a missing permission for it. cPanel is not returning any packages when asked for them. Did you create any new packages? Are they configured correctly? I would create a new package in cPanel and then check whether it is being fetched in Blesta.

Are you using Record Payment to pay these invoices? If so, you can set the date the payment was received.

Blesta lists transactions in the interface by themselves, without invoice/service information. If a client wants to see what that transaction applied to, they click on it and another request is made that will determine to what invoices it applied the transaction, if any. Determining the service would be another step, but Blesta doesn't go any further to show that information. I think the best work-around is to write a custom query that will fetch exactly what you want. You can create a plugin for Blesta that provides a method that fetches exactly the information you want, then you can call that method over the API.

Your plan to build a table of transactions with service information is a little opposite of how Blesta fetches data internally. So you would need to fetch and derive that data using other methods. You could do something like this: for Transactions::getList as transaction: // Store services transaction->services := array() // Determine what invoices the transaction was applied to applied := Transactions::getApplied(transaction->id) // Fetch each invoice the transaction applied to and determine if it has services for applied as apply: invoice := Invoices::get(apply->invoice_id) for invoice->line_items as line: if line->service_id: transaction->services[] := Services::get(line->service_id) endif endfor endfor endfor Of course three for-loops will be pretty slow, so you may want to simplify what you're trying to do or determine another way to go about it.

I don't believe the importer will convert knowledge base articles into Blesta. And I don't think there is an automated way to do it otherwise. Can the articles not be moved manually (assuming you have the WHMCS install to copy from)? I imagine manual edits to each article would be necessary anyway.

Have you looked at the Shared Login plugin? If you're looking at authenticating a user between Blesta and another system, you can use that plugin.

Service quantity defaults to 1 currently, as the OP mentioned. But package option quantity can be different. You can define a package option (under [Packages] -> [Options]) of the "Quantity" type, which will then make the quantity variable. So we wouldn't be able to simply remove all references to quantity. But I can see that it may be redundant or unnecessary to show the quantity as 1 for everything. Perhaps it would be useful to have a setting that allows you to set whether to show the quantity if it is 1 or not.

The specific task that failed would not say that it had completed, which is how you would know that it did not end. Each task begins and ends with a log message (e.g. "Attempting to..." and "...task has completed"). The cron is setup for tasks to be grouped into their respective company or system tasks. The group also begins and ends with a log message (e.g. "Attempting to run all system tasks" and "All system tasks have been completed.") because it can be useful to know if the group has run, whether or not any of the tasks in that group had run too. e.g. Attempting to run all tasks for XXXXX Attempting to apply credits to open invoices. There are no invoices to which credits may be applied. The apply credits task has completed. Attempting to deliver invoices scheduled for delivery. No invoices are scheduled to be delivered. The deliver invoices task has completed. Attempting to provision paid pending services. The paid pending services task has completed. Attempting to unsuspend paid suspended services. The unsuspend services task has completed. Attempting to process renewing services. The process renewing services task has completed. Attempting plugin cron for order accept_paid_orders. Finished plugin cron for order accept_paid_orders. All tasks have been completed. Attempting to run all system tasks. All system tasks have been completed.

Each cron task that runs also logs that it has started and that it has ended, regardless of whether the task outputs anything else about what it did. The system message: "All system tasks have been completed" simply indicates that all of the system tasks that were scheduled to be run have been run. If any of those system tasks were unsuccessful, or produced an error, you should check the log for those particular cron tasks to see why.

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.

I was getting an error when attempting to load the Module Options on the add/edit package page. It looks like a simple issue caused by the module declaring the wrong key name, which is used to reference the primary module row field. The module uses the primary meta field "hostname", but says its primary field is "server_name". Changing that should fix it. i.e. Update: public function moduleRowMetaKey() { return "server_name"; } to: public function moduleRowMetaKey() { return "hostname"; }

Is the code on github still up-to-date? I haven't had a chance to look at it yet, but might be able to see what's going on this weekend.

Gray is the normal highlighting for every other row in tables. So first row is white, second is gray, third is white, fourth gray, etc. So really, the only color that means anything is blue, as Licensecart mentioned.

Good to hear you were able to isolate it to the custom changes by Rodrigo from another thread. Since this problem is related to the custom changes you made, I'll close this thread as not a bug with Blesta.

It would be great to have some more information, as described in How to Report a Bug. Is it possible that your Invoice Delivery (Unpaid) email template (under [settings] -> [Emails]) has the option "Include Any Attachments" unchecked? If so, that would prevent invoice PDFs from being attached and sent with the email. The setting to allow clients to change their invoice delivery method could affect this. That setting determines how new invoices are delivered by default. If it is set to "Paper", for instance, it is expected that you would print out the invoice and mail it to them. Invoice (reminder/late) Notices don't include any attachments with the email, but you can set links in the email for them to view/pay the invoice. If you go to the client's profile page, you can check a box next to one of their invoices, and email it to yourself. Then you should receive the same Invoice Delivery email that the system would have sent them before. You can use that to verify that an invoice is attached to the email.

What behavior would you like to see in that case? Domain availability can be checked without the need for a domain module, so if someone visits the order form, I imagine they should still be able to check whether a domain is available. But perhaps you wouldn't want to show pricing options in that case?

As I mentioned in the other thread, I wasn't able to duplicate this behavior. Did you make any customizations to the site, .htaccess, routing, etc.?

Blesta comes from the root word "blest" (blessed), from the Latin word "benedicere", meaning to praise. In later Old English it meant to make happy. And we want to make everyone that uses the software happy by providing them with a useful and stable billing application to make running their business easier. Hah! I'm kidding about that--while partially true, that's not why it's named Blesta. Had you going for a second.

How are you activating the servers manually? By creating them in Multicraft? If so, the two problems may be related. You should manually provision the service from within Blesta instead. Did you setup a cron job to run Blesta's automation tasks? When a customer pays an invoice for a service, that pending service is made active when the cron runs. You should check the following: You have setup a cron job for Blesta The Automation task for "Paid Pending Services" is enabled, and runs at a frequent interval. See [settings] -> [Automation]. If you bought the Multicraft service from an order form, check whether your order form has the option checked for "Require Manual Review and Approval of All Orders". If that option is checked, then you will need to manually approve the order first. To do this, go to [billing] -> [Overview]. On that page should be a Orders widget. Check the box next to the order you want to approve (i.e. the multicraft order), and Approve it by clicking the button below the list. By approving the order, you make it available for activation. The Multicraft module will automatically create a user account for each client, and then assign the server they ordered to their account. Any subsequent servers will be added to the same account.