Leaderboard

a lot of us want to translate blesta to thier native language , but this are a obstacle , big obstacle , is the translator website , is not easy to manage translation and to correct some old translation . the worth is in blesta upgrade , how you can know wich file has been added to it some new lang ? so i have this issue for long time , and i have resolved with my own way , today i have dedcied to share the translator plugin with the community , my translator motor , check the native language 'en_us' with the existing languages , with this plugin you can know : wich file are missing from your language directory . wich phrases are missing from your language file . translated the files within your blesta system , save it . off course drink coffe with you playing with the translation . before i upload it , what you need tose in this translator plugin . screenshot http://host-image.net/v.php?id=69170admin_languages.png waiting your's idea .

Thanks for listing the steps to duplicate. It should be noted that you also need to ensure you have your WHM account configured to require a password strength (e.g. 60) when attempting to duplicate this behavior. It looks like the API response from changing the account password is not in the same format as the other API responses that the module expects, so it was not handling that error. I've updated the module to handle that error for the next release. See CORE-1580. It's entirely up to the module to determine what an error is with respect to the API it makes use of, and to then let Blesta know what it is, if any. While cPanel generally displays friendly error messages, likely because the same message is shown in their account interfaces, error responses from the API can't always be parsed and sent to the view in Blesta. Some APIs don't return friendly messages (maybe just an error code #), or may contain sensitive information that should not be displayed in the public interface. The module should determine what the best error message response would be considering the information it has at hand and the fact that it will be displayed in the interface. This is why several extensions sometimes defer to generic error messages. The cPanel error message for this particular password request can be confusing: Sorry, the password you selected cannot be used because it is too weak and would be too easy to guess. Please select a password with strength rating of 60 or higher. The second sentence tells the user to select a password with a strength of 60+. What is 60 and how is it determined? The module doesn't know, the user won't know, and even I don't know what would pass that requirement. It might make more sense in cPanel because they display a password strength indicator while you type in your password, but that strength indicator is not available over the API. It would likely be better for the module to translate this message into something more useful/generic because of this, such as "The password you selected was rejected. Please enter a longer password containing numbers, letters, and symbols." But I'll leave that as a feature for another day.

D'oh! That did the trick. I was confused as to why I kept getting this. Fixed, now.

These are package screenshots, but it does confirm my suspicions. Go to Settings > Company > Modules, and manage the Universal Module, editing your Product. All of these fields appear in the Package section, when they should appear in the Service section. The Package section displays fields on the Package, the Service section displays fields for clients during checkout.

We are planning to add support for Omnipay gateways, of which GoCardless is one, see https://github.com/thephpleague/omnipay. I'm not sure if their implementation supports the features of GoCardless that you are expecting. Omnipay is one of the items we cannot implement until we have raised the minimum system requirements to include PHP 5.3+. This dependency change is expected in version 4.0.

i will merge this plugin with admin tools plugin , i got some idea from your points , i don't know if i can do exactly what you have request (time here is matter) , but anyway i will release it with the basic function in admin tools plugin , and in every new release i will add more options to it .

That's funny you say that. I was holding off on blaming the host, but I checked our old WHMCS installation. It seems there is a similar bug that wasn't there. Time to move hosts. Thanks for the help!

i have this in some of my made-in-home modules , in case of error module , i display the module error response . and that is the correct way . because the success message has one difinition , error message is multiple and has some cases , also in some controle panel when updated it has more error message and rules .

so , i thunk is a bug , because the module is sending a no success message , and blesta should take i consideration this error response , like the other no success message .

Just to clarify . I m not talkink about the cron delay . Tyson has got my idea , and well descriped the obstacle of it . Not a cron subject .

If this will cause a lot of probleme , ingore it , i will try to find my own solution . But just to enrich this discussion , why not to add new field in invoice , let say 'sended' , put it in false per default , if invoice sended put it true , if proforma converted to invoice then reput it to false , this way the invoice will be ready to sent again , this is just my 2cent in this behavior . This because i think you have made a complicated/ugly system for invoice delivery . But is working

The problem is more complex than updating that null value, which, by default, uses the language the system is currently using. If you only updated that value, it would be possible for clients to receive their invoice PDF in another client's default language. I've resolved this issue for v3.4.1 in CORE-1559. It will probably be available next week.