Timothy

The setting that controls Auto Debit Days Before Due Date no longer allows Same day to be set when using a client group override. This is on Blesta 3.1.2 Steps to reproduce. 1: Create a client group 2: Try and change the setting for Auto Debit Days Before Due Date to Same Day. This used to work. I'm not sure when it changed, but it reset all the client groups from Same day to one day and started charging clients early. Please let me know what else you need to fix this. Thank you

Hello, I am having an issue with configurable options showing up on the order review screen when they have not been selected. This happens to any option that uses a quantity field. I have tried to leave the quantity field blank, but it automatically fills in with a zero. This leaves the review page showing all options with quantity fields regardless of customer selection. Is there any way to make options with quantity fields not show up on the review page unless they have a quantity higher then zero?

Paul, I was also under the impression that the Stripe implementation was fully tokenized instead of the current setup. I believe I had a open ticket about this back in December. I agree with @iamp, that it is likely, there are other installation that are using Stripe unaware of their PCI compliance obligations. So here is my vote for having the stripe module fully tokenized in Blesta.

Hi, So far as I know, it does pass the card pan through the server and then on to Stripe when the data is initially put in. After that it uses tokenization to charge cards. The PCI implications are that you have to manage your own PCI compliance. This typically requires filling out a SAQ (type C) and doing quarterly scans from an ASV. Stripe.com will note this under your Account settings > Security section. Hope that helps.

Hi Cody, I opened a ticket with the information.

Sorry Paul, I forgot to mention it was marked as wont-fix. I hope you guys can find a solution to this as our invoices are almost impossible read. Thank you for your attention to this.

Core-570: Group and designate addons as such on invoices. The current invoices in Blesta 3.1 show addons mixed with primary products on the invoice. I would like to see invoices listing the primary product followed by each addon product associated to it in a format that easily readable by customers. This is marked for 3.1 as indicated at http://www.blesta.com/forums/index.php?/topic/1813-release-310/, but does not appear to have happened.

That makes sense. Thanks Cody.

I am curious what the rotation policy is supposed to do? From my understanding it should delete the logs, but in most cases it does not appear to do so. For example I have 1012 pages of cron logs which date back to December 31. The Gateway logs date back to the 12th of December. Everything else dates back to October. The rotation policy is set to 30 days and has been since the install. Am I not understanding how it works?

We had the same issue and it was due to something not being set right in the database. We were able to fix it by setting auto debit to off and then back on again on the client profile page.

It appears to be working on the 3.1 beta. Thank you Tyson.

Hi, I would take a look at the fastcgi buffer settings and increase to compensate for the larger size of SSl transactions. Link: http://nginx.org/en/docs/http/ngx_http_fastcgi_module.html#fastcgi_buffer_size Edit: You may want to look at fastcgi_max_temp_file settings too. They may be to low for the file you are uploading.

Hi Tyson, I will test it again tomorrow. Glad to know it's implemented.

I put this in as a bug as the issue is still present and I can't find a bug report or core number for it. http://www.blesta.com/forums/index.php?/topic/1675-ticket-response-via-email-not-changing-status/

When a customer responds to a support ticket via email, the status of the ticket is not updated. There was a discussion about this back in October at http://www.blesta.com/forums/index.php?/topic/1277-support-response-via-email-not-changing-status/?hl=status I can confirm I still have the issue on 3.0.7. It does not appear to be fixed in 3.1 Beta.

It works for us, but we may be doing it differently. We do SSl termination on a Nginx proxy which then passes through to a different Nginx server running Blesta in clear text. I've never seen the 'client intended to send too large body' error before. Normally it would be a 413 Request Entity Too Large if it was a matter of max_client_size. Would you mind posting the relevant bits of your configuration?

Not at this time. Check http://www.blesta.com/forums/index.php?/topic/1613-need-some-information/?hl=mass+mail#entry12650

This would be useful to me too. +1

There is no mass mail option built into Blesta that I am aware of.

As another FreeBSD user +1. I surprised it's not more common to have a central place for GeoIP data since so many web applications are using it now.

Good point. Sorry for the noise.

Cody, I seem to remember the php hash and tokenizer functions were also needed when I did my initial install. Also, Blesta works just fine on Nginx which is not listed on the requirements page.

Hi, We do this as well but use the real ip module as a solution. Our layout looks like this: Nginx proxy -> Nginx web server with Blesta. The proxy has the following in nginx.conf. proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; And then on the back end Nginx web server we install the real ip module. You can get that from http://nginx.org/en/docs/http/ngx_http_realip_module.html #Real IP Configuration in nginx.conf http section. set_real_ip_from your proxy ip; real_ip_header X-Forwarded-For; With the above configuration, Blesta works fine and tracks the right IP.

Perhaps as an addition to CORE-136 you could allow people a place to to add advanced parameters that are then passed directly to mysqldump. I think this is probably a corner case scenario but it might be useful enough considering you already have CORE-136 open. This thread can be marked as solved. It looks like both the issues are server specific and not Blesta at all. Sorry for the noise.

It looks like there are two problems. Mysqldump was not working with the Blesta database user due to not having lock tables permissions. My previous manual test used a admin user that did have those privileges. Updating the privileges of the Blesta database user to to be able to lock tables fixes the dump with a hard coded mysqldump path. The question I have now is why does it require a hard coded path when mysqldump is in the path environment and works correctly when run as the Blesta server user. Also, are there any other side affects of not have lock tables permissions with Blesta? Perhaps a check when Blesta is installed for the lock tables permission would be useful. In any case, with a hard coded path the issue is solved for the moment.