Jono

I know I have heard Paul mention this in the context of the domain plugin.

Hmmm, it sounds like this is only an issue when the service is not synced with the domain, since it should not be build until the expiration is approaching. I think the intent of that code was to prevent a domains expiration from being bumped a second time if an admin manually changed it already in logicboxes.

I took a quick look at the logicboxes module and found these lines of code $vars = [ 'years' => 1, 'order-id' => $fields->{'order-id'}, 'exp-date' => $order->endtime, 'invoice-option' => 'NoInvoice' ]; foreach ($package->pricing as $pricing) { if ($pricing->id == $service->pricing_id) { $vars['years'] = $pricing->term; break; } } // Only process renewal if adding years today will add time to the expiry date if (strtotime('+' . $vars['years'] . ' years') > $order->endtime) { $response = $domains->renew($vars); $this->processResponse($api, $response); } What it means is that if the end time fetched from logicboxes is farther in the future than the current time plus the number of year from the pricing term, then the request to renew will not be sent. I don't fully understand your problem, but is it possible that this accounts for it?

So you are asking for another permission for package deletion? That seems like a good idea. CORE-2484

CORE-2397 Should have resolved the issue happening in the cron. Are you saying that you still experiencing services having their renew date changed from a prorata date to something else when activated by the cron? Or are you experiencing this through manual activation?

I took a quick look through the service creation process and it looks like if you create a service and append it to an existing invoice then you receive a fatal error. I created a task to resolve that issue CORE-2480, which was introduced by CORE-2167. If this is the issue you are having, just add this code to the beginning of Invoices::appendServices() and you should be good: if (!isset($this->ServiceInvoices)) { Loader::loadModels($this, ['ServiceInvoices']); }

Is there more to this error? A line number or some thing that can help me track down where it is happening?

I'd love to hear back from @activa on this. I downloaded the module and created a service. The label field was blank. But I messed with some stuff because I do not have credentials, so I did not have any nodes or templates (though I don't think those are relevant to the service name). Any how, you seem pretty confident that it should work so I just want to see if it works for them.

Hmm, yea hopefully it continues to function properly, let me know if it comes up again. I took a quick look at this. It looks like the service name field is defined in the config as 'server_name'. As far as I can tell, this is not actually a service field, but only a module row field, and so is not actually a valid service name field. In this case, that blank service name would make a lot of sense. Oh, but before I go declaring it invalid, are you able to see anything under 'label' when editing the service? If you wanted to try and get a service name you could try a couple things. Based on the fields returned by addService() the only valid field would be vmid, so you could change the config so it uses that for the service name. Alternatively you could define a getServiceName() method in the module that retrieves options['hostname'] as the service name.

What modules are you guys using, and do I have access to the code? I'd love to see if I can figure why both are experiencing unexpected behavior.

The content of this tag is very dependent on the module you are using. The task updated methods used by Suspension, Unsuspension, Cancellation, and Creation error emails to include the service name provided by [yourmodule]::getServiceName. If this method is not defined by your module, it will return null which results in the tag being empty. Again, the value of the tag is determined by the getServiceName() method of your module, so I can only think that that module defined it using the client name some how.

Each template(ajax, standard, and wizard) has it's own language files. You are probably looking for plugins/order/views/templates/ajax/language, plugins/order/views/templates/standard/language, and plugins/order/views/templates/wizard/language.

Unfortunately, Blesta does not currently support this, though this does seem quite useful. I'd love to see a feature request for this at https://requests.blesta.com. If it makes sense at all to put your packages in to one group, packages can be ordered within their groups. This is done by going to Packages -> Package Groups and expanding(clicking on) the row for a package group, then dragging and dropping packages in the order you want them.

Just a note, but if you are familiar with mysql Blesta allows you to create custom reports in Billing -> Reports. An example for exporting a list of clients for a given package ID is described here.

CORE-2462. Sorry for the slow response, looks like this one got lost for me too. Anyhow if you would like to implement this on your system immediately you can update components/invoice_delivery/invoice_delivery.php and add this code on line 164: if (($errors = $this->Emails->errors())) { $this->Input->setErrors($errors); }

