Paul

These notifications are pretty cool and orders and tickets would be a good candidate for these. I could see this something that we implement as a sort of "beta" feature that you could enable if you want.

It's been re-issued.

We need the license key in order to re-issue. As Mike mentioned, emailing sales will work (Or you can PM me) if it's a trial. If it's a paid license you can re-issue it on your own in the client area.

We are considering that.

Do you have a ticket open? If so, what is the ticket #? After you had a failed import, did you restore your database back to a fresh install of Blesta before running the import again? The error about a duplicate entry could be a result of not doing so. The import can only be run once because it will try to import everything again. We recommend making a backup of your Blesta before attempting to do the import. If you didn't do that, you could empty your database and remove your /config/blesta.php config file (You should have a blesta-new.php file in there) and run the installer again. Then make a backup, and try the importer again. If it fails, you can restore your database backup. Any errors you get would be helpful, but it must be from a failed import on a fresh Blesta install.

The new look is a minor part of the major code update to 4.0 which increases the minimum requirements for Blesta and allows things like domain management to happen. When we began development for 4.0, we announced that 4.1 would be dedicated to domain management. The new whmcs is mostly a new look, and they borrowed a lot of ideas from us. I understand you want better domain support yesterday, but it's scheduled for 4.1. The most constructive way to proceed is to give us feedback on what features of domain management you value most.

Settings > Company > Billing/Payment > Invoice Customization. Add it to "Terms".

You technically can open a ticket at https://account.blesta.com (click support) or email support at our domain. The only thing is, as with other methods, since you don't have an account with us we cannot verify that your license belongs to you. This means we can't re-issue it, or change any information related to your license. You should contact the reseller for this anyway.

We are using some pieces of Bootstrap, including bootstrap buttons. However, replacing all of the markup in favor of bootstrap would take forever. There are many features that everyone would rather see instead. Our goal with v4 wasn't to redo the entire admin interface, but we figured we could improve on the UI quite a bit while we were at it.

The admin UI is not responsive, unfortunately -- that would be a major undertaking, but we're making steps toward that direction. It's the same fluid layout. The new graphs do scale automatically which is nice though, as the old jqplot ones had to be refreshed.

Here's a tiny peek at some of the UI changes in v4. What stands out to you?

Very good, thanks for the update!

You could modify the templates and make all the fields that are not required hidden. In the future, we will be allowing fields to be set to required or hidden via the UI (right now just the Tax ID can be disabled in settings) You still accept payment from them right? I imagine that would be the biggest hangup with kids, rather than supplying their name and address. Chances are, their parents would be helping them with the order. It's pretty much the same no matter what they buy online.

If this is just for configurable options, it makes sense for it to be a setting for the option. For example, in the "Basic" section at the top of Packages > Options > Create Option. [x] Allow Upgrades [x] Allow Downgrades The issue is that how do we know what is an upgrade or a downgrade? There are different types: - Checkbox (Should we assume that checking the box is an upgrade, and unchecking is a downgrade?) - Radio / Dropdown (Should we assume that items toward the top of the Options you set are upgrades or downgrades?) - Quantity (Should we assume a larger quantity is an upgrade, and a smaller quantity is a downgrade?)

I would definitely suggest they upgrade to 3.6.1 (the latest release), which includes a newer Multicraft module. (Version 1.3.0 of the Multicraft module)

We had a brief power outage and MySQL failed to start on Jira, fun. Domains are a good example of renewing for more than 1 cycle, however domains are also very unique in that they have many other restrictions. For example, you can't register a domain for more than 10 years. I wonder if this type of functionality should be delegated within domain management and kept separate from standard services. (When we add better support for domains) If a case can be made for renewing other services for more than a single cycle, perhaps the setting that allows clients to renew early can also allow a maximum number of cycles to be specified. There is nothing preventing someone from renewing in advance again (Unless that were also included as part of this) so there is no upper limit.

Have any changes been made to Blesta or the Multicraft module? What version of Blesta are you running, and what is the Multicraft version? This output looks as if someone was doing some debugging, not a typical response by Blesta.

See the screenshot in the task, it contains all of the options necessary for Staff, which is just, the # of cycles. For the client, I think advancing it a single cycle is sufficient. What other options are you thinking of?

In terms of what you recommend for the client side, this is almost identical to what the task describes in CORE-2058. From the admin side, an option under Actions would be fine unless we allow bulk-renewal as specified in the task.

Just an update on this. I've created CORE-2062 to force port 25565 when using a dedicated IP, since Multicraft doesn't default to that behavior (oddly enough).

Just an update, I've created CORE-2062 to address this within the module.

This was mentioned in http://www.blesta.com/forums/index.php?/topic/5527-multicraft-not-setting-dedicated-ips-properly/ In the following post, Tyson says what you can do to force 25565 as the port # for all servers: http://www.blesta.com/forums/index.php?/topic/4201-questions-regarding-multicraft-module/?p=31118 I wonder, if the module could be updated so that if it pulls an IP from the pool, that it specifies the port as 25565 rather than allowing Multicraft to select the port. That's really the issue here -- Multicraft is not using port 25565 for dedicated IPs by default, but perhaps we can force it.

Yes, it creates a problem though if as an admin you invoice for multiple cycles and a single invoice is created per-service as I suggested in the task. I wonder if we should create an individual invoice for each cycle or handle it differently.

Please see CORE-2058. This thread will serve as a point of discussion on this task.

Please see CORE-2057. This thread will serve as discussion on this task, if you have any comments, please let us know. There is additional planning required for this task prior to development.