Tyson

One person that had the OP's problem experienced it because they had multiple cron jobs setup that they forgot about after they moved Blesta to another server. I see no other explanation for this behavior other than mistakingly running multiple cron jobs.

Interesting. I don't experience this on v3.4.3; just the beta for 3.5.

Thanks for the update. What version of Blesta are you using? CORE-1688

Blesta doesn't know what your costs are, rather only the pricing you are selling services for, so I'm unsure how you would expect the system to determine profit. We've had revenue forecasts in the past, but it was met with overwhelmingly negative criticism, and therefore wasn't included in v3. I think most found it to be too "inaccurate". I wouldn't mind having revenue forecasts in the future, but I think better support for determining revenue would be necessary first, e.g. CORE-1479.

Client controllers require login. How are you accessing the method?

So you would be alright with showing the price, from any period, as per month, even if it were based on a day/week period? Then let's generalize it further and say that any price, from any period, can be shown per any period? e.g. Package: 3 months @ $100.00 $1.11/day $7.78/wk $33.33/mo $400.00/yr The settings necessary to display this info would still need to be determined.

If we were going to add this, we would very likely use the countries list from Blesta rather than the OP's list. Would that suffice?

What if the package only supports daily/weekly terms?

I'm not sure exactly what you're trying to accomplish. Only the blesta config file should contain the csrf token setting. It sounds like you want to remove it for the order plugin, which might be "config::preconfig".

If I'm understanding this right, I could order a service, not pay to renew it, then get it for free until it's canceled, and the associated invoice would be automatically voided. I suppose this depends on how you manage invoicing, but I imagine some would like to keep the invoice open to recoup the cost of services rendered.

If you're using SolusVM, make sure SolusVM is running v1.16.10 or greater. The module makes use of functionality introduced in that version.

Modules don't typically create tables. A plugin would be better suited for that. The Universal Module makes use of the existing schema to add products as module rows. If you're trying to mimic its behavior, you should check out how the Universal Module formats package and service fields from a product into module row meta data.

Why not?

What does your module's install() method return? Those fields are set as the meta data.

We recommend using separate Blesta installations for testing and production if you want to run tests on the system. There is no way to differentiate what invoice/payment is a test and what is real other than the fact you know you were testing it when you performed the action.

Are the service option fields hidden? If not, then I suspect your module is not including them similar to the Universal Module.

I think that is one of the issues that will be resolved when the definitions for v3.5 are added to the translator upon its release. Some expected data is missing which accounts for that error.

We haven't forgotten about the mass mailer, domain manager, or refactoring coupons. I'm frustrated these aren't done yet either, but if they were, then other features would be missing instead. In all likelyhood the mass mailer will be the next major new feature after v3.5, but we still have more tasks to prioritize to determine what the next version will contain.

GoGetSSL brought this issue up with us as well. Our module retrieves all products from their API using the API script they provide in their documentation, so I'm not sure yet what the reason is behind not being able to view all products. You should go to edit the package so that products load. This will make an API call, and the raw input/output will be logged and shown at the top of the list under [Tools] -> [Logs]. Click on the table row for that entry, and a list of the Input/Output data will be available. Look for something that starts with "<api-username>|ssl-products".

It's difficult to diagnose where the problem lies in order to develop a solution, as it appears to be intermittent, and we have yet to duplicate it ourselves. We're still looking into it, but as soon as we can isolate the problem we can patch it.

You can handle that through Module::getPackageFields. Use jquery to make an AJAX request to refetch module options when the selected server changes, then make your remote API request, and update the module fields returned by that method to contain the updated details. Other modules do this as well, so you could take a look at SolusVM or VPS.net as an example.

Do you have the GD library available to PHP?

The meta data is added during a POST request from the manage page of the module. You would need to check the POST data being submitted from that page.

Can you provide the meta data you are using (which is being inserted as duplicate)? What is the value of each `key`? It sounds like you may be adding multiple meta records for the module, and some may have the same key, which causes a duplicate key entry error. Both the `module_id` and the `key` make up the primary key, so each `key` must be unique for the same module.

You should also check the Module Logs under [Tools] to see if cPanel generated a more specific error from that action.