Tyson

You would need to add them manually into Blesta. When adding a service in Blesta using the Interworx module, make sure that "Provision using the Interworx module" is not checked. This will add it only into Blesta, locally, and not attempt to add it into Interworx, which is probably why you're receiving that error. If any of these services are resellers, then the service needs a "reseller_id" service field set. However, it is currently not possible to add that reseller ID through the interface until CORE-1384 is completed. You would need to update the database to add it in manually. That's correct.

I'm not sure what you mean. Can you provide an example? Module::arrayToModuleFields($arr, $fields, $vars) - first parameter, $arr, accepts an index, "attributes", representing an array of additional attributes. You can set additional attributes here, like 'placeholder'. e.g. $arr['field']['attributes']['placeholder'] = "My Placeholder". Whether a field option is selected is determined by the values set in $vars, where the keys in $vars match the keys in $arr.

vQmod is useful for making custom changes to software without actually making changes to it. Blesta doesn't use vQmod, but the use of any third-party code, whether it be via vQmod, modules, plugins, etc., may contain code that disrupt's Blesta's security, as you put it. Blesta has been around since 2007, but v3.0.0 has only been around since last year, which is what most people seem to be referring to. I like keeping it simple and straight-forward. There will always be feature requests here, but that doesn't necessarily mean they will be added into the core of Blesta. Some of them have been supported in 3rd-party plugins already, or are better suited toward a plugin. I wouldn't worry too much about Blesta becoming bloatware--it won't.

I think most of us are in agreement that it is more convenient to have only the possibility of 1 pro forma number found, like your example, when checking logs for that particular pro forma invoice number. We will likely explore a different solution than yours, however, since yours adds two fields to every invoice when only 1 invoice would contain valid information. For now, pro forma numbers will continue to be generated like beta 1.

The OP's approach is more or less what we're already working toward. This is the reason we have extensions. For instance, the Order plugin is not apart of the core, although we currently ship it with Blesta by default. Likewise, gateways and modules are not apart of the core either. However, there is still going to be a need for core features to some degree. Currently, there are several still pending, such as the ability to merge clients. Many other features, like a mass mailer, are better suited as plugins. We still need to expand on the event system in Blesta to allow for extensions to perform more actions. There's always going to be some users that need custom feature X, or want feature Y to be changed slightly to work better for their business. But we don't intend to add or change core features that only 1% of users will use. Plugins are better suited in those cases. In the future, you will probably see a decrease in core features, and an increase in extensions.

You can edit a client via Clients::edit, but most information related to a client (e.g. first name, email, address, etc.) belongs to the primary contact. Each client has a contact (i.e. contact type is 'primary'), but it's also possible to add additional contacts under each client.

I'm not sure why you receive an SQL error, but I see the values you're setting for Clients::edit aren't supported by that API call. Sounds like you want Contacts::edit.

Welcome to Blesta!

CORE-1418 has been added for beta 2. Perhaps an exception should be made for services from a package that is set to cancel at the end of its term. That might make a good feature request.

In that case, you would need to disable the setting for clients to cancel services. If a client has cancel options available, they can cancel a service, schedule it to be cancelled, or uncancel it if, for instance, they made a mistake in scheduling it to be cancelled in the first place. I'm going to move this to Suggestions.

I find it a little funny you created a thread about pro forma invoices not being sequential and now suggest using random (non-sequential) pro forma numbers. The invoice numbers will have to be sequential. Currently, they meet that requirement, but it just may be difficult for users to find and reference some particular pro forma invoices over time. I think the best solution will have to simply be to not reuse them.

I've added CORE-1418 for this, which is an improvement to disallow clients from changing the term, or package, when the service is scheduled for cancellation.

CORE-1370, as described above, is now complete. As is CORE-1389, so I'm going to close this thread.

The use of "getRules" on the Error Checking page is simply to aid the example of how you might define a custom callback method in a validation rule. How you decide to use the rules to validate input is not covered in the example since it would be superfluous. As flangefrog mentioned, you would fetch the defined rules when setting them to the Input component. Setting rules to an array wouldn't be considered harmful. As a developer, it is up to you how best to manage your rules for validation, such as by merging your custom rules with rules that already exist if you choose not to directly update the array of rules shown in the example. As for the Universal Module, it supports a JSON-encoded object of input rules, but cannot specify custom callbacks unless you update the module itself to support such an action.

I don't see a need for all controllers and controller methods to be fetched in/by Blesta. You could improve that by using Loader::toCamelCase

If any tags existed related to users, they would need to be set conditionally in the template.

Looks like you already search for the files, so then you can find the class methods: $class = "className" $methods = get_class_methods($class);

I've never heard of anyone confusing a Tax ID with a SSN, but I suppose anything's possible. Just another reason to have optional field support for you to set what you require.

naja7host's method would fetch the total amount due (past due or not). You would need to calculate the total past due via Invoices::getAll if that's all you wanted

I'm not that familiar with the Plesk plan configurations, but it does sound like a pain if you need to manually reconfigure the plesk IDs to match everything up. If that's the case, then perhaps grouping the servers should not be supported by the module to avoid the case you describe here. But I'd like to hear other Plesk user opinions before moving forward with it.

The proforma number is sequential, with no duplicates. The associated invoice, however, when paid, is no longer a proforma invoice. Voided invoices are still proforma, and still sequential. Once a proforma invoice number has been paid, it becomes a normal invoice, and the proforma number is 'released', whereby it can be used again elsewhere (sequentially, like your example). Are you saying there is a requirement that proforma invoice numbers cannot be used if they were used before, even when the proforma number is still unique? If so, could you reference the source for that requirement?

Only services that are scheduled to be canceled are canceled automatically (at the time they're scheduled to cancel). It sounds like you would like a setting which will automatically cancel services that have been suspended for longer than a configured number of days. Moving to feature requests.

I think I better understand your description now. When configuring a Plesk package in Blesta, selecting to use a Server Group rather than a specific Server will load plans for one of the servers in the group--probably the first. It will not load plans from all servers in the group, then combine them into a single list. Doing so would require the module to determine the corresponding server from the plan later on, when services are created, updated, etc., since the correct server would be dependent on package settings specific to the module. I'm not sure supporting that behavior would be ideal. Selecting a specific Server rather than the group, or not grouping those servers together may be a better alternative. I'll move this to the feature request forum. CORE-1408 is unrelated to this issue.

This has been fixed in v3.3.0