Paul

Thanks, this is fixed for the next release. https://dev.blesta.com/browse/CORE-4494

Is your registration price set to 0 for the TLD?

The plugin is only intended to allow a client to unblock their own IP. If you like, you can submit a feature request at https://requests.blesta.com. We would consider adding a option to the plugin to allow an IP address to be entered that's different than the client's IP, but it would have to be a setting that is disabled by default. There is no simple and straight forward way I can think of to prevent abuse. Alternatively you can modify the plugin, but don't have details on how to accomplish what you're trying to do. It may be possible to just remove the disable element on the form, but I suspect there is probably more validation.

Are you trying to unblock an IP as a staff member or as a client? Allowing clients to unblock any IP address, even if it's not theirs could be a security risk.

If you are using the new Domain Manager in 5.1+, then Blesta will sync the renew date automatically within 24 hours of it being renewed with the registrar. Just don't forget to manually invoice in Blesta. In Blesta 5.2 there is an option to renew in advance, which would be the preferred way to go.

Are you using the Domain Manager? If so, edit the configurable option under Packages > Configurable Options and check the box labeled "Default" for the Enabled option. However, it looks like this may be separate from the domain manager, and the option may be generated by the module. If that's the case, it will require a code change. I don't have an example of that handy. Our Discord #developers channel is probably the best place for developer related help. Here's an invite https://discord.com/invite/XCq34pU

These fields are not required, they are only used if you want to do a refund from Blesta directly. Sandbox ID, Account, Secret doesn't appear to be the same information.

What version did you upgrade from and to? Version 5.0 no longer supports PHP's mail() function, it uses Sendmail instead. If your server doesn't support Sendmail, you may wish to configure SMTP. Settings > Company > Emails > Email Setup

Thanks! FYI, we created this task https://dev.blesta.com/browse/CORE-4440

Use IPv4 in what way? If their API doesn't support IPv6, then they shouldn't have an AAAA record on their DNS for the endpoint, and your server shouldn't try to connect over IPv6. If they do have an AAAA record, and your server has an IPv6 address, removing the IPv6 address should force IPv4.

You can submit a feature request. To do this now, a plugin that ties into the Invoices.add event to append a line item with the fee would be the best way to go about it.

You can always open a ticket, or PM me your license key and I can check. We did not offer the lifetime license prior to releasing v3.0, and it has never been less than $500. Some people confuse an owned license with a lifetime license, owned licenses will continue to work indefinitely even if you don't purchase support & updates - you just wouldn't be able to upgrade or get support.

Are you certain that your contact logs are rotated out based on your rotation policy (Under Settings > System > General)? Ours go back to 2013 when we started logging them, it shouldn't be part of the rotation policy. The original idea was to be able to see changes made to client/contact details forever, so you could see and possibly restore details from any point in history. Unless you're saying you do want them to rotate out, but after a longer period of time?

It's a good idea, thanks for the suggestion. Where do you suggest we put this? Also, should we include any actions (like to cancel the pending changes)?

If you can't check the option, it shouldn't appear when they order a domain. If you manually edit the package and add the configurable option group for ID Protection to the domain Package (to bypass the checkbox under TLD Pricings) then yes, it would appear, and if they check it they will be charged for it based on pricing you set.. but the module will not enable it automatically, you'd need to do so manually after they order. So if the goal is to charge them for the option, and set it up manually in the interim, then you would click to edit the pricing for the TLD under Packages > Domain Options, click on the Advanced Tab, click on the "Edit Package" button, and assign the configurable option group "ID Protection" to the Package and save. Don't forget to set pricing for each term under Packages > Configurable Options for ID Protection, if there is no pricing for the term then the option will not be available.

We are not ignoring anyone. 5.1 is the initial release of the domain manager, it improves domains significantly, and it's really just the start. I count 15 tasks for the domain manager that are already done for the next release, version 5.2. If you want to write Blesta off because it doesn't import all your TLDs in the initial release, that's up to you. That doesn't negate the fact that it's still a major step in the right direction. Our staff don't typically respond to forum posts over the weekend.

