PauloV

What about posting in social media? (Facebook/Twitter/Google Plus)

Didi you tried to Post on outher foruns like WHT with the link to this fórum? maybe it helps

Common people No one make an offer? Is for a good cause

I dont know if (Cody or Tyson) can help me on the last post above Thanks in advance

+1

Absolut amazing work I just did a donation for your work (Paypal: 2K5903321U590691D)

loooool no prob Just finishing the OpenSRS Module, Bookmarks Plugins, and release the update for Live Chat, Support Manager Pro and Admin Loading and I will do that next One of this days we have to meet (the world is smaller then we think), and drink a cofee or a beer

Great solution/idea naja7host We will also implement your idea its genius and can reduce a lot of time spendimg

+1 Its better to submit a feature request I want this also

How the hell can I set a default value if I want the field to be "required"? lol I dont see the intended prupose to have the two option selected, "required" + "read only", if we cant use them both as they should work. To not discuss this more as a "BUG" because I dont like to argue and make more exemples and excuses , can you (Tyson/Cody/Paul) please move this forum to "Sugestions"? this way I dont have to make anouther post regarding asking this Like I always said, its just to help Blesta, not me, because I can easly add this to our Blesta, modifing a simple line of code on the Client Form.

We have some similar cases, but we still use WHMCS What we usually do, and if we use blesta we do the same is: 1º- Cancel the invoice associated to that service 2º- Manual Renew the service and change the next renew date to the next renew date (even if the client didnt pay yet) 3º- Create a manual invoice with the same info of the original canceled invoice. This way, if you add a payment to the new invoice, it will not send the renew command

Regarding to this tread and for the releasing of OpenSRS Domain Module We see that on Domain Modules we can check the "$package->meta->type" (has i describe on first post of this forum) and we can add new types in getPackageFields() on array $types So what we have try several times, but we didnt succeed 100% is this: 1º- We have added two new types called: - domain_renew - domain_transfer because we want to add diferent prices for domain_renew, domain_transfer, and for domain (regist a new domain). This part is 100% and we can create packages with diferent prices witout any problems 2º- On Domain Order Form, in Client Area, we want wen a client click on the button "Transfer" to get the prices from the "type" domaintransfer, we have trie many things bu we still dont find an easy solution, so we ask. Can you help me, and point to the right direction? how can we get on "Domain Order Form" wen clicking on "Transfer Domain" to display the TLD's with the process from the type "domaintransfer"? 3º- This step is easy for us, and is the last step, wen a client regist a domain or transfer a domain, we simple execute a query to change the "type" to "domainrenew" to get the correct prices for renewing domains. With this 3 simple steps we fix 100% the problem on Domains Modules, and we only need a way to implement the "2º" step After this is resolved, its easy to implement some news things like for exemple import TLD's from registrars, or even import an CSV to add/update TLD, prices.

Yes, I know, but dosent make sence The "read only" only has to work on Client Area and not wen a client is registering How the hell we can make a field "read only" + "required" lol How it is done right now we cannot ever, never, enable the "read only" + "required" or the client cannot finish the process There is 3 kinds of "bugs" in my view 1º- Bugs that cause errors 2º- Bugs that dosent work the way it should work 3º- Bugs that dosent make sense the way it works This "Bug" goes into the 2º and 3º category "Sugesttions", is for me, new functionality that isnt alredy implementd, in this case dosent fit here because the functionality alredy exists P.S- Only my opinion

Hello, Wen we add a new custom field in admin area with the options: Visible to Clients (checked) Read Only for Clients (cheked) Required (yes) Wen a Client is on the Client Registration Form, the field is "Read Only", and the client cannot insert the info needed. For exemple, we want the client to insert the info on that custom field wen registering as client, but after that, we dont want the client to change that field in Client Area.

Hello, It would be great if we had an "Todo List" Plugin that logs all entries to manually review and do, for exemple: Create a Service in "Module": f there is an error creating, add to the "Todo List" a task to manually review the error, fixt it and execute again the creation Cancel Scheduled Services: If we dont activate in Crons the task to auto cancel services, add a task to the Todo List to manually review and cancel the service Regist a Domain: If there is a problem wen registering a Domain, add to the "Todo List" a task to manually review the error o correct and try again Transfer a Domain: If the Module initiate a transfer, add an entrie to the "Todo List" to check transfer status after 5 days. etc..