Correct. If we look at the minphp Bridge View class we see in the fetch method these lines of code: if (is_array($this->vars)) { extract($this->vars); } if (!file_exists($file)) { throw new Exception(sprintf('Files does not exist: %s', $file)); } In this case $this->vars contains all variables set using $this->set(). When the 'file' variable is extracted it overwrites $file with the value you set. In this case it sounds like you set an object which is of course not a valid argument for file_exists(). I suppose the bridge could handle it more quietly by adding a flag such as EXTR_SKIP or EXTR_PREFIX_SAME to the call to extract. In any case, it is not allowed to set a variable named $file to the view.

Right you are. It looks like the change is only made locally. It seems that if no password is given in the edit, it defaults to a blank value. To fix this you can replace lines 1043-1049 $params = [ 'username' => isset($service_fields->direct_admin_username) ? $service_fields->direct_admin_username : '', 'passwd' => isset($vars['direct_admin_password']) ? $vars['direct_admin_password'] : '', 'passwd2' => isset($vars['direct_admin_password']) ? $vars['direct_admin_password'] : '', ]; with $params = [ 'username' => isset($service_fields->direct_admin_username) ? $service_fields->direct_admin_username : '', 'passwd' => isset($vars['direct_admin_password']) ? $vars['direct_admin_password'] : ( isset($service_fields->direct_admin_password) ? $service_fields->direct_admin_password : '' ), 'passwd2' => isset($vars['direct_admin_password']) ? $vars['direct_admin_password'] : ( isset($service_fields->direct_admin_password) ? $service_fields->direct_admin_password : '' ] Thereby causing it to maintain the current password by default.

Glad you found what you needed . Though I believe Services::getOptions() only gets options currents assigned to the service so be careful with that one. Also PackageOptions::getByPackageId() does not respect settings for client addability or editability if that matters for your purposes.

CORE-2458. If you want to fix this in your code replace direct_admin.php lines 1267-1276 'direct_admin_password' => [ 'format' => [ 'rule' => ['matches', "/^[(\x20-\x7F)]*$/"], // ASCII 32-127 'message' => Language::_('DirectAdmin.!error.direct_admin_password.format', true) ], 'length' => [ 'rule' => ['minLength', 5], 'message' => Language::_('DirectAdmin.!error.direct_admin_password.length', true) ] ], with 'direct_admin_password' => [ 'format' => [ 'if_set' => $edit, 'rule' => ['matches', "/^[(\x20-\x7F)]*$/"], // ASCII 32-127 'message' => Language::_('DirectAdmin.!error.direct_admin_password.format', true) ], 'length' => [ 'if_set' => $edit, 'rule' => ['minLength', 5], 'message' => Language::_('DirectAdmin.!error.direct_admin_password.length', true) ] ],

Maybe Services::getOptionsAvailable() is similar to what you are looking for. services.php starting at line 1535. It is a private function, but it is easy enough to replicate the process it does.

Hmm, well as I said, there shouldn't be any way for this to occur unless the value in that field is less than 5 characters long. Let me know if this comes up again and I'll take another look.

Those are account actions. Nelsa was referring to the service actions on the service edit page. On the list of services there is link labeled 'manage' for each row. Click the one corresponding to the service you want to edit. On that page there is a section with the heading 'actions'. Under that heading there is a drop down and one of the options is 'Change Renew Date'. uri: admin/clients/editservice/[client_id]/[service_id]/

Through a direct link I went straight to the config options page. Then I continued on to the cart. I signed in, and clicked to checkout & pay. At this point I received an error about the quantity and the service was not actually ordered. In my situation, the problem is not that the service is actually orderable, but that the error message is not clear and it does not keep you on the checkout page. Did you experience the same behavior, or was your service actually orderable?

As long as that value is 5 characters or longer when you submit the form, the error should not occur. Have you been able to recreate this since the first time?

Fair point. That line will not affect the error message, or cause any transaction to be approved that shouldn't, but it will affect whether the logs correctly mark the response as an error.