Jonathan

Blesta's fraud checks/reviews can be bypassed by the following process: 1. Place order. Client account created. Blesta properly flags this order for review per fraud check settings. 2 .Place another order. Since client account existed, no fraud checks are run and the order is provisioned. This is a pretty major bug. People seem smart enough to do this and get fraudulent orders through the system

While not perfect, it would be more accurate to require at least two periods in this. So while domain.co.uk would technically pass, at least domain.com would not. It would be an improvement.

Is this on b4? Everything in the database for the user looks perfect, that's what I don't get. The username just will not work. Change it back to one not starting with a number, DB gets updated as you'd expect to update users.username and then it does work.

Went back and tested again and I guess I fat-fingered 3.4.3. I can still recreate it in 3.5b4. Create a client "use email as username" Change the email to something start with a number. I used "123test@gmail.com". You can also create a contact and set a simliar username to recreate it. Error: "No matches found for that user/password combination." Found at /client/login Blesta 3.5.0b4. PHP 5.6.9 (cli) (built: May 15 2015 09:40:22) Copyright © 1997-2015 The PHP Group Zend Engine v2.6.0, Copyright © 1998-2015 Zend Technologies with the ionCube PHP Loader + Intrusion Protection from ioncube24.com (disabled) v5.0.7, Copyright © 2002-2015, by ionCube Ltd. with Zend OPcache v7.0.4-dev, Copyright © 1999-2015, by Zend Technologies mysql Ver 15.1 Distrib 10.0.19-MariaDB, for Linux (x86_64) using readline 5.1 nginx version: nginx/1.8.0 built by gcc 4.4.7 20120313 (Red Hat 4.4.7-3) (GCC) built with OpenSSL 1.0.1e-fips 11 Feb 2013 TLS SNI support enabled configure arguments: --prefix=/etc/nginx --sbin-path=/usr/sbin/nginx --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --http-log-path=/var/log/nginx/access.log --pid-path=/var/run/nginx.pid --lock-path=/var/run/nginx.lock --http-client-body-temp-path=/var/cache/nginx/client_temp --http-proxy-temp-path=/var/cache/nginx/proxy_temp --http-fastcgi-temp-path=/var/cache/nginx/fastcgi_temp --http-uwsgi-temp-path=/var/cache/nginx/uwsgi_temp --http-scgi-temp-path=/var/cache/nginx/scgi_temp --user=nginx --group=nginx --with-http_ssl_module --with-http_realip_module --with-http_addition_module --with-http_sub_module --with-http_dav_module --with-http_flv_module --with-http_mp4_module --with-http_gunzip_module --with-http_gzip_static_module --with-http_random_index_module --with-http_secure_link_module --with-http_stub_status_module --with-http_auth_request_module --with-mail --with-mail_ssl_module --with-file-aio --with-ipv6 --with-http_spdy_module --with-cc-opt='-O2 -g -pipe -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic'

I've verified this in two different Blesta installs. One 3.4.3, one 3.5.0 b4.

Any username, be it a username or an email address, which starts with a number cannot login to Blesta at all.

Regex would be a fine solution for the most part but I don't think there's a way to create my own regex rules on top of the Solus module's fields, at least not that I'm seeing?

Sounds awesome. Would be a huge improvement.

I didn't think that error should be getting generated either. It's via the admin GUI. I can click "manage service", ONLY change the renewal date, save, error.

Looks like there's no checking here for a valid hostname. "google.com" is not a valid hostname for the purposes of a Linux server's hostname. "host.google.com" is. This causes some issues with many things inside of a VPS such as cPanel being a big one. cPanel will not recognize a raw domain name as a hostname.

It only seems to occur when "prorate" is ticked so I guess the flaw is potentially somewhere in the proration logic here. Proration works on configurable optoin changes just fine.

When trying to change renew date I get "One of the configurable options selected is not valid for the service." no matter what. I can change term, package, configurable options, etc. without issue, but cannot change the renew date. FWIW this is with "prorate" ticked and "use module" unticked.

Sounds good to me!

...

Sounds like something you could use a restricted package for.

It's in 3.5b4 guys

Looks like using "copy" on a package doesn't copy it's coupon associations. There's no issue here, move along

Coupons aren't included in the price preview displayed in admin for upgrades/downgrades, nor are they actually included in the pro-rata invoice which is generated so I think the first issue is connected to the latter. I did confirm on some pro-rata invoices I had generated in b3 that this was working, but is now broken in b4 and that the new price previewer doesn't take it into account either. This effects both package upgrades/downgrades, and configurable option upgrade/downgrades. Perhaps it's tied to CORE-1672 somehow?

3.5 does seem to change a few things in templates so I'd recommend building on 3.5 base. Basic on Blesta's history a stable release is probably only a few weeks away.

3rd has my vote.

Yep I thought of that after posting this, but I don't think that's as bad as ending up with a 4-page invoice from a one-item pro-rata change. There's gotta be a middle-ground solution as I think we can all agree a 4-page invoice for one change is obnoxious.

Sure would be handy if the universal module could POST/Email on cancellation scheduling with the date scheduled for and other basic info. This would let us send any necessary cancellation scheduling APIs to remote parties.

Hey guys, Thought others might find this useful. I needed to have old configurable option values available in my POST requests from the universal module so after a bit of digging a pretty simple edit to app/models/services.php takes care of this nicely. Unfortunately it's a core edit, though hopefully this can make it into core officially *hint hint* // KNOWNHOST MOD RETURN OLD CONFIG OPTS foreach($service->options as $config_option){ if(isset($config_option->option_type) && $config_option->option_type == 'quantity'){ $vars['oldconfigoptions'][$config_option->option_name] = $config_option->qty; }else{ $vars['oldconfigoptions'][$config_option->option_name] = $config_option->option_value; } } // END KH MOD RETURN OLD CONFIG OPTS Insert this code around line ~1064 (right above $service_info = null;) of app/models/services.php I've only tested this a few times with different scenarios but it works perfectly in my environment. Enjoy

I have a service which uses a lot of dropdowns for various configurable options (10+). This being the case, editing a single one results in a 4-page pro-rata invoice that is just a confusing mess to me, so I know it will be to customers. @Cody / @Tyson I sent a copy of it to @Paul via email so he can pull it up for you. 450686.pdf sent today.

@Licensecart just because something isn't a high priority to you doesn't mean it's not a high priority to someone else. Who are you to tell someone what's important to them or not? You constantly run around these forums bashing anyone with an opinion different than yours, or *gasp* anyone who's critical of Blesta.