Paul

Assigning a class to the outer div, and setting it to display: none; would be preferable. Still a change that would have to be re-added when upgrading.

Just FYI to the OP, this has been implemented and is available at https://account.blesta.com/client/plugin/license_verify

I don't have an example for you, but if you hide this and someone tries to sign up using the same username for an account that already exists they will be unable to register and either have to select a different email address, or login. We have some customers who have multiple accounts for legitimate reasons, so we wouldn't want to restrict this. A feature request has been made for a setting to force email address as username, so it's something we're considering implementing system wide. The approach I would take is assign a class to the div for the form element, and in CSS set it to display: none;

REQUEST_URI being undefined is troubling, I'm not sure what would cause that. What I would suggest as a test, is try running your cron via wget, GET, or lynx instead. See the example at https://docs.blesta.com/display/user/Installing+Blesta#InstallingBlesta-4.SetupaCronJob "Running the cron via the web". Curious if that resolves it. Might then be an issue with your CLI.

You could hide the option with something in CSS like "display: none;"

Very useful, nice work! Does it work on the order forms? I noticed it works on the portal, if it works on the order forms also, would be very useful.. maybe a screenshot of that would be more effective. I can see people using this for discounts on holidays, and the order form would be a perfect place for it to appear. Can't wait to see how this looks in Blesta v4 and the new UI.

You should check the task, it's not likely we'll post here when its resolved. We're working to get it in beta 5, so i'd suggest checking back once we release beta 5 to see if it's in there.

That probably explains it, hang on and watch the task status.

That's what I'm thinking, why I asked for the version.

We don't use 30 days for monthly, it's calculated as (date +1 month) for monthly. The term and period as configured on the package is always used. (day, week, month, year). Typically a service added on the 1st of the month will renew on the 1st of every month, but it's possible depending on the time it was added that the invoice could be due on the last day of the current month.

Yeah, it doesn't share any of the same code. I appreciate what you sent though, we just wanted to do it different enough that it made sense to start from scratch. Thanks!

What version of Blesta? If you disabled the shared login plugin, does it make any difference?

You can now check to see if a hostname is using a valid license for Blesta at https://account.blesta.com/client/plugin/license_verify/ Over the past several months, we've found a number of Blesta installations that were nulled in production. If you suspect a company is using a nulled or invalid copy of Blesta, you can use this utility to find out. If you find someone in violation, feel free to reach out to them directly to try to resolve the issue. Or, submit a ticket to us and we'll investigate and reach out to them. When people pay for Blesta it helps support development. Tip! Follow the Tips on the page Also, feel free to comment below if you have any suggestions.

Identifying the service and applying the transaction to an open invoice linked to that service is a good idea. It's also possible that we could look for open invoices that are for the same amount of the transaction, but this would be less reliable. Does PayPal allow for this kind of meta data to be set up with the subscription?

Yes, this is the case with all modules that implement a suspend and cancel option, and I assume this one does as well. (You need to install the Auto Cancel plugin to cancel suspended services automatically though https://docs.blesta.com/display/user/Auto+Cancel) Probably not, at least not without removing it from everyone by modifying the module. We are planning to allow certain management options that modules implement be permissions based on the Package level in the future though.

Just a note.. to automatically cancel services, use the Auto Cancel plugin that ships with Blesta. Here are the docs for it - https://docs.blesta.com/display/user/Auto+Cancel

I tested this on our v4 beta 4 install and can't reproduce. Invoices are generated, and emailed out and marked as emailed, not to be sent again. Trying a different mail delivery method as I suggested may be worth a try.

It's possible the invoice won't be marked as sent if Blesta thinks the email failed to send. How are you set to send email, PHP Mail, or SMTP? I suggest trying the other method to see if it continues. You may also enable error reporting, and run the cron manually (after stopping it temporarily from running automatically) under Settings > System > Automation, and see if there are any errors output for invoice delivery.

Re #2, it's irrelevant with Authorize.net. Since Blesta initiates the charge, Blesta is paying a specific invoice. The only way to have an Authorize.net payment that is not applied to a specific invoice is to manually process it under Make Payment, without specifying an invoice.

You could, but honestly most people will want to keep it on. You can always unapply payments to edit an invoice, and then re-apply after you edit the invoice. In the other thread, you wanted to re-send an invoice. You can manually resend without editing it. Merchant gateways charge specific invoices, so had that been an Authorize.net charge, you would not have had that issue.

Mass Mailer is in v4, currently in beta. I responded to your other thread with more details.

It's in Blesta 4.0, which is currently in beta. When you upgrade to v4, go to Settings > Company > Plugins, and click to install "Mass Mailer". It will create a new Mass Mailer link under Tools.

Since voids and refunds are a status change of an existing transaction it's not handled that way. If they were recorded as new negative transactions, then it would be possible to report it in that way. This is one reason Blesta does not currently support partial refunds. Something we might change in the future.

Those transactions were made 2 days ago, so would not be reflected in revenue today regardless of their status. If the transaction was today, and then voided today also, I'd expect it to appear and disappear from the total after it was voided.

Settings > Company > Billing / Payment: "Automatically Apply Loose Credits" must be checked. Also check client groups to ensure the same setting is enabled or settings are inherited from the company. Cron must be running. They are posted as credits for recurring invoices because PayPal doesn't know what the new invoice # is each month, so it can't be applied directly to the new invoice.