Jump to content

interfasys

Members
  • Posts

    249
  • Joined

  • Last visited

  • Days Won

    3

Posts posted by interfasys

  1. 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.

  2. 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.

  3. It is, you try registering a domain via the module you'll get a error or maybe 3 domains registered :) not tried it but I take it that will happen.

    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.

  4. 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

  5. I've been looking for a dark theme, i like the look of this, but I can't seem to install it.  I'm running 3.2.2.

     

    I go to settings -> Look and Feel. Click add theme, ensure Import a theme is selected and click choose file then click create theme and I get an error asking me to enter a theme name and valid 6 character hex code for each color.

     

    I would love this theme.

    I did the same mistake. We take autoinstallers for granted :D

     

    Unpack the file and upload the json files that you want to use (client and/or admin)

  6. Because what people like myself do if we customised it is extract the zip, remove the files which will overwrite and upgrade, but in patches only plugins may be overwritten, there's no routes. If you custom something you expect a little bit of manual labour.

    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.

  7. 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.

×
×
  • Create New...