EuroDomenii

Exactly! My use case is selling subdomains ( we’ve done a fork of generic_domains with internal whois). This really needs a separate order form. However, I guess that even separating order forms of new gTLDs versus classic TLDs, would be another use case.

Before jumping into domain package group architecture, I didn’t find a way to change the default value from interface https://docs.blesta.com/display/user/Domain+Manager#DomainManager-Advanced Here it says: Setting - TLD Package Group Default value - TLDs Pricing Packages Description - The package group to which all TLD packages will be assigned. But there’s no such setting at admin/plugin/domains/admin_domains/configuration/?tab=advanced Anyway, the default value is 1, in the company_settings table. The setup workflow is somehow by design stealth, maybe for the benefit of non-advanced user setups. This default package group is hidden at admin/packages/groups/ ( becomes visible by Toggle filters with Show Hidden Package Groups ) By default, creating a TLD assign this domain package group via private function createPackage(array $vars), from plugins\domains\models\domains_tlds.php // Set package group id if (!isset($vars['package_group_id'])) { $domains_package_group = $this->Companies->getSetting( $vars['company_id'], 'domains_package_group' ); Let’s imagine the scenario in which I would like to have another domain package group, in order to set up a different order form. You would have to find the hidden package admin/packages/ ( by Toggle filters with Show Hidden Packages) , and assign a different group membership. The downside of working with different domain package groups from the company setting, is that you miss all the cron goodies. Let's take a look at the cron task from plugins\domains\domains_plugin.php ( listed in GUI at /admin/settings/company/plugins/settings/IdPlugin/automation/ ), the services are restricted to $settings['domains_package_group'] of the company private function synchronizeDomains() $company_id = Configure::get('Blesta.company_id'); $settings = $this->Form->collapseObjectArray($this->Companies->getSettings($company_id), 'value', 'key'); if (!isset($settings['domains_package_group'])) { return; } // Find all domain services $services = $this->Services->getAll( ['date_added' => 'DESC'], true, ['package_group_id' => $settings['domains_package_group']] ); private function cronDomainTermChange() // Find all domain services that do not have a 1 year pricing term $services = $this->Services->getAll( ['date_added' => 'DESC'], true, [ 'package_group_id' => $settings['domains_package_group'], 'excluded_pricing_term' => 1, 'pricing_period' => 'year' ] ); private function cronDomainRenewalReminders() // Fetch all qualifying services $services = $this->Services->getAll( ['date_added' => 'DESC'], true, [], [ 'services' => [ 'package_group_id' => $settings['domains_package_group'], ['column' => 'date_renews', 'operator' => '>=', 'value' => $start_date], ['column' => 'date_renews', 'operator' => '<=', 'value' => $end_date] ] ] ); Even the spotlight_tlds work only for one company domain_package_group. if (!empty($spotlight_tlds) && $domains_package_group && $meta['domain_group'] == $domains_package_group->value ) { $this->view->set('spotlight_tlds', $spotlight_tlds); } This was the very first one that caught my attention. Hacking by eliminating the condition $meta['domain_group'] == $domains_package_group->value would do the job, but , for the rest, it seems too much to hack. private function addTldPackageGroup from plugins\domains\domains_plugin.php, // Check if there is a package group collision between all system companies, I would assume that, by design, there should be one package domain group per company. Add a package group for hiding and managing TLDs // Check if there is a package group collision between all system companies $domains_package_group = $this->Companies->getSetting($company_id, 'domains_package_group'); $companies = $this->Companies->getAll(); foreach ($companies as $company) { $company_domains_package_group = $this->Companies->getSetting($company->id, 'domains_package_group'); if ($company_domains_package_group->value == $domains_package_group->value && $company->id != $company_id) { // A collision was found, unset the domains_package_group setting for the current company $this->Companies->unsetSetting($company_id, 'domains_package_group'); break; } } Including import package private function importPackage( On the other hand, public function getSettings(array $vars = null) from plugins\order\lib\order_types\domain\order_type_domain.php, this takes into the account the other custom group. // If the "Domain Manager" plugin is installed, then default to it's package group for domain order forms $domain_package_group = $this->Companies->getSetting( Configure::get('Blesta.company_id'), 'domains_package_group' ); if (!isset($vars['meta']['domain_group']) && $domain_package_group) { $vars['meta']['domain_group'] = $domain_package_group->value; } In order to fit this architecture, I should assign all TLDs to a single domain package group. But, in this case, could I have different order forms for different domain groups? By design, it seems that there is for each company only one TLD package group . I would enjoy the flexibility for a single company to have multiple order forms with domains. Thx!

