Tyson

Your work-around would be to set multiple messages to the same message type, e.g. $this->flashMessage('error', array('err1' => array('error' => 'Error #1!'), 'err2' => array('error' => "Error #2!")));

I think we need to know more about what you're trying to accomplish in order to offer suggestions on a design that will work for it. Could you elaborate?

Did you reboot the VM? I believe a disk space change requires reboot. If that doesn't resolve it, could you provide the module logs (under [Tools], click on the table row that corresponds to the SolusVM action) for that upgrade? There would likely be an entry for changing the hard disk space (i.e. "changeHdd") in the list.

I wonder if it's a bug. Open /plugins/order/controllers/checkout.php and change this: $this->redirect($this->base_uri . "order/checkout/cart/" . $this->order_form->label . "/"); to this: $this->redirect($this->base_uri . "order/cart/index/" . $this->order_form->label . "/"); Then try to process an order. Do you still experience the 404 error, or do you receive a normal error?

It might be useful to select additional fields (e.g. client first/last name) so admins can more readily use the queries to find matching clients. They could also use them to generate custom reports under [billing] -> [Reports].

This would be a better question to ask Multicraft. If their API supports this behavior in the future then we can make it available in Blesta.

I appreciate your desire for a setting to control this behavior, and this is something we will consider. However, I must disagree with your 99% statistic, unless you can provide quantifiable evidence for it? If so, a resolution for the current behavior will be coming forthwith.

I'm not sure I follow your idea of setting a base daemon IP. The Multicraft module will choose the "best" daemon to use based on the amount of resources available from all daemons available on your account, and then assign the service to that daemon if you are not using a dedicated IP. What are you envisioning for an alternative? A plugin wouldn't solve it. You would need to update the module itself to force a specific port. Did you try updating the module as I mentioned in this other thread?

The label to use is defined by the module, so in your case that would be the Proxmox v2 module. You would want to update that module under /components/modules/YOURMODULE/YOURMODULE.php of your Blesta installation. The label should exist in the service fields and be returned from the getServiceName method. Here's an example.

The thread you linked to describes how you could force port 25565 to be used. The module is currently designed to let Multicraft determine the port because the API does not provide a method of determining what ports are available for use, so we cannot reliably choose one. We'll have to make another pass on the module to see if we can improve that behavior. Does the dedicated IP address work now because you made the source change I mentioned above?

What does it contain? Can you add a new payment type that is of type "Credit"?

Blesta doesn't provide an option to delete invoices (unless it's a Draft), or clients that have invoices/services/etc. as you've noticed. If you're only intending to test Blesta, that would be best done in an alternate Blesta installation dedicated to testing rather than mixing test/live data in a single installation. Laws in many countries prohibit the deletion of important data like invoices. If you really want to delete invoices anyway, you could manually do it via the database, or write a plugin for Blesta that will delete them. Also, the Shared Login plugin will not create a client in Blesta if one does not exist. It will only log them in. Deleting a user in Wordpress will not automatically delete an associated user in Blesta. Additional functionality would be required to accomplish this behavior.

There are no other logs in Blesta that could be checked, so the next step would be to either check server logs (which probably contain nothing of relevance), or analyze the point a request is made to Amazon S3 and look at the request and subsequent response details. You could do this by checking packets sent/received on your server for requests to s3.amazonaws.com, or update the source in /vendors/amazons3/S3.php for the putObject method to manually debug.

I'm unclear on the behavior you're experiencing as the above statements appear contradictory. Could you clarify, perhaps with an example? It would also be useful to have additional information as described in How to Report a Bug, such as the version of Blesta and the PayPal Payments Standard gateway you're using. I took the liberty of testing the gateway just a moment ago on v3.6.1 via an order form and this is the behavior I experienced: I Ordered a $1.00 monthly service I applied a 50% coupon to the service I checked out with PayPal Payments Standard PayPal tells me the cost is an initial $0.50 with a monthly subscription of $1.00/month Note that my 50% off coupon is configured with the option Apply when a service is added only selected. This option only applies the coupon to the new service on creation rather than to the recurring amount, so the $0.50 initial cost and $1.00/month subscription would be expected. If the coupon is configured with the option Apply when a service is added or renews, then following the same steps I outlined above, PayPal says the cost is an initial $0.50 with a monthly subscription of $0.50/month because the coupon also applies when the service renews. Is your coupon configured for the desired behavior?

I'm surprised you took the time to claim the issue is certainly a bug. I think the expectation to receive "dream-land logic or round-about excuses" for the current behavior is rather presumptuous and partially shuns us from having an open-minded dialogue on the issue. The contact permissions dictate page content access rather than back-end system behavior, like sending an email. This is similar to staff permissions. I think if you disable all contact permissions, you'll find that the contact still receives invoice delivery emails for new invoices. This is not because the permissions are incorrect, but rather the nature of a "Billing"-type contact. The system is designed to favor billing contacts for invoice delivery email, so if any exist, only the billing contacts--and not the client himself--will receive invoice delivery emails. Many companies setup billing contacts this way so that they don't need to bother with receiving invoices intended for their internal Billing department. Maybe there is more we can do to improve these types of behavior in Blesta, and I'm open to suggestions.

