Jonathan

This will be in 3.5 as apart of CORE-1717.

Looks like they're both getting loaded but thanks for the recommendation.

Any action resulting in an invoice generated by means of pro-rata.  Upgrades/downgrades including configurable options.
 
What's the logic behind not queueing them for delivery?  Seems like it should so the customer will know about the invoice if say for example they opened a ticket to have the given change done.  It's done via admin side thus queueing it in service_changes pending their payment.  The invoice should be sent to them for payment.

A whitespace at the beginning or end of a search string results in no results found.  I can't think of any case where it'd be warranted to need to search for whitespace at the beginning or end of a string, so perhaps a trim() here could fix it right up

A whitespace at the beginning or end of a search string results in no results found.  I can't think of any case where it'd be warranted to need to search for whitespace at the beginning or end of a string, so perhaps a trim() here could fix it right up

A whitespace at the beginning or end of a search string results in no results found.  I can't think of any case where it'd be warranted to need to search for whitespace at the beginning or end of a string, so perhaps a trim() here could fix it right up

Looks like this is out now: https://developer.paypal.com/docs/classic/express-checkout/in-context/integration/
 
Would indeed be pretty neat to have from the looks of it.

I think the option of requiring a previously accepted order would be the best approach, unless you make an interim "in review" client status they'd be kept in if their first order gets flagged, which the system would remove them from upon acceptance of an order.

Obviously, but that's no solution to keeping someone from bypassing it to start with.  Lets say I'm asleep and can't mark them as fraud (or better yet, just letting Blesta "do it's thing") and they order, fail fraud.  Order again, lets say 5 times, get setup, and setup spam bots.
 
Now what?  Blesta let someone circumvent the fraud system by taking advantage of a flaw in the logic.
 
EDIT - your second assumption is the correct scenario.

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.

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.

mmmkay CORE-1693

It's in 3.5b4 guys

Sounds like something you could use a restricted package for.

It's in 3.5b4 guys

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

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.

3rd has my vote.

Conditionals will be amazing to have!

3rd has my vote.

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

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.

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