Add new config option types:

1. Text (input)
2. Textarea
3. Password

It's often necessary to create custom service fields when using a module other than the Universal Module. With the Universal Module, service fields can be added, which are requested during the order process.

Sometimes people want to ask for additional fields while using a specific module during checkout so that the order can be customized. The custom data could be manually handled by staff, or could be accessed via the Services.add event to perform some automated action.

For example, when using the cPanel module, we could request a Select field (For Script), Admin Username, Admin Password, and Installation directory and Softaculous could use this information to perform an automated installation of Wordpress (Or even Blesta), after the cPanel account has been provisioned. This is one use case, but there are many possibilities and the competition already supports these kinds of custom fields. This would also fit very well with CORE-1551 (No module has to be selected) and would make the Universal Module unnecessary in most cases, except for it's email and HTTP POST request ability.

CORE-1550 describes breaking Package create/edit into multiple tabs.

• Add a new Package tab called "Custom Fields"
• Support the following field types: Text, Text Area, Password, Select, Radio, Checkbox
• Ask for a field Name, Description/Label (Shown to users), Regex (For validation)
• Each field should have the following atributes (checkbox): Client can Add (Similar to config options. If clients can't add, only admins can.), Required
• There is no associated cost with any Custom Fields

This is very similar to the Universal Module "Service" options.

If possible, these fields should be treated as if they are module service fields, but would be requested after any normal module service fields. The data should be stored in the same way as module service fields. If we can do that, then any changes to the order plugin and client area should be fairly minimal. It's just that the module would not utilize this data, and it would treat it as extraneous data.

These fields would be associated with a specific package only, and would not be "re-usable" by other packages. Cloning a package should also clone this data and be associated with the new package, being independent. The table could be called something like package_fields