EidolonHost

Yup. Basically, what I do is input text into the Text mode tab, then switch back to HTML tab in the editor. The expected behaviour was to have the text also appear in the HTML tab, so that if you needed to edit the way the text looked like... for example, such as inserting a link to something, you'd want to temporarily switch to the Text tab to add the <a href="exampledomain.com/tos-example.php">example tos</a> bit and have it appear as a clickable example tos link. But for whatever reason, this does not work as I would expect it to.

Ah, hmm... ok. Makes sense. I'm glad you're explaining the logic of how things work behind the scenes when asked about them. That's what I've currently got set, to BCC to admins as a workaround until I either knuckled down and learned to code a server manager module thing or hired someone. It's not an ideal solution but for now... it'll work, I suppose.

So I'm typing in text and occasionally pasting text into one of the Universal Module sections. And I paste some text into the editor under Text mode, then switch back to HTML mode. The text disappeared. I tried this in several different screens and it appears to affect any screen that has the HTML/Text tabs to switch from one to the other. Type any text into the Text mode area, or paste text into that area. Switch to HTML mode in the WYSIWYG editor, and you'll notice it is blank. Installed Version 3.0.6 cPanel server with Litespeed as the web server. Any additional information needed, please do let me know.

That is a point I didn't consider. Hmmm. I think maybe we should have a general dedicated server extension/module/plugin, but set up so that it's easily modifiable by anyone. Since I'm not a uber-developer, I'll have to either contact you guys or hire someone that knows Blesta well to do that for me. However, I think for now, this will work. It does conveniently allow us to not display the server's root password... but, I wonder... nope, just as I thought. It doesn't reveal the password to the admin when looking at the client's server screen. Hmmm. Any way to modify it to show based on permission levels, ie support staff can see root password based on -requirementhere- and admins can see root password based on -requirementshere-? I think for the most part, the UM module set up for Dedicated Servers are pretty much set. I just need to eventually link it to something else, such as maybe NOC-PS's server management plugin that they released for Blesta... so that the order once completed and approved, sends it all to NOC-PS. Or maybe I'm just duplicating NOC-PS's efforts. :U More research will have to be done!

Aaaaaah. OK, that makes sense. I wasn't sure if service_field_6 as written in the guide referred tot he service field IDs themselves or not. Your response says no, which tells me that the "service_field_6" option is more or less meant as a fillable field that matches that value. Correct? Also, with regards to redundancy, now that I know, I have adjusted this. Also... ugh, rewrite rule hell, fun! I'll deal with that later for now. That said, now that you've helped light the path for getting a nice Dedicated Server setup going... I have to thank you. However, my previous post, post 8... do you guys have any thoughts with regards to that?

Alright, while I'm still experimenting with the UM for dedicated servers... "{"service_field_6":{ "valid":{ "rule":"isEmpty", "negate":true, "message":"Service Field 6 must not be empty" } }}" I understood this to be referring to the service option fields. However, when trying to configure the order as an end-user, the error is returned even if the field is selected. Basically, there is 6 service options, like so. But when I go to order the product as a test, it returns the error no matter if the option is selected as such. What am I doing wrong here?

Gotcha. Wasn't sure if it was for clients or admins... alrighty then. I'll be updating the e-mail notification there. Hmmm. Okay, so I successfully went through testing the Universal Module for use with dedicated servers... now, the order is successfully created and does send notifications... however, if a client pays for the service and logs in to hit up the UM manage section to look at the info that's listed there, the details of the order isn't listed. It does say the following: UM-Dedi 8-Core Asura - derpity.eidolonhost.com 1 @ $285.00 1 Month Created on Nov 26, 2013 Renews on Dec 26, 2013 but no other details... I think I need to mess around with this a bit more. The backend does say that the service has no details. Which is a tad bit confusing. Where does one edit such things? Edit: To clarify, I mean it does not list the hostname, OS, etc as one would expect for a dedicated server.

Gotcha. Also, I'm noticing there's no option to copy stuff, especially if you're making nearly identical products, at least in the Universal Module section. I'm currently focusing on dedicated servers at this time for our company, heh. That said, I'm starting to really get the hang of things... though I need to create an e-mail template and copy-pasta that into the packages I've set up. Edit: QUick question: The e-mail notification section at the bottom -- is that for client or for admins? The documentation doesn't say.

Ah, there we go, got the radio buttons working. I had to reread the module and look at the name values field section again. It momentarily confused me, because it seemed as if you needed to escape it. Turns out that wasn't really necessary. Edit: Second question, would rather not post another post. How do you attach add-ons to this? Or is that not possible with the Universal Module?

