Tyson

Closing this thread as resolved in beta 2.

Multicraft is updated for beta 2 in CORE-1405 to auto-select a daemon if not specified, which will resolve this issue for you. Test it out once beta 2 is released. Closing this thread as resolved.

This has been improved in CORE-1394 to allow credits to be applied without a payment option if it covers the invoice total it's being applied to.

CORE-1396 has been added for beta 2. Instead of appearing under "Status", they'll be in their own section.

The todo refers to checking the input fields contained in $vars to ensure the fields required by the module are defined and valid for use when adding the service.

The logo changes I mentioned above work fine for me. Did you remember to update the .logo class?

No, there is no email that can be sent based on config option values. What are you trying to do? You could update the package welcome email with conditions to check if your config option is set, and add additional email content there, which will be sent to the customer on service creation.

I don't recall either, and no logs specifically mention it. But it looks like you initially removed it a few years ago along with the "reconciled" status, and even left the language definitions defined.

Not sure I fully understand the issue you're describing, but I noticed that plan validation is always checked against the server group rather than the server (followed by the server group if necessary). This may be a byproduct of that issue. CORE-1408

Thanks, but this has already been fixed for beta 2 in CORE-1392. I encourage you to check the dev tracker as mentioned in How to Report a Bug before opening a new bug thread, just to make sure the issue you have hasn't already been created.

This was both added then removed before v3.0.0 was released. Moving this to feature request.

Closing thread as not a bug.

Thanks - CORE-1407

You can create a feature request for it, but we currently have no plans to list config options without showing a label for them. I would think most people would want to describe the option in the label rather than only in the option name, unless it were only for checkboxes. If setting a label were optional, you could have some options with labels and others without, which may be confusing for clients, as they might see something like: Memory [DROP-DOWN] 1 GB ($0.00) [DROP-DOWN] 2 GB ($5.00) [CHECKBOX] Unlimited Player Slots ($0.00) [CHECKBOX] Buycraft Trial ($0.00) [CHECKBOX] Enjin Trial ($0.00) [CHECKBOX] Dedicated IP ($0.00) [RADIO] Los Angeles ($0.00) [RADIO] New York ($0.00) ...which is 6 separate config options

You can upgrade directly to v3.2.2 by downloading the full blesta-3.2.2.zip and following the upgrade instructions.

You need to setup multiple config options, and set a label for each one. Re-reading your OP, it sounds a little more like you want the values of multiple options listed, with only 1 label for "Multicraft Server Options", which is not possible--each config option needs its own label. So you can consider re-labeling your config options from: To Set Your Own Player Limit [CHECKBOX] Yes (£0.00) Start a Buycraft Trial [CHECKBOX] Yes (£0.00) Start an Enjin Trial [CHECKBOX] Yes (£0.00)

Sounds like you may have skimmed over my post. Config options can override some of the package fields you have set, but that's not relevant to your original post, which asked how to setup the config options under the same "Multicraft Server Options" heading, which you have set on the config option in your example. A config option describes only one field, like "Unlimited Slots" in your screenshot. You don't set "Unlimited Slots" and "Enjin Trial" on the same config option. Those are two separate config options.

I think you need to revise the way you label each config option. Each one refers to a single option, which may have multiple values, but you seem to expect it to describe multiple options with multiple values. When displayed on an order form, the config options are already placed under a heading for "Configuration" of the service, so the label you enter should describe the single config option itself. Consider an example of 3 config options: Label: "Server Memory" Name: "memory" Type: "Drop-down" Option 1 Name: 1 GB Option 1 Value: 1024 Option 1 Price: 0.00 Option 2 Name: 2 GB Option 2 Value: 2048 Option 2 Price: 5.00 Label: "Server Type" Name: "jarfile" Type: "Drop-down" Option 1 Name: Default Option 1 Value: default Option 1 Price: 0.00 Option 2 Name: Craftbukkit Option 2 Value: craftbukkit.jar Option 2 Price: 2.50 Label: "Set Your Own Player Limit" Name: "user_players" Type: "Checkbox" Option 1 Name: Yes Option 1 Value: 1 Option 1 Price: 10.00 Result will display something to the effect of: Server Memory [1 GB ($0.00)] [2 GB ($5.00)] Server Type [Default ($0.00)] [Craftbukkit ($2.50)] Set Your Own Player Limit [ ] Yes ($10.00)

The API isn't clear as to whether the daemon is optional or not. It appeared as if it was optional, since you are not required to set one for one to be set, however, as you've discovered, Multicraft defaults to always selecting daemon ID 1. But now that they've cleared up that misconception, we'll have it resolved for the next release.

I think it's best to not require a daemon to be entered at all. Daemon ID(s) can be set for config options already, which considers memory usage when choosing one. So in that case, you can specify which daemons to use. But for the problematic case that you don't specify a daemon--either you don't care to set any, or you only have one--then the module will choose one of the available daemons you have automatically based on memory usage. That will fix the issue you were having with daemon ID 1, and not require any additional configuration.

I spoke with the guys from Multicraft, and they tell me daemon ID 1 is the default value whether it actually exists or not. So one must be explicitly set instead. See CORE-1405. In the meantime, a daemon ID should be set as a configurable option for the package.

I meant @naja7host. Addons appear to work properly in php 5.5.12, which is probably why we didn't notice it earlier. In any case, fixed in CORE-1397.

What version of php are you running?

As LicenseCart already mentioned, a plugin already exists that will handle this for you. In Blesta, head over to [settings] -> [Company] -> [Plugins] -> [Available], and enable the "Client Documents" plugin. Then head over to a client's profile page. Under the "Actions" section in the left sidebar, click to "Show All Actions", and finally the "Documents" link, where you can upload a file for them.

Thanks for the info. I haven't looked over the recent changes yet, but since Plesk is backward compatible between versions, you shouldn't experience any issues with the functionality that it already supports.