interfasys

Yeah, there are tricks we can use to use a 2nd language, but it's more like a temporary solution

It would be confusing to me, but not for someone in my team. We wouldn't name a package in a language nobody in the company understands. Besides, it would probably look like this: Directadmin Pro होस्टिंग , so it would be recognisable. It's just some of the extra words which usually need to be translated. And there is also a solution for the problem you've mentioned: to make it possible to open tickets about services. The problem with package translations gets even worse with the universal module where we can sell all sorts of services and have custom fields asking important questions. It's never great when your invoice is full of lines you only understand half of, if the customer even buys anything.

It's not always feasible to have universal package names, so it would be great if Blesta could let us type the name in all the installed languages, just like for the descriptions

OK, so maybe it's more of a documentation problem.

The more happy developers we get, the more useful modules we'll get.

OK, so found out why this was happening. As suspected, the order had to be accepted first, but I couldn't find where to accept it. For future reference, orders are "hidden" in the orders widget which you may have to activate so that it shows up on the billing dashboard.

It seems there is only one way to reach the list of orders and that's via a widget which may not have been activated. So, it would be great if "orders" could be added to the billing menu

Just tested and customers can order one domain just fine even though the package has been defined to handle many. So the original question remains.

I'm not transferring any domains and see the exact same message when trying to activate a domain. It looks like Blesta is asking Logicboxes to tell it about the domain (as it does not provide any registering information), but the domain has not been registered yet, so Logicboxes is telling it that. This is coming from Billing>Services>In review, trying to activate the domain that the customer has just purchased. The button says "manage", but there is no "activate", "register" or "edit" button.

If that were the case, then Blesta would not let us select multiple domains per package. All domains would be in a dropdown or everything would be greyed out as soon as you select one.

I hope not :S

In order to be compatible with the new miraculous and mythical Blesta domain pricing manager , should we organise domain packages per price or per extension? During a WH*CS import, one package per extension is created, but if we create a package manually, we can add as many extensions that we like to a package, as long as they all sell at the same price and use the same registrar. With the one package per price approach, we end up with one duplicate per registrar and per price + one package per exception $20 domains at Netim $20 domains at Namecheap $40 domains at Netim $40 domains at Namecheap $500 .tm at OVH ... It's a bit messy With the one package per extension approach, we end up with hundreds of packages, which is totally unmanageable via Blesta at the moment. Even with a pricing manager which can apply price slabs to groups of packages, who wants to have to manage hundreds of packages? So, I'm hoping for the new way to manage domains to be like this: domain packages can still be built the way they are today, one package can include all the extensions we want to offer in that package. It could be useful to be able to offer different groups of domains to different types of customers. An extension can belong to several packages, etc. there is no domain pricing in the domain packages anymore if discounts can be applied on order forms for certain packages domain pricing is defined in a new domain pricing manager, which for each extension allows us to select a registrar and the price for each operation and the number of years. That module will be smart and full of goodies to make it easy to make changes to similarly priced domains With such a configuration, we would only have a couple of domains packages, but I reckon, most people would only have one. So, is this where Blesta is going or is it best to fill our packages list with extension packages?

Share categories with "Predefined Responses" maybe since it's very likely we're going to have the same categories Make it easy to add an article to a reply, either as a link or embedded Top X articles widget Comments on article Comment moderation Rating on article Real-time search engine (can be turned off) Well designed articles previews in the search results which includes the title, the last update, the link and an exerpt Permissions: Public and Private KB for staff, Maybe more granularity over time Guest commenting on/off switch Article versioning w/ diff viewer File attachmnents Article tagging Export to PDF Article Id to make it easy to reference by both staff and customers Styling via shortcodes. Useful for warning, note, etc. boxes Bookmarking system for customers so that they can quickly find the articles which matter to them Import system which can parse markdown and other wiki syntaxes Category tree in a sidebar? Navigation in a hidden/revealed menu above the current article? RSS feed so that customers can stay current

Meh, US only, not interested

I think you've nailed it

Yeah, I think loading another custom.php file which doesn't get overwritten would work and in the meantime, maybe a warning in the doc regarding the fact that _custom.php gets overwritten with every update.

Ah, but that's because you didn't put this rule first

Here you go, mate. RewriteCond %{REMOTE_HOST} !^192\.168\.1\. RewriteRule ^admin https://myblesta.panel [L]

I did the same mistake. We take autoinstallers for granted Unpack the file and upload the json files that you want to use (client and/or admin)

Currently, when defining a dropdown, it's not possible to display the different elements in the dropdown using translated text, which means that unless, we use brand names, people who don't understand english may not understand some of the custom fields they're presented with.

Re-reading my OP, it wasn't clear. I'll post a feature request.

I disagree. Of course, it's not difficult to write patches, update scripts, etc., but we're not talking modifying the core here, but configuring or perhaps customising an installation using documented switches and configuration files put at our disposal. Other projects have php.sample files which we rename to personalise or look for .local files and use that. Of course, one has to port changes made to these files, but they're usually only touched when there is a major upgrade. Maybe the documentation needs to be updated. In my opinion, you can't just say, put your customisations here and then wipe the file.

That's what I've used and it doesn't work.

Give us the headers for the CSV files and convert the WHMCS importer into a generic CSV importer. We could probably be getting the headers by running the script to spit out SQL commands and converting the SELECT fields into table headers, but the Blesta devs probably have a schema they use to map everything out. Then this can be used instead of connecting to an external DB, to put the data into arrays ready to populate Blesta. In my case, I can probably track all the orders created through the various systems I've used and build various tables ready to be installed into Blesta in much less time than it would take me to try and re conciliate everything into WHMCS and it would also give me the full history for the past 10 years.