thynan

Allright, thanks for the info!

Hi! Sorry if this has been asked before, or if it is already documented, but I couldn't find any specific information on this: Is it possible to just upgrade from Blesta 3.4 to 4.0, or do I have to to upgrade to the latest version of Blesta 3 before upgrading to 4? Also, if I have to upgrade to the latest Version of 3.x, can I directly upgrade to the latest version, or do I have to upgrade from minor version to minor version?

I want to be able to "lock pakcage cancellation" for customers, X days before the package gets renewed. In our case, we allow customers to cancel their hosting packages up to 1 month before it gets renewed. After that, they should not be allowed to cancel the package before it get's renewed. Example: Package gets renewed at 1.1.2017. The customer can cancel the package immediately/at the end of term until 30.11.2017. From 1.12 2017 to 31.12.2017, he can not cancel it before it gets renewed (he can schedule a cancellation at the end of the new perio (31.12.2017), but then the service is already renewed an has to be payed).

Hi! sorry if this feature is already implemented, but I couldn't find it in Blesta: I want to be able to "lock pakcage cancellation" for customers, X days before the package gets renewed. In our case, we allow customers to cancel their hosting packages up to 1 month before it gets renewed. After that, they should not be allowed to cancel the package before it get's renewed. Example: Package gets renewed at 1.1.2017. The customer can cancel the package immediately until 30.11.2017. From 1.12 2017 to 31.12.2017, he can not cancel it before it gets renewed (he can schedule a cancellation at the end of the new perios (31.12.2017), but then the package is already renewed an has to be payed). I guess this has to be implemented on a module level and not in the core itself right? Are there any modules that implement this?

Hi! No, we don't have any updates yet. The module works for our (rather restricted) use at the moment, so we won't continue developing it until the new "domain management" is released with blesta core. When that happens, we plan to upgrade and extend this module. As far as I know, that will happen with Blesta 4.1 (fingers crossed).

Hi guys! Sorry for the delay. We were waiting for the new domain management of blesta to be finished, so the whole thing was put on ice. However, we now launched our blesta installation without domain management, and are using a workaround with universal module... The module is used by us in production. However it is definitely not finished as a module that works out of the box for everyone. But maybe some of you can use it, or use it with some modifications, or even as a starting point for your own development. I already wrote about the functions a bit a few posts back: http://www.blesta.com/forums/index.php?/topic/1210-ispconfig-module/?p=27826 Some Info, if you want to try the module: In our company, we have a free domain for every customer who orders a hosting package. To replicate this in the blesta module, i added a "domain" field, which the user can fill out during the order. If the customer entered a valid domain, the module automatically creates a DNS-Zone in ISPConfig for the user, using the default dns template configured in ISPConfig. The domain is also shown in the blesta UI, so the customer sees it as "included domain" This is a workaround, because it would be better to manage this with a domain module, but as I mentioned above, we are still waiting for the new domain management before managing domains correctly in blesta. This "domain functionality" can be rather easily "pulled out" of the module though. Just search for the word domain, and remove what you dont need. (there are some TODO notes reagarding the domain/zone-file functionality in the code - check those out too) Reseller functions are not implemented at all. Be aware that this module is a work in progress, and definitely test everything on a testserver before using it. I used the cpanel module which was implemented by the blesta devs themselves as a "guideline" for this module. And by "guideline" I mean that I copy pasted vigorously. The reason for that is, that many of the functions (managing Servers, Packages, Services etc) are very similar in all hosting-panel modules, so it made sense to work with the structure that the blesta developers provided in their modules. I did not really test the server-groups and the "use first non full server" option that blesta provides. That is one of the parts I copied from the cpanel module... It should work, but don't assume it before you tried. Generally read the TODO notes in the ispconfig.php file - they may offer some insight.. Install instructions: Install module as usual Create a remote user in your ispconfig installation (system -> remote users) You need to add some custom functions to the remoting.inc.php file of ispconfig. This is described in the remoting.inc.php file I included in the module. Go to blesta -> system -> modules -> ispconfig -> manage -> add server Server Label: any name Hostname Master Server: the hostname of your server (or Master-Server if it is a multi-server setup) Remote user name: the name of the remote user you created in ISPConfig SOAP Location: Something like 'https://servername.domain.tld:8080/remote/index.php' SOAP URI: something like 'https://servername.domain.tld:8080/remote/' We usually use gitlab in our company, however for this project I set up a GitHub repo. This is my first GitHub repo - so bear with me. I didn't create any issues or extensive readme yet - if some of you are interested in continuing development and organizing some collarboration, just let me know. GitHub URL: https://github.com/thynan/blesta-ispconfig