Do you mean the log shown under Tools > Logs? The "Contacts" log here is kept indefinitely and are not rotated out automatically like other logs. It is hard to find stuff here though, and we should definitely show changes for a specific client under Actions on their profile page. See https://dev.blesta.com/browse/CORE-2223 for the task, will this accomplish what you are looking for? Maybe we can bump it up.

Just to add, the pricing for these config options will be able to be set under Packages > Domain Options > Configuration in the next release - version 5.2 of Blesta.

If you are using the domain manager, the option can be enabled under the TLD Pricing page (Packages > Domain Options) for registrars that support it. Currently the pricing would be set under Packages > Configurable Options > Options > ID Protection: Edit (and set the prices for each term. The current schema is the same price for all TLDs, but you could clone this option with different pricing, put it in a different group, and manually assign it to the Package (Under TLD Pricing > Edit > Advanced > "Edit Package" button. Swapping out the official config option group with the one you created. As a note, most of the registrar modules do not yet support ID Protection. If you check the box and get this error then it doesn't support it yet. We'll be adding support for these extra options to official registrar modules soon. The id_protection feature is unsupported by the selected registrar module.

This depends whether you are creating your own module, or using the Universal Module. For the Universal module, we recommend creating any fields that will not cost extra (like username, password, etc) as a service field on the product. See https://docs.blesta.com/display/user/Universal+Module#UniversalModule-ServiceOptions for docs and an example. For any fields that should cost extra, those should be created as Configurable Options, under Packages > Configurable Options. If you are creating your own module, then you would code in the service fields. The Extension Generator plugin can help you get started with development, and I believe it lets you define these fields https://docs.blesta.com/display/user/Extension+Generator

How do you get away with not paying VAT tax on both the original invoice for the credit, and the invoice for the credit consumption? It looks like you're simply not charging VAT on the portion of the service invoice that was paid with prepaid credit, but this doesn't seem like a very elegant solution. An invoice paid by credit would essentially be tax exempt, or partially tax exempt. At the time an invoice is generated, it does not know how it will be paid. Is the tax on your invoices edited/adjusted when they are paid, based on how much prepaid credit is applied to them? This would violate regulations in many countries that do not allow invoices to be modified after they are created. Also, what if the VAT rate changes between the time the prepaid credit is made and the service invoice is raised? Say it's 18% when the credit is made, and 20% when the service invoice is created. If an invoice-like document must be sent when a prepaid credit is made, this seems more logical: When a credit is made, create a new type of invoice.. maybe it's called "credit invoice" or something, to distinguish it from a normal invoice. Do not charge any tax at the time the credit is issued. When credit is applied to a service invoice later, calculate the tax rate like normal an assess the tax then. This avoids the problem with duplicate amounts appearing in invoice reports, because a different type of invoice is generated for credits, it's not the same. It avoids the issue with the tax rate changing, because it's only assessed when it's applied to a real invoice. And, it avoids having to edit/change an invoice on the fly to account for taxes that were paid with the prepayment.

The license "Blesta Owned Lifetime" does not have a yearly fee for updates. It's a special license type, that we may limit future sales of, adjust pricing, or discontinue sales for at anytime without notice. Those that have it will not need to pay anything in the future.

I think Cloudflare was having trouble yesterday. I got an error for about an hour from home, even though the network and servers at the origin were fine.

Where can we find official government documentation on this? The problem is this: Let's say a client makes a $100 payment for credit. If we invoice for the credit, the amount would be applied to the invoice, and there would no longer be a credit. If on the other hand, the credit is both invoiced and remains as an account credit, then at a later time a client receives $100 worth of invoices and the credit is applied to those invoices, the initial $100 credit has been applied to $200 worth of invoices. Additionally, the client may be able to submit this to their tax authority as a $200 deduction. How do you reconcile that?

Prior to 5.1, modules didn't have types. A minor tweak is needed to make the module compatible with the domain manager, and we have provided the information to them. The module would continue to work outside the domain manager as it was, but the minor update to make it compatible is the best solution.