Contact's don't have an id_code attribute, however, client's do (e.g. {client.id_code}).

Thanks for including the module logs. It looks like the dedicated IP is set and then later overwritten. You might try making a quick change to the module and checking whether it will work correctly, i.e. backup the file /components/modules/multicraft/lib/multicraft_service.php and find if (empty($vars[$this->service_prefix . $service_field])) change it to if (empty($vars[$this->service_prefix . $service_field]) && empty($config_options['ip'])) Then try adding a service with a dedicated IP to see if that resolves the problem. Which images are you referring to? I've looked over the Multicraft images and the only differences I see are that the config option screenshots do not include "Client can Add" and "Client can Edit" checkboxes, which would not impact your Multicraft configuration. Which forum posts are you referring to?

The error you receive indicates that a part of the upgrade process has failed because the upgrade has at least partially been completed. Did you run the upgrade before and encounter an error? In Blesta, under [settings] -> [system] -> [General] -> [Payment Types], do you receive an error? Or can you see a table with headings for Name, Type, and Use Language Definition? If you see the table, does the table contain rows for both Credit and Debit under Type? This will tell us whether you have already completed the entire upgrade from 3.4.3 to 3.6.1. If you see the table of entries, Blesta is already upgraded. If you see an error or missing information, the upgrade only partially completed for some reason and manual action will be required to repair it.

I believe the cron logs under [Tools] -> [Logs] -> [Cron] only shows company-related automation tasks, not system tasks like Amazon S3 and SFTP backups. However, you can check the database to see when that task has run (via cron, not when manually forcing an upload) by checking the `log_cron` table. For installations with one company, the task `run_id` for Amazon S3 backups is 14, so you can list each record of Amazon S3 via the following query: SELECT * FROM `log_cron` WHERE `run_id` = 14 ; If you don't see the records you expect after running that query, it could be possible that another task has failed to run, possbily causing a PHP fatal error, stopping task executions. If that is the case, you should check your automation tasks under [settings] -> [Company] -> [Automation] and look for a task that is still running (denoted by a spinning icon). You could also run this query to check.

There is no email template for canceled services, so no email about a canceled service would be sent. There is a task to add an email template for services scheduled to be canceled, but perhaps one for cancelling a service would be good as well. Your scenario is a little bit different, however. You want to include a message in the email template about the cancellation of a specific service, but an email template we create would be generalized and not dependent on the service being canceled. A separate partial email may need to exist to handle the behavior you expect, similar to the Package Welcome Email (e.g. Package Cancel email).

Since your cron log contains the message "The backup completed successfully", the backup was triggered with AmazonS3, uploaded to your bucket, and produced no errors (i.e. it was successful). There is no difference between an automatic backup and a forced backup, so it is odd that the backup would not appear in your bucket when run via cron when the log indicates it was successful. Is it possible that it is in the bucket, but not visible? Or that it is in a different bucket than the one you were looking for it in?

Multicraft determines the port to use for the accounts that are setup to avoid reusing an existing port. The comment on this task describes the problem of Multicraft incrementing ports while this task aims to simplify API calls which may or may not resolve the issue with Multicraft skipping port numbers it increments. Always using a specific port like 25565 would require the module to allow you to specify a particular port to use, which is a task we would need to add. However, I'm not sure what will happen if you specify a port for a service that is already in use in Multicraft.

There are basically three types of priorities: low, normal, high. I think an option to select any of the three would be best. However, the X-Priority email header that would be sent to indicate this priority can be interpreted to be spam by some spam services.

You would need to update the staff member's configured setting for receiving order emails in order to disable it. This is only possible when logged in as that particular staff member and going to the Orders widget. Alternatively, you could update the database to remove them from the list in the interim: under the `order_staff_settings` table, you can find records for that staff member by his staff ID, then update the `value` column to "never" for the `key`s "email_notice" and "mobile_notice". This issue will be resolved in CORE-1905.

A setting for something like this seems overkill and still wouldn't resolve cases where you might want to have it appear at the top in one ticket reply but at the bottom in another. If you want it to appear in the middle somewhere, manually moving it would still be required. Maybe another work-around could be to automatically add your signature to the reply rather than setting it in there by default. In any case, if you'd like to modify the source to have it appear at the top, update /plugins/support_manager/views/default/admin_tickets_reply.pdt, Change $('#reply_details').val($('#reply_details').val() + data); to $('#reply_details').val(data + $('#reply_details').val()); and change $('#note_details').val($('#note_details').val() + data); to $('#note_details').val(data + $('#note_details').val());