Universal Module And Order Forms Help

[EidolonHost]

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

[Michael]

You need: http://docs.blesta.com/display/user/Universal+Module#UniversalModule-InputRules

 

In 3.1 they have improved it so much that I've heard.

[EidolonHost]

You need: http://docs.blesta.com/display/user/Universal+Module#UniversalModule-InputRules

 

In 3.1 they have improved it so much that I've heard.

 

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

Edited November 26, 2013 by Keiro

[EidolonHost]

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?

[Paul]

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?

 

You associate addons to services by creating an addon package group for which your addon services belong, and assigning one or more parent groups to the addon package. This associates the addon group to a standard group, and any packages within that addon group will become available addons to those in the associated standard group.

[EidolonHost]

You associate addons to services by creating an addon package group for which your addon services belong, and assigning one or more parent groups to the addon package. This associates the addon group to a standard group, and any packages within that addon group will become available addons to those in the associated standard group.

 

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.

[Paul]

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.

 

We are planning to add an export/import feature for universal module products. This will allow you to import products created by others, and essentially clone existing ones.

 

Edit: QUick question: The e-mail notification section at the bottom -- is that for client or for admins? The documentation doesn't say.

Email notification for the universal module product is for admins. Clients are notified through the package welcome email. This should be used for provisioning purposes, to notify the right person of the order so they can manually provision if not using the API using a POST URL.

[EidolonHost]

 

We are planning to add an export/import feature for universal module products. This will allow you to import products created by others, and essentially clone existing ones.

 

Email notification for the universal module product is for admins. Clients are notified through the package welcome email. This should be used for provisioning purposes, to notify the right person of the order so they can manually provision if not using the API using a POST URL.

 

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.

[EidolonHost]

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?

[Tyson]

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?

 

Setting that rule is redundant if Required is 'Yes'.

 

Based on your screenshot, I don't see a "service_field_6" option set. You have "hostname", "ns1", "ns2", etc., but no "service_field_6", so I suspect your rule is triggering as an error because your service does not even contain the field, and thus is never submitted.

[EidolonHost]

Setting that rule is redundant if Required is 'Yes'.

 

Based on your screenshot, I don't see a "service_field_6" option set. You have "hostname", "ns1", "ns2", etc., but no "service_field_6", so I suspect your rule is triggering as an error because your service does not even contain the field, and thus is never submitted.

 

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?

[Tyson]

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?

 

Yes, the format is along the lines of:

 

{"name_of_service_from_the_name_column":{
    "anything_that_makes_sense_for_describing_what_this_rule_does_and_must_be_unique_from_others_of_the_same_service_name":{
        "rule":"isEmpty",
        "negate":true,
        "message":"The language to display when an error occurs due to this rule."
    }
}}

More described in the error checking docs.

 

 

However, my previous post, post 8... do you guys have any thoughts with regards to that?

 

The universal module does not display the fields you enter when you manage a service, beyond what you've already discovered. There is no way to tell whether the fields you have set should or should not be shown on the service, since you may be collecting information for use in the system backend; you may not want to show the client; showing the information may need to be in a specific format that the module is not aware of; or the information may be useless to the client, but might confuse them if it were shown.

 

It may be a nice feature to have, although I'm not yet sure how it would best work.

[EidolonHost]

Yes, the format is along the lines of:

 

{"name_of_service_from_the_name_column":{
    "anything_that_makes_sense_for_describing_what_this_rule_does_and_must_be_unique_from_others_of_the_same_service_name":{
        "rule":"isEmpty",
        "negate":true,
        "message":"The language to display when an error occurs due to this rule."
    }
}}

More described in the error checking docs.

 

 

 

The universal module does not display the fields you enter when you manage a service, beyond what you've already discovered. There is no way to tell whether the fields you have set should or should not be shown on the service, since you may be collecting information for use in the system backend; you may not want to show the client; showing the information may need to be in a specific format that the module is not aware of; or the information may be useless to the client, but might confuse them if it were shown.

 

It may be a nice feature to have, although I'm not yet sure how it would best work.

 

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!

[Tyson]

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

No, you would need to update the Universal Module to show the fields, but this will affect all universal module products, which may or may not be what you want. And as I mentioned previously, I'm not sure how best such a feature would be implemented here.

 

As for currently getting the values of the fields, you can have them emailed to the client (and BCC'd to admins) be setting them in the package welcome email. The same tags are available as they are set in the Universal module, e.g. {service.hostname}

[EidolonHost]

No, you would need to update the Universal Module to show the fields, but this will affect all universal module products, which may or may not be what you want. And as I mentioned previously, I'm not sure how best such a feature would be implemented here.

 

As for currently getting the values of the fields, you can have them emailed to the client (and BCC'd to admins) be setting them in the package welcome email. The same tags are available as they are set in the Universal module, e.g. {service.hostname}

 

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.

[Max]

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

 

Personally, I think storing root passwords permanently in a central database is NOT a good idea.

 

If you are selling unmanaged servers, there is no need for you to have root access on the customer's server.

Granting yourself more access than you strictly should have for the type of service you are offering can generate interesting liability problems, if your central database is ever compromised.

 

If you do provide server management, there are more secure options like SSH public key authentication to access the server, with the added benefit that it still works if the user ever changes the password...  

 

 

>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

 

Nah, we are not working on order forms and such.

Think that's more a task for the Blesta team, as that's not something specific to our software.

[EidolonHost]

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

 

Personally, I think storing root passwords permanently in a central database is NOT a good idea.

 

If you are selling unmanaged servers, there is no need for you to have root access on the customer's server.

Granting yourself more access than you strictly should have for the type of service you are offering can generate interesting liability problems, if your central database is ever compromised.

 

If you do provide server management, there are more secure options like SSH public key authentication to access the server, with the added benefit that it still works if the user ever changes the password...  

 

 

>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

 

Nah, we are not working on order forms and such.

Think that's more a task for the Blesta team, as that's not something specific to our software.

 

We use SSH keys for managed and unmanaged servers. That's current policy and we use our keys to help reset customers' root passwords, if they somehow manage to lose it. We no longer provide passwords that they themselves used when initially setting up the server if they happen to lose the passwords.

 

Resetting the customer's root password isn't much of an issue... but occasionally we get requests to give them their current (or old password if they changed it) and we verify that the client making the request is indeed the client... before giving them their current root password in our system.

 

This was before I restructured the company, though.