Funny thing, I've done the following patch in the Blesta 5.1.3, which I should have published earlier, and on upgrade, I was surprised to find that an almost identical patch has already been included in Blesta 5.2.2 ? diff --git a/app/controllers/admin_company_billing.php b/app/controllers/admin_company_billing.php index 6a2fc65c..c6ef610a 100644 --- a/app/controllers/admin_company_billing.php +++ b/app/controllers/admin_company_billing.php @@ -716,7 +716,8 @@ class AdminCompanyBilling extends AppController $all = ['' => Language::_('AdminCompanyBilling.addcoupon.text_all', true)]; $package_groups = $all + $package_groups; $package_attributes = []; - $packages = $this->Packages->getAll($this->company_id); + $filters = ['hidden' => 1]; + $packages = $this->Packages->getAll($this->company_id, ['name' => 'ASC'], null, null, $filters); // Build the package option attributes foreach ($packages as $package) { @@ -901,8 +902,9 @@ class AdminCompanyBilling extends AppController ); $all = ['' => Language::_('AdminCompanyBilling.editcoupon.text_all', true)]; $package_groups = $all + $package_groups; - $package_attributes = []; - $packages = $this->Packages->getAll($this->company_id); + $package_attributes = []; + $filters = ['hidden' => 1]; + $packages = $this->Packages->getAll($this->company_id, ['name' => 'ASC'], null, null, $filters); // Build the package option attributes diff --git a/core/Pricing/Presenter/Items/Service/AbstractServiceItems.php b/core/Pricing/Presenter/Items/Service/AbstractServiceItems.php index db34a4d9..3def140a 100644 --- a/core/Pricing/Presenter/Items/Service/AbstractServiceItems.php +++ b/core/Pricing/Presenter/Items/Service/AbstractServiceItems.php @@ -497,7 +497,8 @@ abstract class AbstractServiceItems implements ServiceItemsInterface // Determine the currency from the item price $currency = null; switch ($meta['_data']['item_type']) { - case 'service': + case 'service': + case 'domain': $currency = (isset($meta['pricing']->currency) ? $meta['pricing']->currency : null); break; case 'option': @@ -515,8 +516,9 @@ abstract class AbstractServiceItems implements ServiceItemsInterface // Determine whether this item price can be discounted with this discount $discountItem = false; switch ($meta['_data']['item_type']) { - case 'service': - // Discount always applies to a service item that applies + case 'service': + case 'domain': + // Discount always applies to a service and domain item that applies $discountItem = true; break; case 'option':

At /admin/settings/company/billing/addcoupon/ there’s no available domain package, since they are hidden. At admin/packages/ there’s a checkbox, allowing to ‘’Show Hidden Packages’’. This feature should be implemented also at coupon level? Thx!

Our company is an .Eu Accredited Registrar, and the .Eu registry - EURid, offers discounted registrations for the first year. We pass this discount to our clients, so is very useful to have lower registration pricing and higher renewal pricing.

The "buggy" admin_urls ( a,x,in) doesn't exist in blesta. Anyway, blesta should have a validation in place. There are pro and cons security throughobscurity. From my point of view, anyway I shall restrict by IP the admin url. I just love the idea of having one letter admin_url. It's fast and fun.

