[v4.1.1 Logicboxes Renewal]

On 10/19/2017 at 7:05 AM, evolvewh said:

I would hope it is a feature in the new domain plugin that you guys are working on.

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

[v4.1.1 Logicboxes Renewal]

On 10/16/2017 at 12:21 PM, evolvewh said:

Even with that being the case, why wouldn't it go through and add another year to the expiration?

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.

[v4.1.1 Logicboxes Renewal]

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?

[Staff should not permit to delete packages]

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

[Blesta or cPanel Extended issue?]

On 10/2/2017 at 4:46 PM, evolvewh said:

This is still an issue with v4.1.0 and may still be with v4.1.1 but I can't confirm that yet.

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?

[blank page in add service creation]

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']);
        }

 

[blank page in add service creation]

4 hours ago, Blesta Addons said:

Fatal Error (E_ERROR): Call to a member function add() on null {"code":1,"message":"Call to a member

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

[Suspension Error Email Notice]

23 hours ago, Jono said:

Oh, but before I go declaring it invalid, are you able to see anything under 'label' when editing the service?

19 hours ago, Blesta Addons said:

this module was developed by me, i have used it a long time until i have switched to my custom virtualizor extended module . and i remember well that service name well displayed in the label field .

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.

[Suspension Error Email Notice]

18 hours ago, Blesta Addons said:

yesterdays email was all fine, no empty service name, but i will watch theme every day from now until i can get the same issue .

Hmm, yea hopefully it continues to function properly, let me know if it comes up again.

16 hours ago, activa said:

I use proxmox reloaded .

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.  

[Suspension Error Email Notice]

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.

[Suspension Error Email Notice]

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.

17 hours ago, activa said:

Also fo service creation error a get client name instead of service name .

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.

[Language files location for order form?]

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.

[Display order of package groups in order form]

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.

[Where can i find basic statistics?]

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. 

 

[Invoices reported as sent although the log shows they are "Unsent"]

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);
}

 

[setting var called 'file' in the view load to a error]

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.

[The password must be at least 5 characters in length]

21 hours ago, phamhung said:

Now I can change the server. However, after changing server, the user password, as I showed above, disappeared. It's blank now.

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.

[get Configurable Options for service_id]

17 minutes ago, Blesta Addons said:

i have used $this->Services->getOptions($service->id) it was what i want . another function that do the same is $this->PackageOptions->getByPackageId($service->package->id) .

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.

[The password must be at least 5 characters in length]

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)
                ]
            ],

 

[get Configurable Options for service_id]

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.

[The password must be at least 5 characters in length]

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.

[Existing Domain & cpanel account add to client service]

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]/

[Out of stock items still orderable?]

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?

[The password must be at least 5 characters in length]

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?

[Stripe 403 error response]

 

On 9/1/2017 at 4:42 PM, Lucas said:

Line 1272 doesn't need to be changed?

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.