Ah, you're obviously right - was in a bit of a hurry.. Can you see any other implications by removing the firstname / lastname as required, except on invoices and emails? I can't think of anything right now, but i don't want the system to crash on any important operation because of a missing name...

Ok, I solved it by hacking core a bit. Here's what I did: 1. in app/models/contact.php I commented out the first_name and last_name validation. So now I can create clients and contacts with empty first- and lastname. 2. On the invoice, I automatically get the desired customer-address. The firstname lastname is empty, so I only get the companyname on the first line, and then the address. 3. In my email-templates, I edited the first line to this: {% if contact.first_name %} Sehr geehrte/r {contact.first_name} {contact.last_name}, {% endif %} {% if not contact.first_name %} Sehr geehrte Damen und Herren, {% endif %} So if I have a contact first_name, I greet the customer with his name, else (if it's a company) I just write a generic greeting. Can anybody think of other areas where I could run into trouble because of the missing firstname/lastname?

Hi, we would also definitely need this. There should be a difference between company contacts, and private contacts. We have some customers where we don't have a specific contact firstname/lastname. Only the Company name. This should be reflected in E-Mail Templates, and also on Invoices. And of course Firstname/Lastname can't be a required field in this case. Can you post a link to the feature request? I don't seem to find it.

@naja7host: ok, I suspected that it was not possible to generally change the due date. The workaround you suggest is ok I guess. Maybe I'll just remove the due_date from the Invoice and put a custom Info there. @Licensecart: thanks again, but you still mes-read. I don't want to edit individual invoices after they are created (and already sent to the client). I want to systemwide change the due date. But apparently that is not possible without hacking the blesta-core.

Hi, thanks for the reply, but I don't want to change the renew date, I want to change the due-date. Like I said, when a client orders a service, he gets an invoice, which has a due date of the same day as he ordered it. I want the due date to be 2 weeks later. Also, I don't want to manually change this after the service was created - the customer already got his invoice at that point. I want to genereally push the due-date back 2 weeks after the renew/creation date for all services. Is that possible?

Hi! When a service is created, the due date is the same as the invoice date. I want to push back the due-date by 2 weeks, so my customers don't get an invoice that is due on the same day. How can this be done? Is this possible via interface, or do I have to hack the code? PS: I know that I can just change the due date on the invoice by hacking the default_invoice_pdf.php or creating my own invoice template. But I want to change the due date system-wide, so the payment reminders are working correctly, and the client sees the correct due date in his dashboard.

Hi! In the clients "payment selection "view (...client/pay/method/) and the "payment confirmation" view (...client/pay/confirm/) the name of the "Offline Payment" method ist not translated. Other payment methods are translated correctly - only offline payment is not: example: my language file for the offline payment gateway (offline.php) looks like this: <?php $lang['Offline.name'] = "Vorauskasse"; $lang['Offline.instructions'] = "Anleitung"; // Errors $lang['Offline.!error.instructions.valid'] = "Sie müssen Anweisungen angeben"; ?> What could be the problem here?

Has a "disable partial payment" option been implemented yet? Or is it planned? We would like to remove that option too, and I don't know if it's a good idea to hack core files to achieve this..

Hi! I have a package with a textfield in the configurable options. The package is from a custom module of me. In the order-form (wizard) the textfield is shown correclty with the label. However, the placeholder-attribute of the textfield is the same as the label value. I want to change the placeholder to something different. In my module, the field gets created like this: // Create domain label $domain = $fields->label(Language::_("Ispconfig.service_field.domain", true), "ispconfig_domain"); // Create domain field and attach to domain label $domain->attach($fields->fieldText("ispconfig_domain", $this->Html->ifSet($vars->ispconfig_domain, $this->Html->ifSet($vars->ispconfig_domain)), array('id'=>"ispconfig_domain", 'placeholder' => 'yourdomain.at'))); // Set the label as a field $fields->setField($domain); So I thought the placeholder for the field should be "yourdomain.at". However, it's always the same as the label of the textfield. Does the placeholder-attribute i set get's overwritten somewere?