Kinda a dumb question, since you're essentially verifying what I was asking. I wasn't entirely sure if the use-case would apply when it comes to multiple options but the isEmpty one would apply in this case. Rightyo, back to work on the UM! I'm liking how flexible this thing is. Edit: I'm trying to get the OS and control panel selection area working... but it seems like : or | isn't working. How do? As it is, I've got the control panel selection set up as: Operating System os select DEB:Debian ... but the radio option isn't working. O_o

Hi guys, So I'm getting the hang of working with the Universal module when it comes to setting up dedicated server order pages. First, a couple questions: How do you validate an option... say, for a specific set of options, like a control panel such as cPanel, DirectAdmin, etc... if a customer fails to choose an option, does the UM throw an error and request the customer to select the option? I noticed there was a small hint of input rules, but I'm not sure if that applies to the above scenario. Secondly, um... I think that's it, actually. Actually, the second question just came to me. I suspect I'll have to create additional Datacenter tags in the UM module when I actually create it there because not all of the servers in our datacenters are identical. (We work with three datacenters, and so we offer different servers based on the geographical region)... Is there a way to more or less duplicate packages and slightly edit the options, like for example the datacenter tag as mentioned in the Universal Module documentation? (also, you guys really need to provide a sample config for a Dedicated Server) Also when I added a second package, I was relieved to see that I didn't have to update the order forms dropdown. That is good to know... aheh. You can see for yourself my efforts... lol: https://eidolonhost.com/plugin/order/main/index/Dedicated%20Servers

Yeah, I have SMTP set up right now using the noreply@domain.com right now. I'd do *@domain.com but I don't think Google Apps supports that...

Looks like your order page for this theme is 500ing for me. Might want to take a look.

Ah, no I am not. I am using Google Apps for my company. I should probably have pointed that out... I may consider switching back to cPanel's e-mail system to take advantage of the piping that you've written the steps for.

Hi, Blesta Forums! So, I know over on WHMCS, there's a guide for setting up e-mail for multiple departments from one e-mail (or a few e-mail addresses) My question is: I see it's somewhat possible to do this, with the signatures and e-mail templates section. My issue at the moment is that I've already created several separate e-mail addresses, and so the billing system would be unaware of replies to any other e-mail other than noreply@domain.com E-mail piping is probably the best way to handle this... but I'm unfortunately not as familiar with e-mail piping and the like as I would like to be. A little bit of help in this area would be great.

I know the structure of buying from a reseller and the like. But not everyone realizes that who you purchase the license from typically tends to be the one that provides support. Know what I'm saying?

Ayup... I've been working on figuring out how Blesta can work with VestaCP... unfortunately, recently I had to stop my development cold when I moved recently. I've been using the Universal module to do it, but I'd far prefer an actual module that works with VestaCP.

Hi, Blesta! Remaking this thread due to it getting eaten. So, as I mentioned prior to the thread getting eaten due to the server kernel panicing as mentioned in the forum restore thread... I had updated my monthly license from Blesta to an owned one from LicenseCart. (Thanks, CubicWebs!) I noticed that while the update went through successfully with a large green updated successfully! message, it does not explicitly state that the update successfully called home. I did, however, assume that it did call home and verified that with CubicWebs that it did in fact call home. Now, I know that you can see for yourself that the install is licensed in the lower right portion of the admin panel where it says LIcensed to ... ... but the license key screen needs reworking. My suggestions are thus, then with that goal in mind: Not only a large successful update message as currently in use... but also within this screen where it displays the status of such a license. Ideally, it would display the following data: 1. Actual license key. 2. Status of license key. Active, deactivated, fraudulent, etc etc. 3. Status of support. 4. For those who resell licenses to end-users like myself and the company I represent... or for those who plan on becoming a recognized license distributor like myself, a screen where you can see for yourself who exactly handles support. Is it the reseller? Is it direct with Blesta? This would be a quick and easy glance, as it were for those who need to know that sort of information.

My post was one of those that got ate. No big deal, I'll remake. At least we had a recent backup to work with... so that's good to know. I was wondering why my post disappeared until I went and found my e-mail with the link, which directed me to here. Nice, that.

Zomex is doing Blesta designs and integrations?! Awesome, I can keep my business with Zomex, then. I was hoping I wouldn't have to look elsewhere for a template.

I agree, and it should be that way.

I would like to also 1+ this. It's great for added PCI-DSS compliance. That said... I would say that this is something that should be made standardized, in addition to the option of enabling 2-factor authentication.

No, I'm serious. With a dedicated server module with something like NOC-PS... or whatever other solution you use, you can pretty much make a winning combination.