Configure::set("Route.admin", "x");  also creates problems when viewing invoices.

How to replicate Change /config/routes.php ( see https://www.blesta.com/forums/index.php?/topic/3469-ability-to-change-admin-url/) Configure::set("Route.admin", "a"); 2) Clearing blesta cache from /cache/1/nav/1 3) The 404 not found behaviour is present in many pages from logged client area: -/client/accounts/ -client/contacts/ ( when there’s no contact) -lack of invoice, transactions listings from dashboard Debugging The issue was deceiving, because logged in as admin, everything works flawless. Only after debugging the issue, logged in as a client, I’ve noticed at first run that $controllerClass comes as ClientAccounts, but at subsequent runs comes wrongly as AdminAccounts, that triggers the _404 not found controller, due to lack of permissions. See \web\vendors\minphp\bridge\src\Lib\Dispatcher.php, public static function dispatch($requestUri, $isCli = false) if (!class_exists($controllerClass) || !method_exists($controllerClass, 'preAction')) { throw new Exception( sprintf('%s is not a valid controller', $controllerClass), 404 ); } So for, values like “a”, or “in” for admin_url triggers that behavior. I guess that some kind of escaping is required, but I haven't investigated further. On the other hand , Configure::set("Route.admin", "x"); works flawless. Also, there’s not problem with longer admin paths. But, lazy/efficient admins might prefer one letter url admin. Thx!

In the first place, there was an internal debate regarding domains as plugin versus services. Later on, the mainstream is that domains should remain services. "Domains will almost certainly remain as services but be given a designation as domains so they can be displayed a little differently. That seems to be the simplest way forward. " https://www.blesta.com/forums/index.php?/topic/7197-domain-manager-we-need-your-feedback-on-domains/&do=findComment&comment=52874 "All the world are agreed in this subject. Domains are services and should remain as services. how it should displayed and how the order form should treated is another story. " https://www.blesta.com/forums/index.php?/topic/7197-domain-manager-we-need-your-feedback-on-domains/&do=findComment&comment=60816 According to https://dev.blesta.com/browse/CORE-3053 Add migration for pricing to support a renewal price, there a new columns to existing tables. This means that the new domain manager will be backward compatible? Or still a migration utility is needed, but it will be easier to upgrade, since domains would remain services? Thanks!

What about a fundraising, to speed up development of domain refactoring ? We would jump in with $500 USD .

I guess that the new feature is " Renewal Price Option - Optionally set a renew price that is different from the new price for services." Nice! Don't you have a grosso modo ETA for domain refactoring? I mean, this year will be ready? Or, we are talking about 2-3 years ( let's remember that the initial post is from august 2016). This could be relevant to wait for the feature to land in, or start with existing framework and import later.

I don’t dispute that Blesta isn’t secured by design ( “But Blesta seems to be more secure and a nice and clean software”. http://www.webhostingtalk.com/showthread.php?t=1544179) But every application, with authenticated users, could be vulnerable, at some point, to a Cross-Site Request Forgery (CSRF) or Cross-site Scripting (XSS). The main idea of the workaround is to not store the full passwords of the modules ( registrar modules, hosting modules -Proxmox, Vultr etc), but instead store it into a third party proxy api gateway, https://konghq.com/, setup on your own server. The proxy api gateway will transform only the initial request for an authenticated token, then all the request will be forwarded unchanged. How is this different from an attacker grabbing the full password from blesta module? We can implement rate limiting at proxy level, and validate only allowed api calls ( for example deny delete requests). We’ve posted a more detailed explanation here https://forum.proxmox.com/threads/securing-third-party-application-proxmox-integration-with-proxy-api-gateway.47091/ Thank you!

Every ccTLD, with EPP suppport ,might need further custom adjustments. I guess they aren't encoded files in your module, since is based on https://github.com/AfriCC/php-epp2, under GPL3.0 license