Cody

How your Windows users are configured is beyond the control and scope of Blesta, and thus not a bug with Blesta.

It sounds like the issue you're having here is that your CRON user does not have the same permissions as your WEBSERVER user. Ensure they have the same permissions to read/write files and you'll be fine. Blesta does not set any special permissions on files it creates, only directories. It does this to ensure that when writing files to those directories CRON/WEBSERVER users can both use these file interchangeably. However, because Windows is funky with how it manages permissions if the user used to create the directory does not have permission to escalate the permission of that directory to allow other users to access it, it fails. Thus making the directory unwritable by other users (i.e. if CRON creates the directory then WEBSERVER can not write to it, and vice versa).

Have you taken a look at how errors are returned in the API docs?

Closed as not a bug in Blesta. If you continue to have issues with this please post in the support forum. As per Tyson's response: http://docs.aws.amazon.com/AmazonS3/latest/dev/BucketRestrictions.html

The install.php file can't be used to mess anything up. If it could, we'd require removing it. I think you're just used to other applications that require you to do that. Blesta is smarter than those applications.

Ditto on this. Especially annoying when my browser crashes because it exhausts too much memory/GPU trying to render all the results. Dynamic loading is great for finite length pages that you want to load quicker, but for a set of results that could be essentially boundless it makes much less sense.

A good idea for a mass update plugin. I'm sure there are other settings users could find useful in mass updating as well.

Setting the protocol in the templates as defaulting to http is not a bug. While we strongly recommend the use of SSL certificates, we can not make that a base requirement for using Blesta. That said, users can enable requiring https in their .htaccess file as explained in the manual, which would seamlessly redirect all non-https requests to their https equivalent. If you feel that users would fail to follow links in their email simply because they are not over https, then you can certainly update the email templates to contain the correct protocol. Making the protocol for all email templates a company setting is a worthy suggestion, and I would encourage you to post that in the feature request forum.

What version of the universal module are you using?

Have you tried this: https://github.com/cloudrck/blesta-nginx/ (courtesy of cloudrck)?

CORE-795 is fixed for 3.0.4. To patch yourself update /components/email/email.php lines 260-276: from: $body_text = null; foreach ($this->message->getChildren() as $child) { if ($child->getContentType() == "text/plain") $body_text = $child->getBody(); } $vars = array_merge($vars, array( 'to_address'=>implode(',', array_keys((array)$this->message->getTo())), 'from_address'=>implode(',', array_keys((array)$this->message->getFrom())), 'from_name'=>implode(',', array_values((array)$this->message->getFrom())), 'cc_address'=>$cc_address, 'subject'=>$this->message->getSubject(), 'body_text'=>($body_text), 'body_html'=>($this->message->getContentType() != 'text/plain' ? $this->message->getBody() : null) ) ); to: $body_text = null; $body_html = null; foreach ($this->message->getChildren() as $child) { if ($child->getContentType() == "text/plain") $body_text = $child->getBody(); } if ($body_text === null) $body_text = $this->message->getBody(); else $body_html = $this->message->getBody(); $vars = array_merge($vars, array( 'to_address'=>implode(',', array_keys((array)$this->message->getTo())), 'from_address'=>implode(',', array_keys((array)$this->message->getFrom())), 'from_name'=>implode(',', array_values((array)$this->message->getFrom())), 'cc_address'=>$cc_address, 'subject'=>$this->message->getSubject(), 'body_text'=>$body_text, 'body_html'=>$body_html ) );

I was just able to duplicate. Created CORE-795. When HTML emails are disabled, the email component is not able to find the plain-text version of the email content for logging.

In that case,

Looks like it's logging just fine, based on your second screenshot. To confirm, check the log_mail table for entries. I believe the issue you're seeing is that only plain-text versions of emails are displayed in the UI, and it looks like you have no plain-text versions of your emails. Blesta should automatically convert your HTML emails to plain-text when delivered, but if the plain-text email template contains anything (including white space) that would prevent the automatic conversion from taking place.

Moved as not a bug.

What currency was this for (USD)? What is the format of the currency (####.##)? What was different about the first attempt (that failed) and the subsequent attempt? Was the first through an order form while the other was in the client interface, or...?

Wouldn't it make more sense to offer an option under [settings] > [Company] > [billing/Payment] > [invoice Customization] to choose whether or not the invoice should be streamed or force download, since settings don't allow you to offer two different file types for invoices at one time?

As Tyson pointed out, you need to have the same cipher keys in your /config/blesta.php config file as you did in the system you exported from. Moved to support forum as not a bug.

Don't you get a similar popup to the following when you click to view an invoice? You can click to open it in Adobe Reader, or if you have a PDF plugin for your browser of choice, you can choose to open it in a browser which would do the same as streaming.

There's no mechanism in place to associate custom fields with contacts. Custom fields can only be associated with clients. I don't really have any suggestions on how you might use custom fields for contacts as the database is simply not designed to work that way, and there's currently no event that would allow plugins to associate custom fields with contacts. If you're modifying the default invoice template you should instead clone it and rename it. Then you should have no problem customizing it as much as you need.

This is similar to contact login accounts, which is a feature slated for a future release of Blesta. The database already supports contacts having login (i.e. user) accounts, but the interface doesn't currently have the option to authenticate or restrict access based on permissions. However, the contact-based user authentication system would only permit a contact under a client account access to that client account. It is not planned to support a single contact access to multiple client accounts (though the database does support such a thing). Depending on the access you want these users to have on client accounts, you could do this with a simple authentication plugin. You'd create a plugin with a login form that would authenticate against Blesta's users system, and initialize the appropriate session values to permit the user access to a client's account. If you wanted to allow the user to swtich between client accounts you'd need to create a page in your plugin to allow them to select a different client account to migrate to (by updating their session with the appropriate client ID). If you only wanted to grant access to certain areas you'd have to implement an Appcontroller.preAction event handler and evaluate each URI to ensure the user can access it based upon your plugin's own custom permissions.

The paid stamp is already available. PDFs streamed to browsers are not supported by all major browsers on all major operating systems. Some browsers fallback to forcing download, while others do nothing but show a blank white page. The only way to ensure 100% delivery is to force download as Blesta does. If Blesta did allow streaming we would undoubtably be inundated with misdirected bug reports. If there was an option to enable streaming it would have to be done in such a way that the user is aware of the incompatibility issues that will arise.

If you have phpMyAdmin you can import the .sql or .gzip file directly. If not, you can import by running the mysql command.

The HTTP code you enter in Blesta should only be a number. I don't think that's the issue. Without knowing the API requirements for that particular resource I can't really say what the problem is (a 400 response is vague). It could be that something else that's posted along with the request is throwing it off. As a sort of work around, if necessary, you could have the universal module post to a script you create to capture the data and pass along only the variables the API requires using curl, for example.

Looks like you've just about got it, though the variables are not available in the URL (but that's an awesome idea). They'll automatically be sent via POST, however. From your curl request you've specified both parameters to be sent via POST. To set rank as a variable configure it as a Secret or Hidden type, and specify it's value as VIP. Most HTTP requests respond with a 200 response code. If a 200 response indicates success for that URL enter 200 as the HTTP Code. If, instead, the URL responds with some string that contains "success" or something similar, set that string in the Response Contains field.