Man, that is some beautiful work going on here, I'm seeing. My gods, what a difference. Literally, what a difference. I'm seeing active support here on the module and genuine effort in making sure the importer/migrator works. WHMCS does not do this publicly, whereas you guys do. Hell, you'd be very lucky to even get any support publicly. Such a world of difference. If I wasn't set on Blesta by this point, I am now. (but I already am, so no worries, there.) Fortunately for me, I don't have to worry about importing from WHMCS... but still.

Not sure if they have API docs. I suspect they do, also, apologies on the late response. Yup, Russian. Though they're working on translating it into English and other languages. Good to know that you found the WHMCS one... I should've found that, myself. Obviously though, I didn't think about it. Heh. Edit: Looking at the module in question, it's in English... and that is a very good thing. Also unencoded! I imagine you could do a Blesta one, based on this... Edit2: Chrome auto-translated for me: In the panel, it has a full API, but unfortunately, the documentation on how to use it is not ready yet. I'll try to briefly describe the key points, but if something is not clear, ask. in the folder / usr / local / vesta / bin scripts are located, which are both functions of the API. If you need to create a user, you need a script v-add-user, if you want to delete the database, it will make the script v-delete-database, and so on, by analogy. In other words, if you do ls / usr / local / vesta / bin, then you can get an idea of the options available. If you run the script without any parameters, it issues a statement on the use of: [Root @ V-test ~] # V-Add-User Error: not enought arguments Usage: V-Add-User USER PASSWORD EMAIL [PACKAGE] [FNAME] [LNAME] Each script returns return_code. If return_code is 0, then the operation completed successfully. Any other number will indicate an error. Actual table return codes can always be found in the file / usr / local / vesta / func / main.sh OK=0 E_ARGS=1 E_INVALID=2 E_NOTEXIST=3 E_EXISTS=4 E_SUSPENDED=5 E_UNSUSPENDED=6 E_INUSE=7 E_LIMIT=8 E_PASSWORD=9 E_FORBIDEN=10 E_DISABLED=11 E_PARSING=12 E_DISK=13 E_LA=14 E_FTP=15 E_SSH=16 E_DB=17 E_RRD=18 E_UPDATE=19 E_RESTART=20 UNIX API inspired ideas and therefore all information is stored in plain text files. Each script solves only one task. Upon successful completion of the script, for nothing is displayed. If an error occurs, the script immediately exits and displays a message on the screen. Returning to the creation of user and check the return code. [Root @ V-test ~] # V-Add-User Error: not enought arguments Usage: V-Add-User USER PASSWORD EMAIL [PACKAGE] [FNAME] [LNAME] [root @ V-test ~] # echo $? 1 From Table 1 above it E_ARGS, which means that an insufficient number of arguments. Optional parameters are enclosed in brackets kvadtratnye. To successfully create a user need only 3 azadt argument - user name, password, and email address. If the package is not specified, will be replaced by the default package, which is called the default. [Root @ V-test ~] # V-Add-User Demo d3mo0p4ssw0rd demo@vestacp.com [root @ V-test ~] # echo $? 0 In addition to the categories of scripts for creating and changing, there is a category for display, such sripta fall into the pattern v-list-*. Scripts can display information in several formats. Currently, these 3 formats: shell, plain and json. The first two are convenient to work from the command line. [Root @ V-test ~] # V-list-users Shell USER PACKAGE U_DISK U_BANDWIDTH SUSPENDED DATE ----------------------------- ------------------------- admin Default no 2013-02-11 3 0 1 0 Default test no 2013-03-10 Demo Default 0 0 no 2013-03-18 The third format is used for the operation of the web interface, which work uses the same API. For the operation of the web-based interface to the system is installed an additional web server nginx and php-fpm, to handle php. All requests made ​​under the user interface admin, which is allowed to serve api via sudo. now specifically try to answer your question about the creation of users. There are 2 options: 1) You can ipolzovat api directly executing scripts in / usr / local / vesta / bin, as it makes the web interface 2) You can use the wrapper-om the web interface to access the api. In most cases, the second option would be relevant. Further about it. By the way, just recently been implemented billing system integration WHMSC its wrapper-a. In the module for whmcs implemented key features that interest you and probably. The module is able to: * Create Customer service area * delete users * change the user's password * add web / mail / dns domain to wrapper-u need to handle POST requests, passing the user name and password admin. Here are a few examples of the most vsotrebovannyh: # Create user Add a user to a domain Delete user domains including its https://server-ip/api/?&user=admin&password=currentpwd&cmd=v-delete-user&arg1=demo And reproduced for you here, in English for the most part.