Hi again, I can't get the addon-functionality to work correctly with an OpenSRS package. Has anyone tried this and got it to work? Here's what I did: I created a group called "Webhosting", and an addon group called "Domain Addon". I selected the "Webhosting" group as parent of the "Domain Addon" group. I created 2 packages - one for webhosting which belongs to the "Webhosting" group, and one for domains, using the OpenSRS module, which belongs to the "Domain Addon" group. I created an order form, with the following parameters: Type: Domain and Other Domain Package Group: Webhosting --> I couldnt select the "Domain Addon" group here. Maybe that's the problem? Assigned Package Group: Webhosting When I visit the order form's "domain availability" page, I don't see the checkboxes below the textfield, where I can usually select the available domain-endings. And whenever I enter a domain, I get a "That domain name is not supported" error message. Did I configure something wrong, or does the module just not work as an addon-packge yet?

I also just made a little donation. You and naja7 are making Blesta work for me. The order process of the OpenSRS modue still has some weird behaviour for me however. I'll be back tomorrow with more questions - time to go to bed now... Hope you don't get tired of me yet..

Hi! Thanks for the quick answer. No, I didn't use the Domain and Other ordering form, I used the general form. Now I switched to the Domain and Other form, and the "check domain availability" page shows. However, it shows at the very first page in the order process now. So when the customer goes to the default order form, the first page is the "check domain availability" page. So the customer has chose a domain before he even selected a package. That is of course a bit confusing. Ideally, the "check domain availability" page should show after the customer has selected the opensrs package from the available addons. If the customer doesn't select the addon, then the page should never be shown. Is it possible to configure it that way?

Hi PauloV! First of all, thanks for the great module! Really the only one for a Domainregistrar that supports good prices for .at domains... I tried the module out today, I found an issues. I know it's alpha, so maybe this just isn't supported yet: When I use the OpenSRS Plugin to create an Addon-Package for another Package, the page where the user can choose the domainname, and check availability is not shown in the order process. Instead it goes straight to the nameserver settings etc. So I can only use the OpenSRS module for "standalone" Packages. Did I configure something wrong, or does the module just not support the addon-package functionality yet? I also nothiced that the domain-choose / domain-checker page is never shown when I use the module in sandbox mode.

Wow, that is a nice workaround! Thanks again Naja7. I guess it's time for a little donation. One question: what does the "Enable EU Invoicing" setting do exactly?

I also think that that is really bad - when the invoice contact details get changed, only new invoices should be touched. Old invoices must never be modified - I can't believe that that is only a requirement in the EU. The only "solution" I found for this is to disallow users to change their contact information at all (easy hack with some javascript that naja7host dhowed me). That fixes the problem that existing invoices get modified, but it obviously creates the problem that no client can ever actually change his contact information. So if he moves, and get's a new address, we're out of luck... I think that is a problem that should be addressed as soon as possible - it's a real showstopper..

Hi, sorry for the late answer, I wasn't working on Blesta for a while.. At the moment there is no Git Hub location for the project. However, after checking back with my CEO we decided to make the module public. I will create a Git Hub project and check back here when i'm done. I will have to do some cleanup / documentation first, because atm it's still a bit too messy. It may take me a few days to get to it however, since I'm a bit swamped with work currently.

Nice! Looking forward to testing it. +1 for the Domain Manager btw.

as The thing is, that you as a company have to do the IP check (or any other check that "proves" where the customer is from), and provide some kind of evidence that you did, if I understand the regulation correctly. But maybe no tax isnspector will ever check for that? I don't know... Hmm, another solution may be to show all prices with the tax of your country included, and give the customer some information that the final price may be slightly different, and will be shown as soon as he logs in? There is already a message in most of the built in order forms: "Any applicable taxes will be calculated after you register or log in." So we would have to include some default tax, and change that message a bit. I don't know if that would be enough however? Is there already an option to show prices with a default tax included in Blesta? If there is, i couldn't find it yet.

Wow, that looks great, I'll look into it as soon as I got the time. Thanks for looking it up naja7, you re starting to become my personal blesta coach...