Leaderboard

Blesta version 4.0.0-b4 (BETA 4) is now available. You can download it from right here (Client Area Login Required). If you haven't seen the blog post announcement for 4.0.0 BETA 1, you can read it here. This is a BETA release. Beta releases are not considered stable enough for production use, and are UNSUPPORTED. DO NOT INSTALL IN A PRODUCTION ENVIRONMENT. Please report any bugs you find in the v4 beta bug forum. Installing Blesta See Installing Blesta in the User Manual for instructions. Upgrading Blesta See Upgrading Blesta in the User Manual for instructions. Release Notes See Blesta Core - Version 4.0.0-b1-b4. SEE BETA 4 ONLY For older releases see all Change Logs. What to Test! 1. PHP 7. The focus of this beta was largely PHP 7 support. Check change log for more. Known issues 1. An error is encountered when logging in or out with PHP 7, if errorReporting is enabled in /config/blesta.php

Nevermind, i managed to solve it...

New version available. Type: revision. - Fixed js menu conflig in blesta 4

I'm not sure what needs to be done with the domain registrar modules but I see that Enom has new API information and I would guess other providers do as well: http://www.enom.com/domains/new-transfer-policy/

whoop

Looks like we have a lot more than that even, ha! This makes me wonder if there was a reason that cancelled or fraud orders do not have their "In Review" services deleted. My best guess is that there might be a need, on occasion, to figure out what the customer ordered and add it back. We've had to do this to fraud orders in the past, that ended up not being fraud. So, rather than deleting them immediately, I wonder if they should be part of a new setting that cleans up unpaid, cancelled, or fraudulent orders such that after X days, those "In-Review" services would be deleted. Thoughts?

Did you already disable Credit Card and ACH under Settings > Company > Billing/Payment > Accepted Payment Types? This should prevent them from being able to create a Payment Account at all, but it won't remove the nav link. Good to do this also if you haven't already, in case anyone stumbles on the URL.

In v4 there is an option under Packages > Order Forms > Settings tab for "Default Order Form" called "None - Show Listing". If this is selected, all order forms with Visibility set to "Public" will be listed here. The Visibility setting is a new option in v4 as well, and allows Public, Shared, and Client Only. Shared is via shared link, Client Only is for authenticated clients only. You may find this useful!

Changing the module for a package would break services that were already issued based on the package. Those services would not have the same meta data as those created after the module change because that meta data is defined by the module. Being able to safely change the module would require making some changes to the way that data is handled to de-couple services further from the package. Until this is done, the safer scenario is to prevent the module from being changed.

Yeah you can delete it, not sure what the review bit is to be fair.

Hi Cam, You are correct you'd just add another button in your blesta portal. That's how we add different order forms to the portal, or anything else to the portal for that matter. Daniel.

Tax Support is coming ... probably we will do a pro version that has some more feature than the normal version .

every one has it own method of working . in my work , i try the most as i can to not touch any core files .

Send me a PM . we can do it .

Dreamweaver is so awful, really is the worst software in the world. I make a list of every file I've edited: rm -rf ./plugins/support_manager/pipe.php rm -rf ./plugins/support_manager/views/default/client_tickets_add.pdt rm -rf ./plugins/support_manager/views/default/client_tickets_reply.pdt rm -rf ./plugins/support_manager/views/default/client_tickets_departments.pdt rm -rf ./app/views/client/bootstrap/structure.pdt rm -rf ./app/views/client/bootstrap/client_login.pdt rm -rf ./app/views/client/bootstrap/config.json rm -rf ./config/routes.php rm -rf ./components/modules/thesslstore/thesslstore.php rm -rf ./plugins/order/views/templates/wizard/config.pdt rm -rf ./plugins/order/views/templates/wizard/checkout.pdt rm -rf ./app/views/client/bootstrap/client_services_manage.pdt

They are there incase you 1. What to organise clients. 2. If you wish to give different customers different limits (maybe dedicated customers can get more time to pay, etc).

If you want to manually add a credit into their account that they can use that will not automatically be applied to any invoices then you should: Go to Settings > Company > Billing/Payment. Uncheck and save "Automatically apply loose credits". You may need to do this under Settings > Company > Client Groups also, if your Client Group settings are overriding your Company Settings. On the client profile page, under Actions, click "Record Payment". Enter the amount, select "In House Credit", and do not select any invoices that may be displayed. Regarding your 1st screenshot, when recording a payment for a specific invoice, you can change the amount and pay less or more than the invoice is for. This will result in a partial payment, full payment, or full payment + credit.

Hi Allan it's been here for ages Also the old one:

Your debugging plugin is helping me out quite a bit with PHP 7 testing.

yes .. i will do it ... normally the log file should be with the plugin files, or i have missed it in packaging the files . anyway i have updated the plugin for the check permission and i will update the package as soon as possible . we will waiting your feedback about the debugging plugin

That solved it, thanks! I had to create the "log" directory as well. Probably a good idea to do a permission check, because it makes the system unoperable.

Yes , plugins/debugger/log should have writing permission . maybe i need to add in the install a directory permission check before installing .

I believe you have put the domain groups in the Packages as-well. How can I sell Domains?

No you don't man for god sake.... You can GROUP domains if they have the same price, tick as many as you bloody well want. Or you can set the price PER domain in their own package... You have to do that with that insecure crap you mentioned and you will have to do that with the new domain manager anyway... so what's the difference? The only thing the domain manager is going to do mainly is allow a Register | Transfer | Renew pricing table. Do your research before you start making bullshit up.