+1

Very well design in the first look

lol yes, i make the mistake of saying that OpenSSL[heartbleed], (that can be installed on any OS), was Linux fault

Just to raise the mood in Blesta Foruns, a new reformulated (by me) joke because of the lates security breaches: Three male programmers were in the bathroom standing at the urinals. The first programmer finishes, walks over to the sink to wash his hands. He then proceeds to dry his hands very carefully. He uses paper towel after paper towel and ensures that every single spot of water on his hands is dried. Turning to the other two, he says, "At Windows, we are trained to be extremely thorough." The second programmer finishes his task at the urinal and he proceeds to wash his hands. He uses a single paper towel and makes sure that he dries his hands using every available portion of the paper towel. He turns and says, "At Macintosh not only are we trained to be extremely thorough but we are also trained to be extremely efficient." The third programmer finished and walks straight for the door, shouting over his shoulder. "At RedHat, we sometimes PISS on our hands, like in heartbleed, and the recent shellshock, but we trie hard not to"

Im out of "Like This" since the morning on Blesta Foruns, lol, So I have to reply to Say "PauloV Like This"

lol, im going to finish the last lines of code on Thusday, to trie to relase on nex week

1º- How to sell an Online Automated Hosting Billing System? 2º- What can we offer that outhers dont alredy offer? This is the right questions Blesta is not selling a services, he is selling a master pice of software, and like a great painting or a great car, it has to get the best of best Wen you buy a new Car you dont want to drive in a dirt road with alot of holes (only if you buy an offroad car lol) Wen you buy a painting (for paintig art lovers), you dont want to put in a wall that dosent hold the painting Wen someone buys Blesta, they dont want to run in a server with a minimum of PHP 5.1 It seams today am a bit inspired lol, I have to make a break and drink a coffee Im going to catch the nex flight to UK and invite Mike to go to Starbucks or any outher popular Coffee Shop in UK

Real Senário: WHMCS (next release): PHP =>PHP 5.3.7 WHSuite: PHP => 5.3.7 HostBill:: PHP => 5.3 ClientExec: PHP => 5.3 Blesta: PHP => 5.1 Migrating from PHP 5.1 to 5.2: http://php.net/manual/en/migration52.changes.php Migrating from PHP 5.2 to 5.3: http://php.net/manual/en/migration53.changes.php And so on... The bottom line is: You are not enforce to upgrade PHP, is just new version have better codding and fix some bugs, that Blesta Devs can implement on Blesta Code, Blesta connot use this for exemple or it will break users that have PHP == 5.1: PHP 5.2 New Functions: http://php.net/manual/en/migration52.functions.php PHP 5.3 New Functions: http://php.net/manual/en/migration53.functions.php But are alot of outher new things that we can do with an updated PHP version that we cant do now with a minimum of PHP 5.1 For me as a programmer, wen I make a new plugin or module for Blesta I have to think that Blesta minimum is PHP 5.1, so I have to code thinking like that, and so I cannot use some of the new toys on PHP => 5.3 it will not work ar it will breack some Blesta Users Like I said in the begining, I personaly dont mind that Blesta uses PHP 5.1 as minimum, but to help Blesta Grow (I love Blesta, and really want to help), I sugest to raise the minimum requirement

Some confusing data rouling out, the fix was released 2 hours ago OK, doing some digg I found the new patch: https://access.redhat.com/articles/1200223 https://bugzilla.redhat.com/show_bug.cgi?id=1146319 Patch for Red Hat 5, 6 and 7: https://rhn.redhat.com/errata/RHSA-2014-1306.html The updated and correct version is: ==Red Hat V5 == 32: bash-3.2-33.el5_11.4.i386.rpm 64: bash-3.2-33.el5_11.4.x86_64.rpm ==Red Hat V6 (most used on servers) == 64: bash-4.1.2-15.el6_5.2.x86_64.rpm ==Red Hat V7 == 64: bash-4.2.45-5.el7_0.4.x86_64.rpm

I only publish the links because I have checked some background first, and ofcourse the Code on testing is public available But thanks for the warning and I have added an warning note above on the test links